“Are you agile?” is the wrong question

So agile is dead or dying you say. I think you are right as long as it is the label itself you are talking about. Everyone claims to be agile and everything is described as agile. But who cares? The important thing is not what you call something, it is the results you get. There is an empirical foundation that is the basis of “agile”. This foundation has been tested and proven to lead to better software of higher quality. No, I am not talking about the agile manifesto. The values and principles of the manifesto are too vague to be provable. You have to go further down to insights that are concrete, measurable and proven:

• Release often to production

• Strive to reduce code size

• Minimize time between the collection of requirements and deployed solution

• Allow for slack on both team and individual level

• Avoid breaking up good teams

• Minimize handovers

• Reduce barriers to change in requirements

• Let developers communicate directly with customers

• Avoid multitasking

• Increase visibility of work

In a later post I will explore the empirical basis for each insight. I am confident that there are more insights that could have been added to the list but this is a good starting point. There are also many empirically proven things that should not be in the list. Agile is not synonymous with “good”.

The right questions

Based on these insights one can formulate concrete questions that will give a more objective picture of how agile your software development really is:

• How often do you release to production?

• How much time is spent on reducing code size?

• What is the lag between definition of requirements and deployed solution?

• How much slack time do development teams and developers have?

• How often are team members added or removed?

• How many handovers are required in the process of solving a customer need?

• Are changes in requirements perceived as something positive or a problem?

• How often do developers communicate with customers or users?

• Do you have explicit limits on the number of parallel tasks that can be worked on?

• How large a proportion of tasks the team works on are made visible to others?

The baseline

As is so often the case the “right” answer to each of these questions depends on your context. There will be practical limits to how far you can go in each case. Maybe compliance makes it impossible to release to production more than three times a year? What you have to accept in that case is that you cannot have agile release management. Do not fool yourself into thinking that three releases a year is agile. So even though the “right” answer is context dependent, the agile answer is not.

Each question can be seen as one dimension of agile. Your goal should be to try to become more agile in each dimension as long as your context allows for this. Why? Because that will lead to better software of higher quality!

Niklas Björnerstedt

Posted on 2014.05.07 at 7:51

Comments are off for this post.