Does Agile force developers to spend more time actually working?

Question

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?

Answer 1

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!

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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

Answer 10

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.

Answer 11

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.

Answer 12

"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.