Looking at common Agile practices it seems to me that they (intentionally or unintentionally?) force developers to spend more time actually working as opposed to reading blogs/articles, chatting, coffee breaks and just plain procrastinating.

In particular:

1) Pair programming - the biggest work-forcer, just because it is inconvenient to do all that procrastination when there are two of you sitting together.

2) Short stories - when you have a HUGE chunk of work that must be done in e.g. a month, it is pretty common to slack off in the first three weeks and switch to OMG DEADLINE mode for the last one.

And with the little chunks (that must be done in a day or less) it is exact opposite - you feel that time is tight, there is no space for maneuvering, and you will be held accountable for the task pretty soon, so you start working immediately.

3) Team communication and cohesion - when you underperform in a slow, distanced and silent environment it may feel ok, but when at the end of the day at Scrum meeting everyone boasts what they have accomplished and you have nothing to say you may actually feel ashamed.

4) Testing and feedback - again, it prevents you from keeping tasks "99% ready" (when it's actually around 20%) until the deadline suddenly happens.

Do you feel that under Agile you work more than under "conventional" methodologies? Is this pressure compensated by the more comfortable environment and by the feeling of actually getting right things done quickly?

  • 2
  • 3
    I think agile makes programmers more efficiently by making it more happily. Of cause it overcome procrastination because the two programmer sees each other, and the feeling of sharing ideas of codes is much more rewarding than reading blogs, or answering questions on SE.com
    – tactoth
    Sep 29, 2010 at 12:59
  • 1
    So it seems that Agile programming is EPIC WIN, am I right?
    – Adam Arold
    May 11, 2011 at 7:45
  • 2
    Heard of the "Deadline effect"? Efficiency almost doubles close to the deadline - agile keeps 2 week iterations to balance boredom (idle-time) with anxiety keeping you in the cusp of being productive!
    – PhD
    Dec 23, 2011 at 8:38
  • Agile just makes you do your work with ownership! If its YOURS you'll spend time on it MORE than coffee, surfing, blogs. And since its YOURS you WILL have a positive reason to own up to it and finish it - so will the others. Hence better the chances of the "team" reaching the goal! :)
    – PhD
    Dec 23, 2011 at 8:39

12 Answers 12


The main idea behind the agile methods is to help you be productive - in a positive sense. No one cares if you spend an hour surfing every day if you meet the deadline. Everyone gets mad if you surf half an hour every day but miss your deadline. The solution: Make it easier for you to meet the deadline.

As you noticed, pair programming makes sure you stay focused (among all the other advantages like improving skill/knowledge spreading, better code, less bugs, uniform design, etc.).

I found that discipline is always a struggle for me. If I pair with someone, chances are that one of us wants some work done today and pulls the other along. So the "work for a month" often becomes turns into "work together for one week", being surprised how that huge amount of work resolved in the end, spend a day or so recovering (refactoring, fixing TODOs in the code, adding a couple of tests, surfing with a clear conscience) and then grabbing the next month of work.

Net result: I'm much more relaxed (more because than despite the constant supervision), team cohesion is much better, work gets done more quickly, people don't hang around some minor issue for hours or even days (because someone else can spot the problem much faster).

When you say "you may actually feel ashamed", isn't that a good thing? It means you feel that you did wrong and you should. You're not getting paid to get nothing done. Not getting anything done makes you feel helpless, unhappy, unworthy, miserable. Instead of feeling ashamed, stand back and think "Why didn't I accomplish anything today?" Do you need help? Is there something you don't understand? Is the current task too hard? You don't like it? Maybe you can switch the task with someone else. Maybe someone else can help you get through. Agile means: Assume responsibility instead of being micro-managed like a puppet on strings. You need a tool? Go to your boss and ask for it. Learn to argue. Learn to stand up and shout when you have to.

As for tests, there is a sweet spot when your code suddenly collapses from "nice" to "perfect". That's the moment when you notice that you need to implement feature X and you thought that will be a nightmare and suddenly realize that the code is almost there. Just a small refactoring here and there. A new class and done. Four weeks of work suddenly became a day. Victory! Triumph!


I agree.

Pair programming

Is a very intense and exhaustive way of working, and I never apply it unless I have some developers that needs to be coached by others (new comers for example)

Short stories

Team communication and cohesion

Testing and feedback

Yes Agile and specifically Scrum is a huge productivity booster. When applied correctly, the turn over can be up to 20% (1 developer on 5 leaves the company).

The reason is simple: Scrum doesn't not provide more productivity, it provides the whole company with much more visibility on what's going on (including in the management of course).

  • It makes impossible for a developer to just do the bare minimum. The bare minium is now the team average!

  • It makes impossible for the management to not collaborate properly.

This is why I said (in my other answers in similar questions), that Agile is NOT for every organisation (and for everyone).

For instance, Public sector is really not suited for Agile.

Agile being used as a pressure tool ? Of course, I've seen that many times. It just makes things much more worse.

  • 7
    Re: exhausting. We do pair programming at my office. It's 8 hours of super intense stuff.... and then you can just go home. 40 hour work-weeks in the heart of Silicon Valley. (Helps prevent burnout).
    – user2348
    Sep 29, 2010 at 14:41
  • 2
    +1 for "Agile is NOT for every organization".
    – Ryan Hayes
    Oct 5, 2010 at 12:28
  • Nice answer. Do you also have a source for this "(1 developer on 5 leaves the company)". Would be interesting to read the whole story.
    – Jan_V
    May 11, 2011 at 7:36
  • @Jan_V: Ken Schwaber himself (in 2008). Unfortunately, that was not recorded.
    – user2567
    May 11, 2011 at 11:03
  • +1: Very good answer. Agile allows to follow the development much more accurately but does not necessarily boost productivity. Many programmers do not need pair programming to be motivated: an interesting problem can be enough to keep them going for 10 hours on a row. In certain situations, SCRUM can make productivity drop by 50% or more. But all these stories are always explained with: "You are not doing it the right way."
    – Giorgio
    Apr 6, 2013 at 13:40

Do you feel that under Agile you work more than under "conventional" methodologies? Is this pressure compensated by the more comfortable environment and by the feeling of actually getting right things done quickly?

It makes me work more, but above all, it makes me work on the right thing. At any given moment I know what I should be doing.

It's kind of positive pressure. That's quite different from some external "you're already behind the schedule, work more, code overtime!" -kind of pressure.


Actually, I'm much more productive when I use the conventional methods. With the conventional method, I create e.g. a detailed requirement analysis, a feasibility study, a functional specification, a technical specification and lot of meeting protocols, all within just a few months! I might even create some lines of code once the impact analysis is done!

Agile, all I create are a few deliverables.


In our company,

Pair Programming - When something really complex and does require broad analysis, even we would put two excellent people together and get the task done in QUICK time. Here the complexity of the task decides the need of pair programming.

Short Stories - Then slacking off for 3 weeks (approx 5-6 hours per day) and rushing at the last moment (approx 12 to 14 hours per day) as a developer I don't like to have a oscillation in my work burden. Work around 8 hours per day and keep your schedule stable and this always looks COOL.

Team communication and cohesion - In scrum meeting we not only share the task status but the obstacles too. Here when someone is really in need of help other members would actually come up with their ideas to help him out. But certainly you need a excellent Team for this and we are :)

