The levels of agility
Andy Singleton wrote about what irks him about agile. He has a few good points about how the marketing of agile has distorted the true essence and value of it.
But, first of all, come on, Andy, let’s not be ageist. One of the things he hates is:
Old people: Agile has the smell of death on it. If you go to an “agile” event you will see few people under the age of 40 and many over 50. These attendees are on average much older than the average age of programmers
It is not logical to dump on a state you will inevitably be in, i.e old. You might very well learn a thing or two from those that smell of death.
That said, I want to talk about what I like about agile.
Agile means so many things to so many people that is hard to even define what it means. I’m not going to attempt a universal definition. I’m going to talk about what “agile” means to me.
Here’s my definition:
To be agile means to have such a degree of control and understanding of the process by which you produce that you can make your output predictable (in terms of resources like time, people, material etc.) and can rapidly adjust the process to deal with changes in the environment (such as new requirements or contstraints).
For those who have a deep understanding of what it is, and how to implement it in a team setting, it works amazingly well. Like anything that works amazingly well, people want a piece of it. Like anything that works amazingly well, other people want to sell it. Hence the never-ending stream of books and hoopla and conferences and terminology.
Unfortunately, agile is often sold as a canned collection of processes and practices, and many think that blindly applying it to their context will make all their problems go away. No, it will not. If you just apply them like a script kiddie runs downloaded warez, without really understanding them or knowing how to tweak them, agile will not solve anything for you.
The same goes for agile “tools”, of which there are tons in the market. It is all too easy to fiddle with tools without getting any real results. It is not about the tools at all. I have seen experienced practitioners work wonders with nothing more than a simple shared spreadsheet.
Let’s look at the levels on the agile ladder.
- The pain and the need. The team is somehow making stuff, but it is chaotic and stressful, dates and deliverables mean nothing. If deadlines are met it is by sheer luck. I need something, some process, to bring some control and predictability to this.
Lightweight process. Iteration. The next step is usually to wonder if a process can help you. Most people, especially technical folks, have a disdain for process, and rightly so, because a process can quickly become an end in itself if not overseen by someone mature enough to realize that it is just a tool.
Fortunately, a lightweight process is all you need. This involves simple things like breaking work down into concrete chunks that can be estimated, fitting those chunks into timeboxed iterations (usually a few weeks), and people signing up for chunks in a given iteration. Just doing this much brings a lot of clarity to end-goals and the rough size of the problem being tackled.
When you start out with this, you will realize that you aren’t very good at it. Your estimates will be way off, often by as much an order of magnitude. Your chunks of work may not be well defined. You will probably end up missing things you signed up for in the iteration, and doing things you didn’t sign up for. This is expected. Each iteration, keep an eye on what you could have done better. Stick with it. You’ll get better.
The crucial idea here is that of iteration. You should try to get to a “walking skeleton” as soon as possible, and then add flesh to it every iteration. Failure should get exposed early rather than late. Which brings us to…
Visibility and automation. Next you get to what most people know of as the standard tools and practices of “agile.” Lots and lots of tests. Continuous builds and tests. Dashboards. Code metrics. There is a common theme underlying all these tools and practices–visibility and automation. Automation, because the more you automate, the more you remove friction and leave time to concentrate on the hard problems. Visibility, because the only way to even try to control a large, complex system is to gain visibility into it.
You can get a big fraction of the benefits of agile by getting this far. I call this the “fake it until you make it” phase. Plan iterations (even if the plans turn out to be lousy), set up a continuous build, get used to being green and keeping it that way. You will notice the chaos and anxiety slowly but surely replaced by a calm, confident velocity. There should be far fewer fire drills.
Control and adaptibility. The thing that separates the 99th percentile of guru agile practitioners from the others is an understanding of your process and how to tweak it. What if your requirements suddenly change? What if you realize that you fundamentally need to rework some significant part of your product? What if your team size is halved? Or doubled? How will your process absorb these environmental changes and allow you to continue building and delivering stuff?
There are no tools and practices for this. This just takes time and attention and gentle nudges in the right place.
One principle is key here, and it is one almost never mentioned by agile tool vendors. That is the theory of constraints. That’s a fancy of way of saying that your process always has a bottleneck, and that you should find it and focus on removing that one bottleneck. Repeat with the next bottleneck.
The two most common ways are to either put more resources to remove the bottleneck, or structure your work to avoid “backing up” at the bottleneck. For example, say you have ten devs and one tester. The rate of which your entire team can deliver reliable, tested code is limited by that one tester. You could either hire more testers, or start nudging your devs to test more.
That’s what agile means to me. Every team that gets value out of it uses their own unique variation of it, and that’s great. Take it on. Use what you like, throw away what you don’t. Pay attention to your team and your process. Don’t start by choosing tools. Take the word of agile “experts” with a grain of salt.