I was lucky enough to attend the Orlando Scrum Gathering in March this year, and even luckier to hear Harrison Owen talk about Open Space and then to have him facilitate the Open Space at the Gathering.
As he was introducing the days event, I was suddenly and powerfully struck by an idea; why had I never thought to use Open Space as a format to facilitate a team retrospective!
On returning to Cape Town I discussed with Peter, and we decided to try running it with one of our clients for a multi-team retrospective.
So, firstly, Harrison Owen’s rules for Open Space:
Whoever comes, are the right people
Whatever happens, is the only thing that could have
Whenever it starts is the right time
When it’s over, it’s over
The law of two feet applies; when you feel you can no longer contribute or learn something from the session you should move on. This is not a judgment on the people or the topic.
The person with the passion for the topic has the responsibility to facilitate the discussion and provide feedback to the whole group,
Respect each other, hear what everyone has to say
Allow yourself to be surprised
We snuck the Open Space concept in under the radar. We started by getting everyone to put their chairs into a circle, so that you could see everyone. I introduced the rules to everyone and then we waited for the first person to introduce their topic.
We created a market place with three slots of 15 minutes and seven tables for discussion. We had 29 people which meant about 4 people to a topic at any one time. This was done with some flip chart paper stuck to a wall. We then arranged the tables and placed an identifier on the table.
The initial topic proposals were somewhat slow in coming. The important thing is to allow the space for people to think and then propose their topics. This does take some guts to let there be silences. The important thing is that when people propose topics they should not put too much detail into the proposal; the discussion should happen in the session. Within a few minutes we had a good number of topics on the wall and people went up to start looking at the board and figure out where to go.
The actual running of the session was fantastic; I had some reservations going in that people would be too reserved and would not engage with this process but the level of engagement was fantastic. Unlike some retrospectives where the role of the ScrumMaster in ensuring that everyone participates is critical, there seemed much higher levels of engagement due to the smaller groups and the passion of the individuals for their topics.
At the end we then got everyone back in the circle for the feedback time. We unfortunately ran out of time for the full feedback to happen.
Some learnings for us as coaches out of the 2 hour session:
We needed multiple marketplaces for a first time as people are still becoming acquainted with the process and a number of topics emerged as part of the discussion which then we didn’t have time to announce to the group
We should have planned for fewer total number of sessions
The amount of time planned for the feedback round was inadequate
This is a superb way to encourage self-organisation in an organisation which has low levels of self-organisation.
I am really looking forward to running this style of retrospective again.
Five years ago, almost to the day, Ron Jeffries wrote a great post entitled “A Metric Leading to Agility“. In it he coined the term “Running Tested Features”.
More recently he has talked about another helpful metric for teams transitioning to Agile. It is “Running Automated Tests”. For those who need some guidance about choosing the right test automation tools (and avoiding the wrong ones), Elizabeth Hendrickson has written a great article.
As Lean enthusiasts might be tempted to celebrate the demise of General Motors and the assumption by Toyota of the #1 auto maker rank, James P. Womack* gives us pause to think about the end of an era.
I’ve been updating myself on the activites in the Prince2 camp to update this project management framework. One thing that stuck is the lamentations about the large number of PINO projects. PINO is an acronym (actually an initialism) for Prince In Name Only. In the Scrum world this has commonly been called ScrumButt, drawn from “we’re doing Scrum, but…” as well as the frequent desire to kick such teams in the butt!
Martin Fowler, one of Agile Manifesto signatories has blogged recently on “flaccid Scrum” (http://www.martinfowler.com/bliki/FlaccidScrum.html). FWIW, I agree with him.
We must constantly remind ourselves (and those whom we seek to influence) that:
Scrum is silent on which “software engineering” practices to use, but not on their use.
We must continuously assess our way of working against the Agile principles.
Undone work (aka technical debt) will continue to cripple delivery of value as long as we continue allow it to accumulate.
Scrum is just a tool to expose deficiencies and dysfunction in the team and the organisation – the problems remain ours to tackle and solve.
So while we continue to battle our demons, how about honestly calling some Scrum implementations SINO (Scrum In Name Only)?
Right now I’m sitting at the back of the class while my good friend André is conducting an introduction workshop on ITSM (IT Service Management) using the ITIL framework at a major retailer.
He tells a story to illustrate the difference between incident management and problem management. The latter requires a root cause analysis. The aha! moment for me is when he says that root cause analysis is the start of a CM (Change Management) process.
I realise that Scrum is an ongoing change management process. In every daily Scrum meeting, Sprint Review and Sprint Retrospective the team (and stakeholders) inspect their work and their process and make adaptations to improve.
Being Agile includes working at a sustainable pace. That means we have time for important things outside of work. Like our family, our health, our faith and our planet Earth.
I invite you to invest an hour together with a billion more people in our planet Earth. Sign up at:
The Cape Town chapter of the Scrum User Group of South Africa held its second event on at 18:30 on Thursday 6 November.
We took advantage of Boris Gloger’s presence here to host a panel discussion with Boris, Steve van der Merwe and myself. Sue Bramhall facilitated and her company, 24.com kindly sponsored the venue and refreshments.
The audience of around 40 varied from people curious to know what Scrum is to those practising for a couple of years and looking for some therapy <g>. We had some lively discussions. Boris asked one person from a large enterprise what was preventing her from starting to apply Scrum in her team. Another outcome I recall is we all said we didn’t trust architects who don’t write code!
Steve got people to write down what they want from future events, which should help the organising team to tune future events.
Sue threw the laggards out around 21:00. Sorry, Dan, that I asked you so many awkward questions about your team’s journey with Scrum.
Last night Mike and I ran Boris Gloger’s “ball points” game for the monthly Cape Town SPIN meeting.
We had a group of twenty-something IT professionals who got off to a flying start by immediately organising themselves into the classic concentric circle formation. Yet their score in sprints 1 and 2 were pedestrian. In the reflection after sprint 2 they shed one member to make their number even (illegal?). In sprint 3 the team ‘gelled’ and the score raced up to 60! They asked what the record is. We said we thought it was eighty-something.
Then they made an adjustment to their process that Mike and I had not seen in perhaps 20 times we’ve done this exercise: they threw the balls two at a time. Not exactly throwing, mind you; more like dropping from one person’s hands into the next. To my surprise it worked brilliantly with very few ‘bugs’ (dropped balls). They managed 93 and 103 points in their final sprints and were justifiably pleased with themselves.
2 Comments | 
Coaching, Miscellaneous | 
Permalink
Posted by Carlo
