This Agile has a capital A. It can also have a lower case a, in which case it is an adjective, to be lean/nimble but that’s not what I’m talking about. Agile with a capital A is a noun, a name used for the philosophy described in the the Manifesto for Agile Software Development and the suite of methodologies primarily used for software development such as SCRUM and Extreme Programming.
Tim’s post on Agile as a ‘Cargo Cult’ highlights a problem in the adoption of Agile, not only for software development but for creative and business processes. Everyone is trying to adapt to a rapid and disruptive world screwing with business models in every category. Organisations are looking to close the gap with nimble digital start-ups who are out-innovating them at a fraction of the cost-base. Agile seems to offer a well-packaged magic ability to compete in a new way.
Unfortunately, a lot of confusion happens between being Agile as an adjective and a noun. Without understanding both, without the philosophy of being nimble and the processes of an Agile methodology, failure is assured.
At its best Agile is fluid and rigorous, it can be more controlled and structured than a waterfall project but open to adaption and change. There is a necessary tension between the rigour on one side and it’s resistance to codification on the other so the more you try and practice Agile the less agile you become.
When it comes to adoption lots of people suffer from the McLuhanesque mistake of appropriating the shape of the previous medium as the content for the next (props to Scott McCloud). In this I mean that they try to fit some of the rhetoric of agile around their existing people, culture, process and tools. This normally happens in one of two ways:
Taking the tools of an agile methodology (say SCRUM) and fitting them inside their current philosophy and culture
This is traditionally seen in large bureaucratic organisations looking for “productivity” improvements, certainly in their development departments. Generally their CTO has read in Computer Weekly that everyone is doing Agile and that if they only adopt it too vast riches can be theirs. Alternatively they have been nagged long and hard by everyone below them who wants to do it the way the cool kids do. Either way they know they need to become “Agile” or risk becoming a dinosaur shortly to be replaced.
So they do iterations, they buy an expensive tool-set and get some highly-paid consultants to codify an agile processes for them. Soon they are following the motions but not the philosophy. Hour-long daily standups, a written document for each user story and elaborate attempts to measure velocity.
But what they missed is that these tools only work when fitted with the philosophies of self-organisation, valuing individuals and interactions, customer collaboration and responding to change. It’s easy to know why, because changing a culture is so damn hard!. Getting the benefits of Agile needs Talent, Talent, Talent so you need to invest much greater time in people not processes. Then protect the hell out of them as the forces of bureaucracy move in for the kill. As often as not when you want an Agile team/project runs into a problem with lets say a contractual lawyer you need to change the lawyer not your philosophy.
Janusz Marcin Gorycki has a great blog post Agile is Dead on how this anti-pattern might greatbe killing Agile. Laurie Young of New Bamboo has also done a great post on FrAgile, the evil twin of Agile which makes one of the most important points in that Agile is just as much about producing a continuously improving team as producing the output.
Believing the philosophy of Agile with no tools and processes to help you work deliver the actual work
Hey man, Agile is cool. It’s all about working iterative and being open to change and having no documentation. It’s like a party in the office and everyone is invited.
As Tim said in his post:
Rapid, iterative, profitable, engaging… blah blah blah. Who doesn’t want to put a thick ‘done’ tick next to each of these on their to-do lists?
So often the adoption of Agile leads to, well, chaos. No one knows what they are doing and everyone is running in different directions changing everything and nothing gets produced. Sure they interact a lot but have no process for actually producing output. This can often happens in processes and companies where they are not all about development and don’t have a strong codified toolset to use.
What these people are lacking is a toolset to use to make their existing processes work with this new Agile thing. And as Agile is not only about the continual improvement of a product, but the continual improvement of a team it is also about the continual improvement of the process itself. Agile is not a static object, it should be continually changing and improving like a self-mutating sci-fi virus poised to take-over the world that can only be stopped by Nicolas Cage (straight to DVD). These people often lack enough understanding of how the philosophy relates to the tools to create new tools of their own. It’s taken software developers many, many years and many failures to come up with some working tools that can be taught to others.
I never have believed in pointing out problems without offering solutions. So I have a few thoughts and ideas.
Agile, at its best, is like a professional sports team on the field of play. It is a dynamic, interconnected, self-organised structure that has a strategy to work in, set-pieces and tactics but it can adapt and evolve. It can work its way fluidly down-field, a powerful, talented collection of people who play in a certain way but without a strict chain of execution. A goal doesn’t always come by a defender passing to a midfielder who passes to a striker who scores. It is a Barca, an Arsenal and the ’74 Holland team. This can be what makes it hard to understand because sometimes you need to be the hardline coach and sometimes you need to just let go, let the players express their talents. As any kind of leader this requires a degree of emotional intelligence.
For the first anti-pattern I recommend killing yourself. No, not really but if you are not willing or able to really invest in the talent, fight against the forces of bureaucracy attacking you and truly change your culture then don’t do Agile. Go back to linear waterfall, you will be more efficient honestly. If you still want to try Agile, then don’t give up and remember removing a bit of process or a bit of documentation is not a loss, it’s agile. Make as simple as you can, then make it simpler.
For the second anti-pattern I totally recommend immersing yourself in how developers have made Agile work for them and take what you think might be useful. Remember that you need to keep a tension between change and delivery and then keep delivering value, all the time, every week. Demonstrated, testable value. If you have a linear process which you want to be responsive to change, then look at the process chain and think about all the things that need to be redone if you want to change the output at a point in the chain, then minimise these effects. Remember make decisions at the last responsible moment and become more responsible. Mostly though invent something and try it out live!
Two of the most interesting questions for me is how is Agile going to scale beyond a team level? and how well can it be applied to processes outside software development? At Made By Many We have made a lot of ground in Agile interaction design but there is obviously much more to do and tools to create.
You are going to need processes and philosophy if you want the best from Agile. You are going to need to invest in people but you need to commit to making it work and keep committing. This is not a time for half-measures, it’s a time for Agile heroes.