Testing and feedback - Certainly as a developer I do not want myself to be burdened with Bugs at last, the next moment after you find a bug was to fix it and again, this would allow me to have a good forecast of what should/can be done next and reschedule the deadline (if needed) accordingly.

So, as a developer I am much happy with the kind of task I take and damn sure I can say that I never felt the REAL pressure of deadline.


Do you feel that under Agile you work more than under "conventional" methodologies?

  • If you mean do I feel more productive under Agile, I'd say it depends.
    I usually think of it in terms of Ferrari (as conventional) vs Landrover (as Scrum). When driving on a highway Ferrari beats the hell out of Landrover.
    It's the off-road when one needs jeep not sports car - I mean if your requirements are irregular and/or if the team work and management experience are not that good, you'll have to choose Scrum - simply because trying go conventional will get you stuck - like Ferrari will stuck off-road.

As for "work more", well I think one expecting stuff like that likely underestimates programmer's IQ and their ability to adapt to various forms of management dementia.

So far, I participated in two Scrum teams making quite different projects in different companies. In both teams I did not notice any change in my habits compared to eg waterfall / iterative.

I would be proud to claim that this is because I am so special and invincible but frankly, I've seen habits of all other guys in team being invincible, too.

  • 'As for "work more", well I think one expecting stuff like that likely underestimates programmer's IQ and their ability to adapt to various forms of management dementia.': Well, there might be teams who really need to be monitored closely in order to keep focus on their tasks. IMO this is especially true for unexperienced developers and bad planners. Of course, to more experienced programmers these practices look like management dementia, i.e. they can get very little or no benefit out of them.
    – Giorgio
    Aug 24, 2014 at 10:16
  • @Giorgio yeah I meant something like that when stating that "if the team work... are not that good" may be a good reason to prefer agile. I only want to note that even then, expecting agile to force them "work more" is sort of utopia... or more precisely a bit too straightforward to work well. I've seen it used successfully to teach inexperienced developers and bad planners to work and plan better/more
    – gnat
    Aug 24, 2014 at 13:23
  • 2
    On top of that, for experienced programmers all the SCRUM rituals might just get in the way of getting thinks done. To continue with your metaphor: if you are driving a Ferrari on a straight road, having to stop every 2 km or so to check if you are going in the right direction will only make you slower. But, yes, it will help (bad) managers to have a feeling of control.
    – Giorgio
    Aug 24, 2014 at 13:39
  • @Giorgio agree. As far as I can tell you got my metaphor perfectly right :)
    – gnat
    Aug 24, 2014 at 13:45

