Yes, developers are strange. Let’s just face it. Developers operate on a different wavelength than managers. Agile developers in particular tend to deliver in short cycles, listen for the client feedback and turn that into the next development cycle.

At the same time, management wants to know dates and costs. Asking the developers to estimate and then promising deliveries based on estimates fails miserably. Why is it so?

Falling Into the Trap

Mapping the management view onto development processes may lead to difficulties. And when difficulties begin to emerge, management often decides to strengthen the process control, only to make difficulties even more obvious.

And here is the rule of thumb: Asking developers for estimates and then putting those into a delivery road map is road map to disaster.

Things never happen that way, and estimates turn to be misleading. Managers then often look for rescue by turning to strict plan following mode. They micromanage every single developer’s activity, sometimes going into bizarre details. It all makes the development less efficient, causing even longer delays. This vicious circle quickly lowers the efficiency of the whole team, leading to further drop in motivation and many other undesired effects.

Agile Development Process

Through trial and error, we have learned that the development process should be simple. We all apply agile principles of software development, but the agility is sometimes compromised.

To keep the agility part alive in the agile project management process, we actually try to move managers away from developers. Managers are there to identify medium-term priorities. Prioritized tasks are then mixed with client’s feedback on previous deliveries to form the next development iteration.

From the development point of view, the world ends there. All the complexities of management processes, all the company-to-company negotiations, promises, strategic directives, they all live over the edge of the developers’ world.

Then How Does It Go With the Estimates?

When development is truly agile, its cycles are stable and regular. Very quickly, and that is in no more than two months, management can observe actual velocity of the team. By velocity, we mean the amount of features that can be delivered in a period of time, such as two or four weeks.

This measure is then used to roughly estimate how much time it would take the team to deliver certain larger feature. Negotiations with clients can then be steered by this almost trivial measure.

By putting the velocity into the equation, we are ensuring that the management will never feel the urge to directly manage developers. Consequently, efficiency of the development is constantly kept high, as well as the positive sentiment in the development team.