February 24th, 2014
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
February 14th, 2014
I have teamed up with the Scrum Alliance Coaching Retreat to offer a 50% discount to my 1-day Scrum Mastery workshop for people attending the retreat. The workshop will be run in the same venue as the retreat on the day before the retreat starts. Regular tickets are £500, with early bird tickets available until April at £400 and those booking on the retreat (which I would thoroughly recommend by the way) will pay just £250. Details are on the website here and you can book on here... read more
/ scrum master
Coaching / Retreat / Scrum Alliance / Scrummastery / Training
February 4th, 2014
I tweeted recently that "#ScrumMastery is about becoming great at using Scrum to help create great teams who create great products and services" and I was asked to expand on that. Well, my expansion is probably too much for 140 characters so here's a blog post instead...
I get to see a lot of teams. A lot of teams who are doing Scrum - or, to use their words, doing "Scrum-ish". Most people, when I ask them how it's going say things like "Yeah, it's OK" or "not bad", sometimes things like "frustrating" or "could be a lot better". Most teams are doing OK but they aren't doing brilliantly. They are doing a lot better than they were before they were using Scrum, though, and that could be part of the problem. Comparatively speaking things are a ... read more
/ scrum master
#scrummastery / Development / Engagement / Scrum / Scrum Mastery / Self-organisation / Teams / Trust
January 10th, 2014
I have been toying with this post for a long time now. I want to say right at the start that I don't want this to come across as deliberately inflammatory and certainly not disrespectful (as some bloggers seem to get off on) because that is not my intention. I also realise that by starting with a sentence like that, it's almost like somebody saying "No offence..." or "With all due respect..." and we all know what those phrases typically mean!
Anyway, I have a concern that the conversation hasn't moved on fast enough since the Agile Manifesto was pulled together back in 2001. The efforts of those visionaries have helped to make profound changes in how software has been developed and delivered over the last decade. Almost anyone operat... read more
Bravery / Engagement / Navel-gazing / Non-software / Scrum / Software
November 12th, 2013
A ScrumMaster is a servant-leader and their responsibilities include ensuring the team is able to do what they need to do. They facilitate the Scrum process and also the team. They are an enabler for Scrum within the organisation and the team within the organisation. The word "enabler" often has a negative connotation, the most common association being those who (often unwittingly) assist an addict with their self-destructive behaviour. This is obviously not what we mean when we say that the ScrumMaster is an enabler, instead we are referring to their striving to support others' (primarily the development team and the Product Owner) abilities to do their jobs well. They enable the others in the Scrum team.
Some ScrumMasters and I were havin... read more
Coach / Coaching / Psychology / Scrum / Scrummaster / Self-organisation / White Knight
May 31st, 2013
Scrum Mastery book OUT NOW
I am excited to say that my first book Scrum Mastery: From Good to Great Servant-Leadership has been released. In over ten years of working with numerous teams and organisations I have identified the patterns that separate good ScrumMasters and great ScrumMasters. This book illustrates these patterns through stories of my own experience and those of the many Scrum teams I have worked with and also offers practical guidance to you on your own path to greatness.
You can order the book on Amazon.co.uk or on the various European versions of Amazon. It is also available on Amazon.com and the Amazon Createspace eStore
Comments on the book
Mike Cohn, in his foreword for the boo... read more
Book / Mastery / Scrum / Scrummaster / Servant-leadership
February 12th, 2013
The Geckos were coming towards the end of the sprint (day 28 of 30) and were having their daily scrum in the morning. The team were standing around the sprint backlog board and were taking it in turns to update the rest of the team on what they had been working on and their plan for the day. An extract from the conversation:
“Guy & I have finished coding the photo upload feature and have handed it over to Roxie and Eve to test” Christian said “and that’s us done for this sprint so we are probably going to make a start on the ratings feature from the product backlog to give ourselves a bit of a headstart for the next sprint. Obviously we have no impediments because I’m finished! Hooray!”
Christian then... read more
/ scrum master
/ ScrumMaster Stories
Cross-functional / Developer / Scrummaster / Tester / Testing
December 13th, 2012
I often get asked about a Job Description for a ScrumMaster - recruitment companies certainly haven't nailed this one yet - and also do a lot of coaching of ScrumMasters. There really isn't a great definition of what a ScrumMaster is or what makes a great ScrumMaster so I started writing down examples I have seen of great ScrumMastery in an attempt to move towards a definition of what a great ScrumMaster might be. I will expand on some of these in future blog posts:
They are written in a particular format with both sides of the statement illustrating a positive example of ScrumMaster behaviour and the second part of the statement illustrating what, in my opinion, lifts someone from a good ScrumMaster to a great ScrumMaster. The
A good... read more
/ scrum master
Scrummaster / Team Dynamics
January 13th, 2012
As a Certified Scrum Coach (CSC) I do a lot of work with ScrumMasters in organisations who are looking to find new ways to engage their teams and move their Scrum implementations forward past the basic Scrum framework. When Coaching ScrumMasters I recommend they try to become more ADAPTIVE. As you might have guessed from the fact that the word is capitalised, it is an acronym for a number of behaviours. Following on from my blog post about ScrumMasters getting RE-TRAINED, an ADAPTIVE ScrumMaster:
Helps the team to hold themselves ACCOUNTABLE
Leads the team to DIVERGE before they converge
Helps the team take ACTION to improve
Asks POWERFUL questions to make them think about the root cause of their challenge
Encourages the team to TRY someth... read more
/ scrum master
Accountability / Adaptive / Advanced / Agile Adoption / Asm / Divergence / Elephant / Experimentation / Involvement / Scrum / Scrummaster / Training / Visibility
November 20th, 2011
I'm pretty bad at twitter. I am terrible at getting my thoughts across as intended in 144 characters and the more I try sometimes the worse it gets. So I am writing this as a response to the twitter debate that ensued after Jim Coplien's latest post. My first view upon reading this was that, considering Jim's normally controversy-inviting style, it was well-written and aligned with a number of things I have been thinking about recently. However, it left me incredibly conflicted primarily because I want to be someone who is being positive and constructive to everything that is trying to help make organisations more successful through agility. This is why Jean Tabakas "Community of Thinkers" post resonated with me. I do feel an urgent need to... read more
Agile / Community / Conflict / Kanban / Scrum / Timeboxing