There are many methods and methodologies that fall under the umbrella of “Agile”, some of them have become very closely associated with agility, and even seem to be treated synonymously with “Agile”. Yet as we have seen, the manifesto for agile software development consists of a few short statements centred around 4 values statements. There are also 12 principles that we will look at over time on this blog. Whilst those principles are important, they are less relevant to the point I want to make here. Given what the manifesto for agile software development says, how do we get statements like “Agile says…”, “Agile user stories” or “Agile meetings”? In my opinion the answer to that lies in what I have chosen to name “My Agile”. As in people who, have probably chosen to, focus on a single method or methodology.

There seem to be more and more people who conflate their chosen, or favourite, method(ology), with the only way to “Do Agile”. This makes no sense because you cannot “Do Agile”. Agility, based on the manifesto, is a few values and some statements that we treat as facts (The principles). You cannot “Do” values and principles, they are true or they are not true. Values and principles guide (Or allow us to evaluate) our behaviours and mindset. They guide how we should do things rather than being what we do. Consider the following “Do value individuals and interactions over processes and tools”. That sentence makes no sense. However, if we ask people “How do we know that you’ve chosen a way of working that values individuals and interactions over processes and tools?” Then that makes sense, and we can answer it. A good test for if “Agile says…” makes sense is to replace the word “Agile” with how we want to work. For example we might want to work in a manner as to be flexible or adaptive, so let us try that in a sentence instead by considering the following in the context of a daily meeting (As an example): –

• agile says that we should have a daily.
• flexible says that we should have a daily.
• adaptive says that we should have a daily.
• Scrum says that we should have a daily.
• Kanban says that we should have a daily.

Only the last two of those sentences make sense. We can be agile, flexible or adaptive and yet they cannot tell us what to do. In the same way Scrum or Kanban can guide us what to do and yet we cannot be Scrum or Kanban. We can however be an agile team, a Scrum team, an XP team or a Kanban team because the words do make sense in that context, albeit with different meanings. In the case of an XP team it is actually a team that uses eXtreme Programming values, principles and practices. The same would hold for a Kanban or Scrum team. Whereas in the context of an agile team it would be a team that exhibits the traits of agility, such as being able to adjust, move and understand quickly and easily.
By the way I deliberately wrote agile, flexible and adaptive without capitals in the bulleted list because they are not nouns and I wanted to underline that point.

We can be agile or not be agile, but we cannot do agile or not do agile. We can gauge our agility and become more agile over time. Imagine that agility is like a sliding scale from 0 to 100* and we are somewhere on that scale. The various methodologies can help us move up that scale. Some of the methods and methodologies we choose provide more support in this regard than others. Yet they can all guide us when we use them properly.

* Just to note: that sliding scale of agility keeps moving the bar as to what 100 is means. What might have been deemed as in the range 90-100 agility 10 to 15 years ago might be much lower today.

I suggest that we be open and honest and not try to shoehorn people into a way of working that muddies the waters of communication. If we want a team to be agile let us give them enough freedom to be ever more agile as they improve. If we want a team to be a Scrum team then let us help them use Scrum and to do so in the context of realising that Scrum is a process management methodology (The Scrum guide calls it a framework but it comes from empirical process control) and use Scrum to manage the process by which the team works and improve that process. The same holds for Kanban, XP or any other way of working.

In summary
Let’ us try and understand the different aspects of developing agility and the various methods and methodologies than can help us to get there. Then let’s find a way to work together and make the great aspirations around agility a reality rather than conflate terms and lose sight of the aspirations we really want to achieve.