February 24th, 2014

Blamestorming - Who's Accountable In Scrum?

One of the things about Scrum that many organisations find uncomfortable is the concept of accountability. Who do we hold accountable for this piece of work if things don't go well? Because Scrum doesn't have the role of project manager, there is no single point of failure upon whose shoulders responsibility will ultimately rest, which is inconvenient. There is an underpinning philosophy to Scrum which is that "people are good, they want to do a good job and nobody screws up deliberately". Not everybody agrees with this view of human nature and some are quite explicit in their distrust of other human beings. For these people, Scrum will never work as it is so heavily built on trust. Management who operate at a distance find it harder to trust and would really like the clarity of one person they can go to, exert some pressure on and perhaps have a hold over to encourage greater performance.

Most people realise this is a fallacy when operating in an environment where the engagement of the delivery team is crucial. Instead Scrum was engineered to develop a close bond between all of those committed to making a project work, such that everyone feels a sense of responsibility and, more importantly, an innate desire to be successful due to having an explicit stake in the creation and outcome of whatever it is we are building. The fact that the development team is given a solution-agnostic goal to work on, has control over what they commit to, how they intend to go about building it and then get to demonstrate their progress every couple of weeks identifying ways to improve gives them the three elements of motivation that Dan Pink points out in his talk on The Surprising Science of Motivation: Autonomy, Mastery & Purpose. 

If we overlaid an authoritative role on this setup, it would naturally undermine the impact that the concept of a self-organising team would have. That is not to say that the Product Owner doesn't have authority - they do, but over the product not the team. The product owner will make decisions (perhaps even autocratically in some situations) about goals, release dates, requirements and priorities. That's their job. But the development team itself doesn't have the easy way out of a leader to make a decision, or even a simple, democratic voting process - the minority shouldn't be steamrollered. The development team make their decisions based on consensus - that is something that we are all happy to go along with and support. So there isn't even a process for singling out a scapegoat within the development team. They succeed or fail as a team. As do the Scrum team as a whole.

If (and I really want to stress the word IF here) you wanted the most black and white version of accountability in Scrum it would go like this:

  • If the product turns out to not be valuable or viable, the product owner should pull the plug
  • If the product owner doesn't pull the plug on a failing product, they should be stopped by the organisation
  • If the team is unable to deliver enough value to make what would otherwise be a valuable product viable then the product owner should either (a) support the team's development so they can improve or (b) find find themselves a new team
  • If the team aren't able to deliver enough value because there are too many impediments, they should find themselves a new ScrumMaster
  • If there are too many impediments, the ScrumMaster should change their organisation or change their organisation!

I will say it again though - this is black and white (too much so) and in reality it will be a lot more collaborative than this but it shows how low down the chain the ScrumMaster comes in terms of accountability - this is often a huge surprise for many organisations as they confuse the ScrumMaster with a project manager role.

Projects should be evaluated on a sprint by sprint basis, constantly asking whether this is still a worthy investment and how we can improve our situation. This isn't about voting off the weakest link but rather continually finding ways to help people who inherently want to do a good job, do what they need to do.


Accountability / Blame / Motivation / Responsibility / Scrummaster / Single Point Of Failure

2 comments | view comments | add comment


December 5th, 2011

The Angelina Jolie Blog Post

I think one of the most glossed-over parts of Scrum in teams is the concept of a Sprint goal. My main concern with this is not that people aren't doing Scrum properly but that they are missing out on something that could give their teams, projects and products a massive boost. "After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment" - The Scrum Guide, Schwaber & Sutherland Most Scrum teams, in my experience, take as much of the highest priority Product Backlog ... read more





Cancelled Sprints / Focus / Motivation / Roi / Sprint Goals / Synergy / Themes

0 comments | view comments | add comment


November 8th, 2011

An Autumnal Father-Son Scrum(ish) Story

So here's the situation; the leaves are turning beautiful shades of red, purple, brown and orange, you can hear them crunching under your feet as you take a walk. Yeah...Autumn is my LEAST favourite time of year! I HATE clearing up leaves! When I bought this house, the fact that it had a fair-sized garden was not a plus point for me, and the fact that it was surrounded by huge trees was a very definite negative for this very reason. Anyway, the gutters were full and causing leaks outside the front door so the alert had been triggered. I needed to get my butt in gear and clear them up. I was also looking after my 5 year old son as my wife was taking my daughter to her dancing practice. Could I actually get anything done w... read more



Autumn / Backlog / Experimentation / Motivation / Multi-task / Non-software / Planning / Prioritisation / Quality / Slack / Technical Debt / Tools / Vertical Slices

4 comments | view comments | add comment