How to train your Agile

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”.

A long time ago…

The earliest agile projects, or at least those projects whose participants would later 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.

Tagged with: , , ,
Posted in Uncategorized
5 comments on “How to train your Agile
  1. thinkfoo says:

    Nice article Dan. I’ve never been a fan of certification I think you lay out how it can go wrong well. The other big problem I see with scrum is its failure to include anything at all about technical excellence something I see Continuous Delivery helping to redress. I talk about this more here


  2. Timely article for me Dan, I’m taking a group through a ‘re-examine scrum ‘ exercise next week. Can we clarify the PO role though? I like to refer to the PO as ‘who we work for’, someone who sets the vision and goals, demonstrates the ongoing importance of the next goal causing the team to swarm around the work they think is needed. Aside from representing customer needs I find this aspect of Product Owner / team relationship to be key to good outcomes, the scrum master far less so. What do you think?


    • Dan North says:

      Hi Russell, thanks for taking the time to comment.

      Having a separate Product Owner in that way can systemically disable the team. They don’t “work for” a Product Owner any more than they “work for” a tester. The team works for any number of stakeholders. Primary stakeholders are the end users of the product and anyone who will ultimately benefit from the capability they are providing. Other stakeholders might include regulatory or compliance representatives, security and operations, support staff, application administrators, anyone maintaining or building on the codebase later on, etc.

      Where there is a Product Owner they typically only represent a small subset of those stakeholders, so the needs of the others get discarded as technical or operational debt that never gets paid back, or emerge as “urgent” fixes to comply with compliance requirements that got forgotten in the rush for more and more features, and all the other fallout that happens when a single person makes all the priority calls.

      If the team needs external help to understand or care about the value they are delivering, that sounds like another systemic problem. Maybe they are too removed from their stakeholders or they don’t get frequent enough feedback to see the impact of their work. (Maybe the work doesn’t have much value, which is useful feedback in itself!) Introducing a proxy for some of those stakeholders might help, but then that person should be a team member just like anyone else. Pairing domain experts with developers is a great way to share both product and technical knowledge, and blur the boundaries of both roles.

      Instead of an external PO the whole team should be aware of the primary and incidental stakeholders (I’m a fan of Persona Modelling to explicitly identify these) so they can make and communicate decisions about trade-offs as a team, ideally directly with the people who will be impacted. Where they need someone with specific domain or product expertise or to help shape the vision and direction of the product, that person acts as an adviser to the team like the security or compliance stakeholders.

      Depending on how the money works in your organisation there will be a budget holder somewhere who acts as the project’s or product’s sponsor. Even they might not be who the team works for, because often they are just a custodian of money and don’t really have the autonomy to decide where or how it gets spent.


  3. Simon Cowan says:

    Really like the concept of the product a product coach. I think when organisations are looking at agile they gravitate to “let’s go scrum”. In my experience the product owner role has the potential to bring about a less than agile project. Recently, speaking to a colleague about agile and my own exposure to agile I had recounted a story of my early days (1998) as a programmer. It was along the lines of being given a base unit and told to go on to a client site and come back when it’s done. As I went out the door I was told you have 4 months!

    So through luck, commercial reality including a sprinkle of self-preservation I ended up owning a product. I prioritised and I gathered requirements, usually with the customer behind me pointing at the screen. I tested code and built my server’s, installed my database, setup by backups and trained my users. For so many best practice reason’s it was a baptism of fire but getting product thinking baked into my thinking was just amazing. Would be really keen to see how product coaching develops think it is so important to get the team understanding their role and feeling empowered as product owners.

    It will challenges some developers to really think about their role and offers exciting opportunities if grasped.


  4. […] article was first published on the XP2016 blog in April […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: