Agile doesn’t fix anything! So why should I use it? (Part 1)

Before you start to read, one request – kindly please remove your agile coach hat (if you are an agile coach) and please try to put yourself into position of a “stressed waterfall developer on the ground” who has been asked to learn agile. 

Recently in one of the training sessions, one of the participants said that he wasn’t convinced why he should start learning and using agile. Probably it’s the training’s fault? May be…However, here were some of his contentions – 

1.   Agile doesn’t fix person dependency (Only some people know certain things)

2.   Agile doesn’t fix people’s egos and hence politics in the organization

3.   Agile doesn’t fix lots of ad-hoc / unplanned work which keeps coming to the teams

4.   Agile doesn’t fix poor leadership and management problems

5.   Agile doesn’t fix false commitments to customers with fixed deadlines

6.   Agile doesn’t fix people’s engagement during large programs

7.   Agile doesn’t fix collaboration issues between departments of an organization

8.   Agile doesn’t fix attrition issues when we lose some good people and teams keep changing

9.   Agile doesn’t fix this loss of knowledge and cost of bringing up new teams again and again

10. Agile doesn’t fix communication issues across geographies / cultures

11. Agile doesn’t help with “accurate estimates” on large programs

12. Agile doesn’t help with “precise requirements” on large programs

13. Agile doesn’t help with “the right solutions” on large programs

14. We anyways have to figure out all of these gaps eventually and then scramble for it

15. Our customers are not interested in seeing something every 1 month, for us lead times are long enough, there is no urgency of getting something done every few weeks

16. Most of these problems are known to us already, nothing new that we are uncovering!

17. We can fix these problems on a waterfall approach also (if we want and decide to!)

We already know that our estimates are off, we drain 30% or more in ad-hoc / unplanned work, we already know that our organization has become a mesh (or mess?) of several departments, COEs, horizontals, verticals, shared services, thus making it more painful to get something done than actually filing our income tax or getting govt sanction for our new house’s plan! 

 Agile might show me these problems early (by the way, I already know them!), and it hardly does anything to fix them? So, is it worth going through all this pain of agile transition when we can fix most of these problems without moving to agile also?

Well, one can always counter all of this. However, for now, let’s leave that aside. In this part 1, let’s empathize with this “stressed engineer” on the ground who has even more stress now to deliver something every two weeks (with no bugs – wow!) especially when he doesn’t know how that can solve any of his already known daily problems? 😊 I hope, you may “feel” that this developer is right from his point of view!

We will leave you with these views for now. Please feel free to share your thoughts. We plan to explore some insights on this topic in the “part 2” of this post. 

Finally, my sincere thanks to @ Erez Tatcher for his help and guidance while writing this post.