June 24th, 2014
I would say that, in the introductions part of 90% of the training courses that I run, at least one person will introduce themselves by saying something like "Hi. I'm Dave. I work for ACME Ltd and we've been doing Scrum-ish for a couple of years. I'm really keen to see how it should be done".
I typically respond with a semi-humorous comment such as "I'm not sure I'm too fluent in Scrumish but perhaps we can work out some way of communicating, perhaps using hand gestures and speaking slowly". Of course, I know what they mean; there are very few teams and even fewer organisations out there that actually do Scrum. At best, they are in the early stages of transformation into a new, lean organisation. At worst, they are making a half-arsed attempt at paying lip-service to what they see as the latest trend in project management.
I have gone on record in the past as saying that doing Scrum should not be your goal. Scrum is a means of becoming agile - probably the best one I know - but you can, and should outgrow it if you do it right. However most teams and organisations don't outgrow it for that one simple reason that they DON'T do it right. They do it half-arsed, wonder why it doesn't work and then go back to their crappy old process or, sometimes worse-still, stick with a process that is half crappy old process and half confused new process.
Well, as many people - myself included - have said, doing Scrum is hard. And switching to Scrum overnight is often impossible and impractical, certainly at the organisational level. Therefore a certain version of Scrum-ish is almost inevitable, especially if there is no experienced agile coach on board to help guide things. And this is not a bad thing; the rollout (or adoption or transformation, whichever word you prefer) arguably SHOULD be a gradual rather than a big bang process.
The problem is, however, that Scrum-ish tends to encourage Scrum-ish which makes it harder to get to Scrum and, eventually, to get past the need for Scrum. Ironic…
Let me explain with an example. Let's say that you do Scrum but you don't really have a product owner; instead you have a proxy. The proxy doesn't have time to get involved with the team on a regular, continual basis and isn't as qualified or as knowledgable as a true product owner would be. Therefore there are a number of surprises at the end of the sprint; pieces of work that the team considered "done" but when the product owner looks at them declares them "not done". I'm sure it doesn't take too much effort to imagine this scenario.
The team are disappointed and say "well if you'd been involved more then we'd have done it differently" and the product owner says "I don't have time for that" to which the team reply "well you need to write better requirements then because we did what you asked for". So the product owner now needs to invest more time in writing "better", more detailed requirements for the team. One obvious consequence of this - apart from the fact that more tightly defined requirements are often easier to misinterpret - is that the product owner now has even LESS time to spend with the team and it takes longer to feed the team with work. This is a vicious circle.
Another example is where the team don't contain all of the skills to get something "done" within a sprint. Let's say that testing is still done by a separate team and the scrum team hand their work over to the testing team at the end of each sprint. At the end of sprint 1 the team aren't "done" but they have "done their bit" and hand to the test team. In sprint 2, the test team test while the scrum team get on with some more development. At the end of sprint 2, the test team have some more stuff to test (the output from the scrum team's second sprint) while the dev team either get on with some more dev work or, more likely, have to fix some of the issues that the test team found from their first sprint's work. Still with me? Yeah, complicated but at least everyone is fully utilised right?
My point here is that the team aren't "done" at the end of each sprint, as they should be as per Scrum. Because of this the test team are always busy but working one sprint behind the dev team. Thus they are now incapable of becoming part of the Scrum team because they have just got too much work to do to stop and help extend the definition of "done" of the development team. Scrum-ish has, once again, encouraged greater Scrum-ish.
There are many examples of how not doing Scrum properly actually encourages greater sub optimisation. I want to re-iterate what I said earlier: that doing Scrum is NOT the goal but, if being effective IS the goal (and Scrum is a great way to become effective), then for pity's sake do Scrum as best you can and then ruthlessly, relentlessly get rid of the ISH! Otherwise you will find yourself stuck in a kind of half-agile, half-waterfall purgatory.
And that is not fun, believe me.
What other examples of Scrumish leading to greater Scrumish are you aware of? How have you stopped the slide down the slippery slope?
Scrum / Scrum But / Scrum-but / Scrumerfall / Scrumish
June 17th, 2014
I recently ran a one-day Scrum Mastery workshop at the Scrum Alliance Coaching Retreat in Teddington. The retreat as a whole was a great success, allowing close to 70 agile coaches dive deep into some important topics such as the pathway for development for agile coaches, resources for the development of ScrumMasters, making change stick and coaching executives among others.
My workshop focussed on a few key skills - listening, questioning and understanding your gremlins - that are important for coaches to be successful. The workshop was highly interactive (no surprise there!) and allowed the attendees to focus on, practice and receive feedback on these skills. It was well received and I really enjoyed working with some great people.
An ext... read more
#scrummastery / Agile / Coaching / Scrum / Scrummaster / Servant-leadership
April 30th, 2014
I regularly get people ask me for tips on how to be a better leader or ScrumMaster. "What more can I do to help the team get better?" they ask me. This is a great question, and one that every leader should ask themselves regularly. It's also a question that the best leaders ask the team itself - "What more can I do to help you improve?"
A subtle variation of this that can lead to profound changes is "What can I NOT do to help the team get better?". Sometimes the best thing you can do to help a team is to NOT do something. Don't solve their problem, don't answer their question, don't remove that impediment, don't fill the silence, don't update the artefact, don't stand at the front of the room in the retrospective, don't be the one to captur... read more
/ scrum master
#scrummastery / Enabling / Leadership / Scrummaster / Self-organisation / Servant-leadership
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 har... read more
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