Agile Wonderland

I'm a software developer. I work professionally since 2007 way before agile principles were applied as a religion in almost every software company. In that old times waterfall was pretty much the way people worked. You setup a plan at the beginning and then you stick to it till the end. Well, at least this was the plan, but then, reality arrived. And the reality has teach us that the premise that you can define an initial plan, that will hold no matter what, is a false one. And people recognized, since they can't change the problem, that could be a good idea to review the methodology. Sounds reasonable, right? This simple problem, the uncertainty regarding the evolution of a project, is a consequence of a simple fact. Projects evolve. Yes, like species, projects tend to be defined initially with a set of broad requirements that will evolve, and here we mean the darwinian way of evolution. We can see the project as the world and the requirements and features as species that live in it. Species get extinct, a fish mutates into a bird and monkeys drop lots of their fur and become humans, so does the software requirements. Software industry recognized this simple fact and start to change the way things were done. These ideas were written in a 10 commandments way in the agile manifesto.

The companies since then start organizing in a way that these principles were applicable. Nowadays you got a bunch of tools simply to help teams to apply agile principles. The ironic thing is that the very first principle is Individuals and interactions over processes and tools. Nevertheless, if the tools help people to interact and organize their work these tools are complying with the agile purpose. Another interesting concept is the key performance indicator, or for short KPI. What and why is this important in software development? Well lets imagine you are Ayrton Senna, so the best F1 rider in the world, even you know that if your car aerodynamics and engine performance is significant worst than that of your competitors then you are fighting a lost battle. What does that mean? It means that every detail counts and that you need to improve every single thing you can. Well, this rises a question. How do you know if you can or need to improve and what. The answer is metrics. You need to find a set of key quantifiable points and tune the performance of those. How does this applies to software development? You can look at the software development team as a F1 Ferrari. Well, maybe not so red and beautiful but almost as fast (we wish).The team is the engine of the creation of software and so you must have ways to measure the performance to be able to improve it as well as a way of monitor for eventual problems the team might be having. In software development KPIs are a way of diagnosing problems, pretty much like your blood pressure is a KPI of your health status. Till now things seem ok. The problem rises when people misunderstand an indicator and give to it the value of purpose to be achieved. This can be as hilarious as tragic, you choose based on your current mood. I know of a case in which a KPI called predictability, that is nothing more than the variance regarding the amount of work done being the mean the amount of work estimated. When this indicator is high it means that the way you plan things are not being followed and that the team is systematically doing more or doing less work than that that was planned.

How is this a problem? Well since the amount of work is equivalent of man/hour work and this can be mapped into salaries, this means that its hard to estimate the amount of work to do things and this increases the risk of the project. People know that at the beginning teams have low predictability (or high variance) because the degree of uncertainty and unknown is high and so nobody gives much attention to it. However to more mature teams it is expected a decrease in the variance, and by definition higher predictability. But is this assumption valid? The degree of mature of a team is the only thing that influences this indicator? The truth is that the maturity of the team is a fancy world to express a very complex status quo of the team. A team becomes mature because the members know well each other, know well the project they work on and as a consequence they got a better degree of what is done and of what is needed to do something. So it is not difficult to understand why mature teams are more predictable than newer ones. But, why am I saying this? Well pretty much because people keep misunderstanding mature team with an old team. An old team is one that those members are working for a long time together.

Its true that many old teams are also mature teams. But the point here is that not all old teams are mature teams. And, additionally, it doesn't mean that the fault are on the developers because most of the time it is not. If the project suffer lost of members, or the nature of the project changes in a drastic way that set of people will again, constitute an immature team. If a team of java developers start working in a c++ project they will constitute a very immature team, no matter how many years they work on together simply because their knowledge about the problem to be solved is very low. So the concept of mature team is not equivalent to say a bunch of guys working together for a long time. It is much more than that, and people, mainly those who are working in management, those that should be the first ones to recognize this triviality fail in doing so.

But, when is all this tragic? It is a hell on earth when management people don't recognize these points and start using metrics as a way to influence directly the teams. When people put an indicator as a performance goal this is simple incompetence talking and that is sad. It is like saying that you, as a mechanical engineer, will be evaluated not if your engine is the most reliable and the most fast on earth but if you were able to build it in ten sessions, and in each session you completed, in a very predictable way, part of the engine. This can be tragic or hilarious, again, you choose..