Is Agile MicroManagement?

I came across this very funny question recently. And I refer it “funny”, because I find it so.

From experience of working in Agile environment for years now, one thing that I found common in all failed agile projects is that the project teams always blamed it on the overall methodology and associated processes and none of them appreciated the fact that they never got the Agile understanding the right way. And at this point in time, I want to go back to something I read about Agile. It goes as below:

Agile is like teenage sex

Everyone says they are doing it.

But most probably, no one is doing it.

And whoever is doing it, is not doing it right

 But fact remains that there are project teams that tried Agile and failed. And they strongly feel the failure was completely because the way Agile is set up – “Well … it exposes the entire team to the customer with little or no ability for the project manager to manage the situation. There is way too much of involvement from the customer. So much to get done in 2 weeks and with ‘welcoming the change’ philosophy, developers are always on their toes. And QA gets so little time to test in 2 weeks. To top it all, customer has so much of visibility into everyday tasks that they are actually Micro Managing the Project Team”.

 Hold it … right there!!!

 I hear some souls nodding their heads and saying “absolutely … every word related to the project failure justification is true”. And I don’t blame them. That said, it's not that I agree with them. But when I say, I don’t blame them, my point is – what’s the point in blaming a kid who wants to play with fire and burns his fingers. First the kid does not know it's fire, second it does not know it will burn, and third it does not know how to use fire the right way. And ‘fire’ here is only the analogy and not a parallel between Agile and real fire. Given the choice, I would like to call it Ice than fire. But then you might not get my point.

 So basically, if you do not know how to use a tool, you probably are going to use it the wrong way and break it further than not using it at all. So here is what I have observed on all failed Agile projects.

1.       Are we practicing Agile or we are Trying it out? There is a big difference. You would say, if someone is doing it first time, then they would definitely try it once before practicing. Fair point. But when you try it, you do not have to give it up with one or two failure. If that was the case, Edison would not give us the light bulb. So if you know you are trying, then limit it to Trying. And if you want to practice it, then first understand the right way. Don’t confuse between Trying and Practicing.

2.      Agile Project Team – the keyword here is TEAM. So it's important to understand if the project team was working like a team or was it a group of individual performers busy completing their own work. This assessment needs to be done during the course of a project, during the course of a sprint. A post-facto analysis will not help and will produce biased results.

3.       Most importantly, did the Team and everyone on the team understood the Agile the way it should be? Did you really understand the importance and intent of a process or did you go Verbatim way? Do you believe Agile says no documentation or do you understand Agile calls for only necessary documentation? Do you believe Agile means produce as fast as possible or do you understand “as fast as possible expects you not to compromise on quality”? Do you believe delivering on commitment is critical or do you understand that you may go wrong on commitment but what you can deliver – though below committed levels – should be with TOP quality? Do you believe that customer is allowed to make changes or do you understand when to say NO to these changes and recommend the customer to wait till next Sprint? Do you believe Stand up is a status reporting meeting or do you understand it to be an opportunity to collaborate and communicate? And so many beliefs versus understandings!!!

4.      Your customer cannot manage you if you manage the Process. Does your customer understand their role? Do you communicate it to them regularly and frequently? Is your team mature enough to give a necessary push back in line with defined processes? Is your customer trying to get visibility into your Sprint or are you providing maximum visibility to your customer so that they do not have to try to. Is your Sprint Backlog a sequence of tasks or does it provide the clear visibility into your plan to get something done?

5.      Do you have right skills on the team or are you trying squeeze in some non-performers for higher margins? Does your team understand the processes or do they even understand the importance of the same?

And many more such questions you would need to answer, before you blame it on Agile next time.

Hope you would find these answers. And if you could not, just reach out!!