Lessons From the Eye of the Storm Part 2 - The Genetics of Successful Scrumming

In a previous article I discussed the day-to-day challenges facing the Product Manager in the Agile world and remarked that the debate surrounding the role of the Scrum Master and Product Owner was worthy of its own discussion.

A colleague of mine called my bluff the other day by asking me “What’s the issue with Scrum Masters and Product Owners?” This got me thinking about why one would go down the whole Agile route in the first place; what had we set out to do – and how close did we get? This article takes a further “eye of the storm” look at Scrum and its DNA, from a Product Manager’s perspective, and offers some further guidance on four of Scrum’s most critical elements.

Note: I offer no guarantees concerning the scientific accuracy of any DNA or any biological references herein; the references are purely indicative and metaphorical. Scientists need not feel obliged to correct any errors!.

Scrum – the DNA

Scrum, an Agile process framework, is one of the most highly-regarded ways of managing development projects faster, with better outcomes. It has gained an enormous traction in the software world, and is used by a large number of major organizations in the industry.

So, what characterizes an organization that is using Scrum effectively?

The first thing you might notice is that the actual Scrum model being used is already vastly different from the original implementation. Scrum adoption, according to its definition, allows for a lot of wiggle-room (adaptation) and this allows it to be refined to different scenarios and company cultures. Scrum is therefore – as an internal process – likely to evolve over time.

Additionally, there are basic principles of Scrum adoption, above and beyond “inspect and adapt” that give it its uniqueness. As Wikipedia tells us, “Scrum is a process skeleton that includes a set of practices and predefined roles”.

• The Scrum Master. Scrum tells us that for every team of developers working together to build something, there’s someone who cares only about the success of that task and is prepared to do whatever it takes to remove road-blocks, promote action and reach the end-goal.
• The Product Owner. A significant attribute of Scrum was to acknowledge the need for constant stakeholder input and validation, which is where Waterfall had so often failed (big, late projects with requirements that had completely changed during the project lifecycle, rendering the final deliverable useless). The Product Owner therefore acts as “the voice of the business” and sets original direction (requirements) and validates iteration outputs against target. Importantly also, the Product Owner is perfectly allowed to change the requirements – which then change the requirements list (or backlog).
• The meetings – Scrum defines itself in terms of the levels of interaction required between team members. Roles are clearly identified, and success criteria are well established.
• End-Goals. Scrum is quite modest in the chunks it suggests you manage – basically the concept of the ‘iteration’ of a few weeks is a rule-of-thumb duration for a scrum team. Small team, small time-box, simple (read: well-defined and agreed) list of things to do.

You will find more books on Scrum, Agile and derivatives than any other software project methodology in the last couple of decades, and the number of accredited scrum experts and trained scrum staff appears to be growing exponentially. To me it feels like there are less people in the industry who don’t know about Scrum, and on that note I will leave any definitions there.
Let’s now tear apart some molecules of the Scrum DNA and take a more critical look in some of more curious elements.

And why did we invest in that? The ROI molecule

Scrum is so popular it appears to be breaking all records in terms of adoption. For a de-facto industry standard, one might expect the measurement of its value, to be straightforward and unequivocal. As it is, Scrum’s Inspect and Adapt model makes statistical measurement of its business benefit illusive. Remember, “Scrum” today in a given organization is a very different beast to that of another, which is different again from another, and so on.

Guru Ken Schwaber gave us his view in his 2006 FAQ, “The benefits of Scrum are a competitive advantage if you are an ISV or your ability to respond more quickly to your competition if you are a business organization. The benefits are the ability to develop and implement high value, high priority software quickly to increase your return on investment, to reduce your staff turnover, to increase your staff satisfaction and to increase the quality of your product.”

Schwaber’s words give no hard facts at the time to support his claim; we are forced to search elsewhere for proof. When first I was educated in Scrum, I kept hearing “typically two to three times greater productivity” for Scrum-based projects (presumably compared with traditional waterfall models). That’s some claim. I remember one software company setting a target of 40% greater productivity over a year as a result of Scrum adoption. But while there is some truly independent work available (IEEE’s case studies, for example), much of the ‘noise’ about the success of scrum is generated by vendors of training, tooling and other media. A cynic might expect those who are selling services around Scrum to promote the measurable benefits. So, the “accepted truth” about Scrum is inferred, perceived and suggested, or promoted by those with a vested commercial interest.

Gilb and Brodie’s paper asserts this is not good enough, and the industry needs to stand up and be counted as to why this brave new world is better than the old one, statistically. Why doesn’t the Scrum Alliance promote itself by offering quantified benefits, rather than a purely qualitative discussion?

If we look at the molecular structure of Scrum, it appears not to include any self-promotion gene. Or at least not one that is quantitative. All this achieves is making the adoption harder to sell to sceptics. If the adoption flounders at any point, the business may well want to “look at the numbers” to justify continued investment. Those numbers need to be there.