This is a back to basics post driven from a number of interesting conversations I have had recently.
Firstly here is my personal definition of Agile:
An umbrella term for the toolbox of light-weight methods, practices and techniques that are focused on working smarter, not harder.
So let’s break that quote down.
“An umbrella term” means to me that it is encompassing, or arching loosely over something.
“toolbox” suggests that there are tools within it. Like all good tradies (that’s Australian for tradespeople) they know which is the right tool to apply to the right problem. You won’t use a hammer to tighten up a screw.
“light-weight” I debated whether to use this in the definition or not – primarily because to some extent I believe that Agile requires greater disciple than ever before, then again, you can still be disciplined and have simple tools in your box.
“methods, practices and techniques” Most believe that Agile is just either Scrum or FDD or XP, but you are rarely ever using just one method (or model) by itself and in reality you are likely to pick and choose the methods, models, practices and techniques that apply to both your organisation’s culture, to the system, to the people and to the situation.
For me a practice is a repeated activity – stand-ups are good example of this, as are retrospectives. The line between practice and technique is where it gets really interesting. Let me give two examples:
- Prioritise work
- Plan your ability to deliver based on facts
So we can prioritise work in many ways – we can prioritise based upon value, based upon risk, based upon both. We can use MoSCoW, High/Medium/Low, we can have ordered lists – the techniques that we use to get to a position whereby we have a prioritised set of work are quite varied.
We can also plan our ability to deliver based on facts in a number of ways – we can pull in an iteration worth of points based upon the velocity of the last iteration, we can measure average cycle time and understand our variations. Again the techniques to get the answers are varied.
In both instances we want to regularly ensure that we are prioritising work and that we are planning (where needed) based upon facts.
In this context it becomes simple to argue that maybe Retrospectives, as an example, are not actually a practice and more a technique. In this mindset the practice would be “Evolve the way you do your work” and the technique would be “Retrospectives”. I could live with that. There are many different formats that retrospectives come in – deltas, sailboat, quadrants, timelines. You can also evolve how you do your work in many other ways.
This then leads to the debate about whether statements like “prioritise work” and “evolve the way you do your work” are more principles than practices. Ultimately, if you are regularly doing something that reaches that outcome in a repeatable way I would say it is a practice. I am happy to debated otherwise on this front.
“working smarter and not harder” Note what I don’t say in this definition – I don’t say that it is a software development approach. It can be used for software development, and works well for it, even was born from it, but it can be used for more – so why be exclusionary, spread the love! For this reason it isn’t about working software it is about working smarter. For me, working smarter means delivering value to customers in ways that have reduced waste, improved innovation and a very healthy respect for people.
So in conclusion – just to re-iterate, to me Agile does not mean Scrum. Scrum is just one single element of it. I like to think that methods, practices and techniques such as Kanban, Cynefin, Systems Thinking, Lean, Systemic Flow Mapping, etc all have a place in Agile.
Within Australia I have never seen us as an exclusionary crowd. We embrace better ways of working smarter. We like to absorb them into the Agile toolkit we have, a toolkit that should evolve and change over time as we better understand our world and what works and what does not. Most coaches I know don’t teach just one way, they teach a toolbox of ways and often subscribe to the Oath of Non-Allegiance. They have moved on from the Agile Manifesto and begun to embrace the MoreAgile Manifesto.
As always, all comments are welcome but I desperately desire feedback from the Australian Agile community – what do you think: are we embracers of evolutionary Agile or as a community we are stagnant?
