Pragmatic Agile Weblog

Agile software development in real life

The risk of nano-management

One of the things agile practitioners and advocates fight, at least in principle, is project micro-management that is often associated with waterfall software development. Agile methodologies replace the need of having a so hated project manager that controls and then commands any aspect of the team and project with an informative work place and process that encourages sharing also the status of the project. Having a release split in iterations and then user stories in each iteration makes it easier to everybody to figure out how things are going.

This is fairly true, at least looking at our experience, where the new process has been accepted with favour at all levels in the company. In fact, some interpret agile processes like chaos reigns and where any sort of planning is banned. At the contrary, because agile software development embraces changes, an agile process asks the team to diligently and regularly check where the actual plan is compared to the original plan. To do so, inefficient and always-out-dated gantt are replaced with attitude and “tools”.

The attitude of an agile team is to make a plan at the beginning of an iteration or release and adjust it over time. This must not mean that the team is not in any way committed to the plan. The team should do all it can to follow the plan, but the goal is not to adhere to the plan, but to deliver value. Even the concept of “plan” may vary from team to team or amongst different agile processes. The plan could be a sequence of tasks, an high level gantt or even just a prioritized backlog. The goal of the team is to deliver what they promised, the way they achieve it is team responsibility only.

There are also great tools agile practices introduce or make use of to help teams to better perform. One of the best one, in my opinion, is at the basis of iterative and incremental development: user stories. I believe user stories are a powerful tool in the hands of all stakeholders and teams because they represent the atomic (at least at a certain level) piece of work around which a number of other concepts are attached. The first one, for who, like us, estimates in story points, is the size. And when you have a size, and an iteration, you have how many story points the teams make in a certain amount of time, which is their velocity. With user stories and size you can track the amount of work done or to be done over time with burn down or burn up charts. With user stories teams can commit on definite amounts of work and make very clear what’s get done and what not.
In addition to what more related to the process, often agile processes bring a number of other techniques to develop better software or increase productivity. All this is completely under the light of the stakeholders and managers, and in my opinion this is a very positive aspect of agile principles.

However (you knew this was going to come… 🙂 ), stakeholders and managers must be trained or socialized on the real goal and meaning of this tools. Some of these tools are so easy to pick up and give so great visibility that I am sure all managers love them. But if the meaning of the tools is misinterpreted or distorted, than it becomes an issue, because something that you think is useful for your team turns against the team at managers’ eyes.

A good example of what I mean is velocity. It is so easy to associate velocity with productivity or team ability to deliver on time. It is a simple number that may go up, and you are happy, or down and you are unhappy. But if you take just that number, ignoring where it comes from or what’s behind it, than you can easily go off-road. For instance, let’s assume the team is going through a tough period, some features revealed to be harder than expected, more legacy code than expected required refactoring, and maybe the team changed its composition. The sum of these factors will certainly take down the team velocity. If you do not trust your team, you will probably start to think that the team is not able to deliver, so you trust them even less. When managers see (or perceive) bad results they have to react. It is their job and role. This can lead to a situation where managers, given the number of tools that provide so good knowledge of what’s happening in the team, can be tempted not only to start to micro-manage the team, but to even nano-manage it (“why this user story is so big?”, “are you sure it is 10 s.p. and not 9?”, “why are you working on this u.s. now instead of later?”, “can you send me an email with all task you have done at the end of each day?”, “the burn down is not going down, we need to work more…”, “shall we put more resources?”, “c’mon a normal developer would take half of the time to do this…”, etc, etc…)

I am in that category too and so I am the first one tempted to go on that path. Instead, I think we should resist that temptation and keep trusting the team. This does not mean of course to trust the team blindly. We must make sure the team understands there is a problem and therefore acts to fix it. The team must know very clearly what are the areas of concern and what the factors of unhappiness, but still they deserve respect for their work and trust their willing to deliver the promised value. They may need help, and here is what managers are for: to listen the teams needs and help them to see how to overcome the difficulties. Help is also challenging the teams and their decision, to help them cross-check their assumptions and decisions. But the worst thing we could do is stick an ideal burn down chart on the wall and teach the teams that that is what they have to do 😉

(or perceive)

August 14, 2009 Posted by | Agile, Software engineering | Leave a comment