How to train your Agile

9 mins
,

Modern Scrum is a certification-laden minefield of detailed practises and roles. To legitimately describe oneself as a Scrum Master or Product Owner involves an expensive two day certification class taught by someone who in turn took an eye-wateringly expensive Scrum Trainer class, from one of the competing factions of “Professional” or “Certified” (but ironically not both) schools of Scrum training. But it was not always so.

What led to the plethora of practises, religion and superstition that surrounds modern “agile” methods? What follows is an amalgam of what may have happened. It is the result of my conversations with a number of early agile practitioners along with my own experiences as both an in-house and contract developer during the 1990s. It is, as they say, “based on real events”.

The earliest agile projects, or at least those projects whose participants would describe them as agile, started with a single constraint:

We will deliver something, fully-functional, into production, in 12 weeks. What’s more, we won’t just fly blind for that time, we will sprint to halfway, pause, course-correct, then sprint to the finish.

So the first sprints were six weeks long. One sprint, pause, another sprint, release what we have. Nowadays this seems like an insane amount of time to run without checking in with the plan. Six weeks without even a showcase? That’s irresponsible! Back then, in the early 1990s, it was considered equally insane but in the other direction. Six weeks? You can’t possibly do anything meaningful in six weeks! This was in an era when 18 months between releases was pushing the envelope, and a multi-year software project on a monster Gantt chart, with a single release at the end after many months of integration and further months of testing, were the norm in large organisations.

Breaking the model

Chris Matts, product and portfolio management consultant and father of Real Options, uses the term “breaking the model” for introducing a constraint that exposes inadequacies in the status quo. “I’m sure we could improve this system of work, so how could we break the model?”

If you ask a team to target 16 months instead of 18 months for the release, they will try to do whatever they do now but harder. They might start working longer hours or occasional weekends, cutting corners here and there, squeezing a few percent more out of their practises at the expense of their health or sanity. When you introduce a constraint of a 12 week release with a showcase halfway through, they have to radically rethink their approach. They expect a feature to take months to analyse, design, code and test. All these activities are specialised and we batch them up, so we do all the analysis and then start on all the design. Frameworks like RUP blurred the boundaries, so “construction” was supposed to start while “elaboration” was still ongoing, but the all-or-nothing thinking was still steeped in its civil engineering roots and RUP was distorted into another heavy gated process.

New tricks for old dogs

Waiting for the analysts to finish all the analysis and the architects and senior programmers to finish the high-level design and functional specifications clearly wasn’t going to work. “12 weeks? This is crazy!” People assembled themselves into cross-functional teams that could autonomously analyse, design, code and test a single feature. The features themselves were sliced into work bundles that could be reasonably achieved in six weeks with some kind of business outcome at the end. Monthly status meetings weren’t going to cut it in a six week “sprint” so they started meeting more frequently. Weekly at first, and then daily as they realised how much they could drift in a week. “Six weeks? This is nuts!”

These people had never had to collaborate with the other disciplines before. Requirements were handed from analyst to technical architect in a formal ceremony involving the shedding of blood and the summoning of the Governors. Similar ceremony surrounded the hand-off of detailed functional specification from architect to humble programmer, and so on down the line. There was suspicion, mistrust, but mostly ignorance of the other roles.

A little help from our friends

The mavericks who had suggested the 12 week release found themselves in a coaching role, helping the people work together as a team, identifying and removing impediments, making suggestions as the team organised itself around this new way of working. If the daily huddle was like a rugby Scrum, then this person was the Master of the Scrum.

Similarly, most of the team had never thought about the end users of the systems they were building. The programmers were too busy converting the functional specifications in their in-tray into code modules in their out-tray, the testers were too focused on working through the test specifications and keeping to the testing schedule, and so on. So another role emerged, owning the holistic view of the software product, a Product Owner if you will. This person would help the team members understand how their work contributed to the product as a whole, and how this product would deliver value to the wider business. This meant the team could make trade-offs of options for the technical solution, prioritise which features made sense to deliver first, and which ones went together.

The first release wasn’t an impressive affair, but it was a release, and it contained actual working features. And the team was hooked! They had transformed a business need into a set of features that met that need in less time than they used to spend writing the requirements document! No wonder they started calling themselves “hyper-performing”. Nowadays we might think of a six week sprint or only releasing once per season as primitive, but back then it was truly game-changing. And then a funny thing happened.

The start of a religion

There are two ways a community defines itself. A centred community forms around a set of values or ideals. You can be closer or further from the centre but there is no sense of “exclusion”. A bounded community defines itself by boundary markers. These may be specific words they use, clothing they wear, ceremonies they carry out or foods they eat or avoid. Adherence to these boundary markers determines whether you are inside or outside the community.

Bounded communities tend to obsess about the boundary markers and can lose sight of the original values and goals of the community. It is easy to attach a political agenda to the boundaries, which is when religious or tribal factions emerge, then they use the boundaries to justify censure or even violence. More extreme factions adopt more extreme boundary markers, and any violation of this increasingly involved code is denounced as heresy. This is also an effective way to grow the community. Membership of the community is seen as desirable, or in extreme cases as necessary for survival. “Swear allegiance to us or die, heretic!”

Bringing this back to software methodology, one of the most effective boundary markers is certification. You either have a certificate or you don’t. You are one of us or you are not. Once the tribe grows large enough, certification is seen as a valuable end in itself. The more certified professionals we have, the more capable we are, surely? The lucrative nature of providing certification means the certifying body are happy to reinforce this belief.

The what without the why

Boundary markers often start out as good advice that a community adopts. Eating pork or shellfish in the Middle East in biblical times was a fairly risky thing to do! And draining the blood from an animal before eating it–a trait common to Jewish and Muslim faiths–would have been a good way to remove most of the dangerous bacteria in an age when people knew little about food hygiene or health.

Checking in with the team every day makes sense to keep on track, and having a short list of upcoming work means everyone can see what the latest priorities are. But these good ideas have morphed into rigid structures and ceremonies.

These days Scrum has become the dominant agile method. For anyone who has been in the industry less than 15 years, “Agile” has always existed, and mostly as some variant of Scrum. Teams made up of testers, analysts and developers are normal in many companies, and most people have a decent idea of what they are building, why and for whom. Having a Scrum Master in this context is anomalous, as is the idea of a Product Owner, so we find ourselves in a situation where the tail starts to wag the dog.

A team with a Product Owner absolves itself of responsibility for product prioritisation decisions because the Product Owner does all that. The Scrum Master takes on more of a traditional project manager role, tracking and reporting progress, and cajoling the team to go just a bit faster, try just a bit harder, as though they wouldn’t think to do that on their own.

That doesn’t mean we don’t need coaching, or we don’t need product prioritisation. Product ownership is a team activity, in the same way code ownership is a team activity. If the entire team doesn’t have a sense of ownership of the product and its purpose, how can they be genuinely self-organising around that purpose? Having a product specialist to coach the team is as valuable as having a testing specialist to coach the team in testing. The failure mode is to absolve responsibility onto that specialist, which systemically depletes the team’s capability in that area.

Inspect and adapt

The original motto of Scrum was “inspect and adapt”. These days I see little inspecting and adapting and much blind adherence to process. Maybe it is time to cast a critical eye over each of your “agile” practises and ask yourself a few questions:

What is the intent of this practise? What should it give us? Is the way we are practising it giving us that outcome? How else could we get that outcome in this team, in this context? Is it even relevant to us?

Once you start asking these questions you will see your process through a different lens. Now you can inspect and adapt. Now you can start to train your Agile.

[This article was first published on the XP2016 blog in April 2016.]