Developers don’t like Agile

Agile development seems to be the silver bullet for better development, better products, more focussed teams and improved product delivery. Developers love it because they finally get realistic plans from management which they can actively influence. Estimating the actual amount of work that needs to be done says good bye to unrealistic plans and creepy schedules. Suddenly they control the process and it no longer controls them.

This is what books, blogs and agile evangelists tell us. Reality however is very different. Agile development makes the life of developers much harder. First they think that they gained freedom and then they realize that this actually comes at a high price. They have to take responsibility and others start to think agile too. Suddenly product management can change their minds. It is even a central part of the agile process. This doesn’t sound anymore as cool as only build what we know we need.

The great days of coding all day are gone. You have to figure out what to code first. Try out many different approaches. Throw away that great implementation you did last week. Find out after a sprint that you totally went the wrong direction. Weeks of work for … nothing? You have to do it all again … and again. There are no perfect plans any more. Suddenly the people who told you exactly what to do say “Well let’s try this in this sprint and see where it takes us”. Developers realize that while they can define the stories it is the product owner, who decides what is important.  They are expected to take more responsibility and what did they gain?  Less security, more pressure and the inherent feeling that nobody has the ultimate answer any more. They arrived in the true reality of software development. Agile starts to feel like working on a galley ship rather than being the ultimate freedom for developers.

They wish back the great times of their waterfall development times where everything was like in a fairy tale. They got everything pre-defined and things simple couldn’t change but the process did not allow it. They could blame somebody else when things went the wrong direction. Now it is their decision. Times were much less stressful when you could plan everything ahead of time.  The products might not have been great, but life was.

So here we stand between an easy going life and great products and hard work. Which path do you choose?

4 thoughts on “Developers don’t like Agile

  1. GaryF

    Well I’d love to say I agree with this essay but I think somehow this is a ruse to create a reaction!

    I think the key point here is that the Product Owner holds the purse strings. So long as the developers are feeding back that there’s technical debt with an earlier decision and providing there are good Unit Tests (Test Driven, I hope), Acceptance Tests, etc, then all should be okay for quite a while, The key problem is when a Product Owner in a successful and growing company only sees the latest new revenue-generating feature, and fails to hear developers moan that it’s all wrong and the story going to increasing take longer because nobody has the guts to push back to the Product Owner.

    Also remember that for new features, the onus is on the developers to ensure continuous improvement to the application they are working on is planned into each story (where relevant)

    I think Agile is great – it keeps people focussed and if you’ve got a great team doing agile, the sky is the limit. True, people need a rest from time to time, but again, if the team are pushing too hard then it’s a simple case of adding a just a bit of slack in the task estimates. Remember they’re estimates, not commitments!

    I think the ingredients / chemistry to a good team has to be there for Agile to really work. It’s al about feedback loops. Waterfall drastically fails here unless the domain is well understood by all parties.

    1. admin Post author


      I sure think agile is the best way to develop great products. It is however also the most challenging one. Everybody has to take more responsibility and the risk gets shared amongst all team members more than with any other development approach. It is the point when developers suddenly see that they are now responsible for what they were used to be told before when the team as whole has to level up. It is one of the most critical things to make a team successful.

      I agree that product owners must listen to development concerns about technical debt. Who except the developers know, when this is the case. A lot was written about that topic. I think there is no easy answer how to address this in any situation. I believe no sane product owner would kill a product for a single additional feature. (If you want to write a short essay about this, I am happy to post it)

  2. Pedram Hadidi

    I choose Agile too.

    I think, agile is just a “tool” made of concepts and rules (like the car traffic).

    It is also very important how the members of the “car traffic” eg. software designers, developers and teamleaders use this “tool”, and if they change/adapt their attitudes to fit in (do they stop when the traffic light is red?).

    Imagine, you have two teams A and B.

    The leader of A is a softwaredeveloper too and can ask relevant technical questions and understand the concerns (often technical details) of his team members or reported issues.

    Now imagine the leader of team B has no clue about software, software-design, software-design-process, good software-testing etc. He is “just” a projectmanager.

    Question: Where would agile be the right concept to fit in, and why?

    Kindly regards,

    Pedram Hadidi


Leave a Reply