Agile forces programmers to do more useful work, because the various techniques of agile development weed out busy work and work that is just not needed.

  • 2
    Citation needed. That's a bold claim; I've seen a lot of busy work in "agile" environments.
    – user25946
    Aug 27, 2014 at 18:24

it is inconvenient to do all that procrastination when there are two of you sitting together.

I disagree. I worked with a group of smokers and they all managed to take their break together for extended periods because "everyone was doing it."

common to slack off in the first three weeks

This is a sign of poor management regardless of methodology. Even if a huge chunk is due in a month, I would expect to see something at the end of the first week.

you have nothing to say you may actually feel ashamed.

If you're willing to jerk-off for three weeks, you'll think of some bullshit to say.

4) Testing and feedback - again, it prevents you from keeping tasks "99% ready" (when it's actually around 20%) until the deadline suddenly happens.

Waterfall projects can have testing and daily builds.

Personally, I would hate to write code and not have anything done with it for a month. I prefer the shorter-feedback loop on my code whether it is a coded review or user sign-off. Having others approve of my work is rewarding. It's like the cat the drops a mouse off on your doorstep just to let you know she's doing her job.


Agile doesn't force developers to work more, but to work more efficiently

  • 1
    and more productive, which is semantically more important.
    – user7519
    Apr 26, 2012 at 14:09
  • Does it though?
    – Casey
    Feb 2, 2017 at 16:54

Phrasing the question 'forcing developers to work more' comes across a little negative, but surely it's positive if we actually get more done and procrastinate less?

That said, it's a good point. I've been feeling a bit jaded with agile this year but this is a huge unwritten benefit which I hadn't been acknowledging.

I would agree that agile can lead to developers being more productive. Your points about visibility, accountability, and tendency to procrastinate less are all very true.

But agile can and should also lead to developers working harder for positive reasons - the carrot vs the stick. Done well, agile will give developers more interaction with users, less beuracracy, more control over their work, all of which can lead to getting more from your team.

  • 1
    you are correct, Agile isn't about working harder it is about working more efficiently on the most valuable things. In my years of experience, it causes developers to actually work less hard because they have more realistic deadlines and deliverables; being much more productive in the same amount of time, this leads to * efficiency*
    – user7519
    Apr 26, 2012 at 14:25
  • No agile is not about making work more efficient (and it does not, considering all the meetings, sprint reviews, and so on) but more predictable: you do not set a deadline and then work efficiently to meet it, but rather, you monitor the process so that deadlines you set become more reasonable. So it is not about productivity but about predictability.
    – Giorgio
    Aug 24, 2014 at 10:07

more working is still not semantically correct or relevant to Agile, the goals is to be more productive. It specifically focusing on working less on the wrong thing, and more on the working normally on the correct thing; which doesn't mean working more, just more productively.

A side effect, is it does expose slackers and those that are in-efficient or in-competent very quickly. Which sounds more like what you are getting at.

Methodology is irrelevant on whether or not a developer is not working. Process is, even in waterfall, management reviews and code reviews can expose these do nothings as well, just not as transparently as most Agile methodologies.


"Guns dont kill people. People kill people!" It is the same with Agile. Agile does not make people work more, managers make people work more.

  • 2
    Managers don't make people work more. Clear visibility and rapid feedback make people want to work more, so they do. Aug 3, 2011 at 14:58
  • Yes, but up to what point? In one sprint you pick up 10 stories, next sprint: 15, next sprint: 20, next sprint:25. How long before the team reaches its human limit and the not-really-agile manager decides to take it higher. Maybe you have not faced such a situation. In a truly agile project you discover your teams velocity as the sprints progress. You may at the most be able to work with a 10% margin. Nothing more.
    – DPD
    Aug 7, 2011 at 11:14
  • 2
    On the successful agile projects I've done, we use "yesterday's weather" to schedule our iterations. However many points we completed last iteration are how many we schedule this iteration. The manager can cajole/yell all he wants, but the team decides what they are comfortable with and that is what gets scheduled. (Of course, we had director-level buy-in, which means that if the manager tried to force the team, he would get in trouble.) Aug 8, 2011 at 12:18
  • @Sean McMillan - Maybe a manager is not as much of a difference maker when a director totally buys into agile, but that's rarely the case.
    – JeffO
    Apr 26, 2012 at 16:22

Not the answer you're looking for? Browse other questions tagged or ask your own question.