A Return To First Principles

It's always good to go back to first principles occasionally so let's take a look at the agile manifesto. How does it go again? Processes and tools over individuals and interactions... No wait, that's not right. It's the other way around. But anyone observing the agile community over the last few years would be excused for thinking otherwise. For a group that follows a manifesto that explicitly prioritises individuals and interactions above processes and tools, we certainly get very hung up on processes and tools.

Be warned...this is a bit of a rant so you might want to stand back to avoid getting any on you.

For the last few years, the majority of the conversations I have had with other agile practitioners have been about processes and tools. Are you a Scrum or Kanban person? Do you prefer safe or less? Rally or jira? My response has typically been that they are all valid and I will use whatever is appropriate to best support the individuals and their interactions. Recently my response has started to shift towards violently banging my head against something solid, as it's more fruitful than yet another safe vs less argument. At least there is a chance that I will render myself unconscious and not have to hear yet again how less is "more agile" than safe or vice versa.

The Agile community has been drawn into a series of increasingly bitter (and pointless) methodology wars. I think the rot started to set in with the Kanban vs Scrum debate a few years ago but it has reached peak stupid with the less vs safe vs DAD vs whatever debates that are going on now. And lets not forget the "Agile is dead long live <whatever next big thing they are pushing> crowd. We now have conference papers, blogs, podcasts and all manner of artifacts from proponents of one methodology, whose only point is to take shots at their competition and competing papers, blogs, podcasts and whatever, firing back the other way. Massive amounts of time are wasted in organisations deciding which agile methodology to standardise on, based on sales pitches from consultants.

In day to day coaching, it seems that we are increasingly being asked to implement methodology X rather than teach the organisation how to change in the way that best suits it. We are helping organisations do agile rather than helping them become agile.

In the very beginning of George Orwell's Animal Farm, the animals paint the guiding principles of their new society on the wall of the barn - "All animals are created equal". Of course by the end, the pigs have altered the sign to read "all animals are equal but some are more equal than others". In the agile world we have "individuals and interactions over processes and tools" but there is a large crowd of people wielding paintbrushes trying to add "as long as you use XXXX". The debate seems to be what XXXX is, rather than whether the change should be made at all.

This is not good. This needs to change. As a community we have lost sight of our guiding principles. It has become all about the methodology.

Let me make my views on this very plain (if they aren't already). Processes and tools are there to support individuals and interactions. The organisation should adopt a process that best supports its individuals and helps them interact in useful ways. That process should evolve and change as the organisation evolves and changes.

The pre-canned methodologies we have now - SAfe, Less, etc - are useful starting points. They have lots of good material and training that can help an organisation start the journey. But the journey is always towards agility, and not towards adherence to the methodology. They are a starting point. They are not recipes for automatic success that have to be followed to the letter and standardised on. They are not end points.

The organisation should evolve and change its methodology. Actually, I'll go further - if the transformation is to be successful, it must evolve and change its methodology. Otherwise the new agile methodology becomes just another process millstone around the necks of the teams as they struggle to deliver value.

Oh, and by evolve and change, I do not mean waiting for the inner circle of the chosen methodology to emerge from its secret bunker and reveal version X+1 in all its glory. I mean that the organisation should organically review and modify the process it uses continually. If they are doing safe or less out of the box 6 months after they first start implementing, then they are doing it wrong. If their teams are doing out of the box scrum, as taught by their coach, 6 months after starting, they are doing it wrong.

So what can we do about this? How can we reverse the trend? I think we need a principles based approach. What do I mean by that? Let's look at cooking as an example. There are two types of cook in the world, those that follow recipes and those that don't. I'm in the latter camp. I seldom, if ever, use a recipe when cooking. I read a lot of recipe books, I just never use the actual recipes. I use the books to discover general principles about cooking that I can use to create recipes on the fly. These flavours go well together, this technique creates this texture and so on. Other cooks, though, have to follow the recipes because they don't know the principles. They don't have the underlying knowledge they need to change the recipe so when they want the cake to be a bit moister or want a little vanilla flavour, they need to search through recipe books for a cake that is the same as the one they like only with more of whatever it is they want. They often end up trying recipe after recipe to try to get the perfect one. 

They also can't adjust recipes for local conditions. Every oven is different so my 20 minutes at 180c will translate to 25 minutes at 180 or 20 minutes at 200 in different ovens. If all you can do is follow the recipe, and can't make the adjustment, most of the recipes you get from cookbooks will not work as expected. 

At the moment, in the agile community, we are recipe followers. We do scrum. We do safe. We do less. We do kanban. We do these things by the book because we don't know the underlying principles that we can use to construct new processes. Particularly at scale. At the team level, we are starting to uncover the general principles that make teams work and interestingly, the methodology wars in the team space seem to have largely died down. Once mortal enemies, scrum and kanban seem to be coexisting happily in many teams.

What we need to do as a community is look beyond the recipes and start uncovering general principles that make scaling successful. If we can do that, we can end the methodology wars and move back to supporting individuals and interactions.