When you hear people talk about "Agile", what's the first thing you think of?
The answer will likely depend on your exposure to Agile (and opinion of it). For many people in the software industry, though, I'd wager that the first thing that comes to mind when someone asks you how to "do Agile" is something to do with either sprints or standups. I've seen this happen at multiple companies. "We want to start doing Agile, so we will now be holding a daily standup every day at nine-thirty, and we work in two-week sprints." Sound familiar?
If it does, then chances are your attempt at "doing Agile" isn't going as well as it could.
What is Agile, anyway?
There is something very important about Agile that teams get wrong, time after time. You'll note that I've put "doing Agile" in quotation marks. There's a simple reason for this: Agile isn't a thing you do; it's a thing you are. To put it another way, Agile isn't a process, or a methodology, or a way to build software. Agile, at its purest, is a philosophy. The original Agile Manifesto (still available at agilemanifesto.org) gives four value statements, each in the form "we value X over Y". The four values are:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
It goes on to say that the things on the right are still important, but the things on the left are more important. The site also lists twelve principles that elaborate on the spirit of the manifesto, but that's it; that's all there is to it.
This is obviously not a process you can follow - instead, it's a set of metrics that you can use to decide whether your process is a good one. If your process succeeds at delivering all eight of the things mentioned, it's perfect. If it tries, and where there are conflicts, it prioritises the thing on the left over the one on the right, then it's a good process. If it lets things on the right impede the things on the left, it's a bad process. The heart of Agile is using these metrics to make your process better - whatever your organisation means by "process".
On top of these core ideals, a great many frameworks and process templates have been built. Two notable examples are Scrum and XP (Extreme Programming), and the popularity of these frameworks means that many assume that they represent the Agile way of doing things. This is not strictly true. Scrum is an Agile way to do things, and XP is another, but they are not the only ways to be Agile.
Start Right By Finishing Right
So if Agile is all about applying metrics and making improvements, how do we get started?
Actually, the best way to start becoming more Agile is to not do anything. Or rather, to not do anything new. Remember, the primary goal here is to build and deliver software. Presumably, that's what you were doing beforehand, so keep doing it. Change is disruptive, and changes made blindly have no guarantee to be worth the disruption, so the worst thing you can do is to start copying pieces of someone else's process and hoping for the best. Agile doesn't specify processes or practices - it provides metrics, so keep working, and use them to measure.
Of the twelve principles of Agile, perhaps the most useful to a team starting their Agile journey is the last (which, as we'll see, is very appropriate). The twelfth principle is this:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
When starting to improve your Agility, the most effective step you can take is to simply pay attention, and then talk about how you're doing. In a Scrum-based process, there is a specific term for this: it's called a retrospective; a meeting at the end of each sprint where the team discusses the sprint with a view to improving their process. In general, a retrospective looks at three key areas:
- What things were effective or done well?
- What went wrong or caused problems?
- What can be done differently to improve?
By examining these areas - usually in this order - a team can identify which elements of their process need to be continued, protected, or expanded, while also digging into the causes of any delays or mishaps and proposing solutions or mitigating actions to try next time. Hopefully, in a later sprint the team will be able to point to those solutions as things that went well, but if not, the retrospective allows the team to acknowledge this and try something different.
Of course, when we talk about things being "done well" or "causing problems", we return to the Agile manifesto to make those judgements. The twelve principles tell us that "working software is the primary measure of progress", but a problem might not impact the software at all. It might be...
- something that makes it harder for team members to communicate ("individuals and interactions")
- something that is taking more effort than it needs to ("Simplicity - the art of maximizing the amount of work not done - is essential")
- something that is making the team or the software less flexible ("responding to change over following a plan")
The retrospective should be a safe space for the team to discuss these issues. The goal should be to solve the problem, not to apportion blame, and there should be no recriminations or backlash for speaking up. Equally importantly, the team should feel that speaking up is actually worthwhile - that changes they propose actually have a reasonable likelihood of becoming reality. One of the twelve principles of Agile spells this out clearly:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Part of that trust is to accept that mistakes are part of being human, and an opportunity to improve is a more effective motivator to a passionate engineer than a reprimand for failure. Another part of that trust is to trust your team with the ability to make changes to how they work (within reason). If your team is not empowered to enact the changes proposed during a retrospective, then the exercise is pointless and the team will quickly become demotivated.
If this is the only change you make, the addition of retrospectives to your existing process is the most effective route to becoming truly Agile.
Closing the loop
Your retrospectives don't have to be regularly scheduled events. Ideally, your retrospectives need to be frequent enough that you haven't forgotten half the things you would have wanted to talk about by the time one comes up, but far enough apart that you have time to make a reasonable attempt at implementing the changes that are suggested. Beyond that, it really doesn't matter when they are. They don't have to be at the end of sprints (you might not even have sprints) and they don't have to repeat on a set timeframe. You could have a retrospective after every delivery or deadline, or as part of your post-incident procedure, or just on an ad-hoc basis whenever team members indicate that they feel they have something worth discussing. This, too, is the Agile way of doing things: Agile values individuals and interactions over processes and tools, so you don't have to have a process for being Agile.
Of course, some of the changes your team proposes might be to adopt other aspects of Agile frameworks such as Scrum or XP, or to develop your own bespoke processes to follow or tools to use, and that's ok too - but it's also fine if you don't. Agile is not dogmatic or prescriptive, but it is a highly effective method for making your team better at whatever you do - however you choose to do it.Comments powered by Disqus