|
|
 Scrum Simulation
I met Michael Sahota at Agile 2009. Gino Marckx, fellow Toronto agilist, recommended I talked with him.
Michael has created a Scrum simulation based on the XP Game. I regularly get asked if there’s a Scrum equivalent of the XP Game. I’m sure there must be, but this is the first one that I know of that’s published. If you know of any other published, free games let me know.
What I like is:
- One hand drawn overview of the whole process and game. Portia does something similar when she plays the XP Game: one poster with a post-it figure moving from step to step as the team progresses through the game. The poster remains in the team workspace as a handy reminder of the process.
- Making the backlog visible with a story board.
- Changes are republished with a Creative Commons license.
Agile Tour Toronto
I had more discussions with Toronto agilists Peter Yu and Syrous Delavari from Intelliware. Gino, Michael and the guys from Intelliware organise Agile Tour Toronto on October 20th. I won’t be able to attend. If you’re in the neighbourhood of Toronto around then, don’t miss this event. It’s sure to be fun and interesting.
Agile 2009 roundup
I already wrote up the different sessions I attended:
Time to do a conference retrospective.
What Went Well
- Chicago (at least the part I saw) is a pleasant mix of big city with plenty of green and lake
- The Art Institute, Field Museum and Museum of Contemporary Art provided several hours of stunning and interesting exhibits. After some searching, I got to see Nighthawks up close
- Mapping the Agile Enablement Battlefield by George Schlitz and Giora Morein gave me a new tool to think about agile enablement in large organisations
- Several analysis sessions in the program shows that we’re interested in finding out out what value our projects can deliver
- Useful leadership and facilitation tools from Steve “Doc” Smith and Chris Avery
- Flirting tips from Ole Jepsen and Jenni Dow to connect better at work
- Lots of games for innovation, push/pull, kanban
- Meeting other participants in the sessions, over breakfast, lunch and dinner and going out for drinks
- Story telling as a coaching, consulting and retrospective tool
- Playing two parallel bottleneck games and seeing happy participants who’ve learned useful techniques while having fun
- The facilities staff were very helpful and thorough helping us to rearrange the room for the bottleneck game. A nicely self-organising team in action.
- The event organisers provided us with rapid feedback: the feedback forms were scanned and emailed to us only a few hours after each session.
What Went Wrong
- We accepted too many players for the Business Value Game, which made it very difficult to come to consensus in each group and made for a noisy and messy session
- The hurried banquet and too long closing keynote
- Too many sessions, especially those about analysis, that consisted of only the presenter talking without any participant interaction or activity. I thought analysis was about listening, involving people and discovering what they value?
- Not being able to meet everyone I’d like to talk with
- Missed the PMI Agile meeting at the Thoughtworks office
Puzzles
- When are we going to stop those blanket dismissals like “project managers are useless, they should all become scrum masters”, “PMI is non-agile”, “we don’t need analysts, they’ll only lead to lots of useless documentation and paralysis”, “lean is bad because it’s production”, “powerpoint presentations are bad”, “Scrum is evil”, “Kanban is stupid”. Let’s grow up a bit and realise that we’re all fighting against bad project management, bad analysis, bad presentations and unprofessional software development.
- Are Portia and I typecast as “games makers and players”? We also submitted presentations, but the reviewers seemed to prefer “fun games” above “boring presentations”. Presentations don’t have to be boring. I had hoped Jared Spool would prove that, but he spoiled it by taking too much time. Come and see us present the “Toyota Way” presentation at Scandinavian Agile and XP Days Benelux
- What is Agile and where is it going? At the conference we see lots of aspects of Agile in a very fragmented view. What is it that we all have in common? What makes us different from professional engineers?
Learnt
- Less is more. The Bottleneck Game went very well because we limited the scope. There’s so much we could tell about the Theory of Constraints and its consequences. The Business Value Game flopped because we didn’t limit the number of participants and because there are too many elements in the game
- The importance of (business) analysis becomes clearer, as the old techniques help us to discover and define value. Without it, there can be no value-driven work. I’ve been applying agile analysis for years, but it’s only recently that I’ve become consciously competent again and can teach it to others.
- Shorter sessions are useful to get presenters to focus on one idea and present that clearly. And it allows me to apply “the law of two feet” more easily. I’m going to try to make some more focused games and simulations, so that I can explain one concept fully and let participants experience it, in a short session.
Another session about Business Analysis. I recognise a lot of the tools and the presenter uses a similar approach to mine: derive required capabilities from the business value drivers.
However, like most of the other analysis sessions, there was too much talking and not enough listening or doing. There was no participant interaction, just a long, monotone discourse.
Olla let the participants see the difference between Push and Pull scheduling, first with examples from his past flipping burgers, then with a simple simulation. We had to work together to fold paper airplanes. This time I was the lucky player who got to be the bottleneck. We then told each other about similar situations in our work life. Most of the stories were about integration testing being the bottleneck.
Participants liked the pull system better: less waste, less stress, better quality.
I’ve sent Olla a complete perfection game about the session, but here are some of the highlights:
To make it perfect
- Use an example that is “pure push”, not the mixture of push and pull used at McDonalds
- Explain the advantages and drawbacks of each method
- Link push and pull to IT, to help participants see the connection
- How do we proceed if we want to install a pull system?
Tsutomo contacted me before the conference to exchange game development ideas and I met him and his Japanese friends at the Thoughtworks office. Unfortunately, I couldn’t attend the session because I wanted to take part in the two sessions described above. I only got to see the end of the game, but the game seemed to be a success: participants were really involved and they got better insights into Kanban. Tsutomo got some good feedback to improve the game. The game is published on Tsutomo’s site. I hope to see this game again, improved with player feedback.
Closing
Thursday evening’s banquet set a speed record: one dish had only just been served or the waiters asked if they could remove the plate and plunk the next dish on the table. In contrast, Jared Spool’s closing keynote, although entertaining and informative, set a length record. What with all the announcements, people were fidgeting to leave. The evening ended with a few drinks and lots of discussion of agile, lean and organisations.
I didn’t participate in Friday’s open space sessions, just said goodbye to a few people. After a breakfast meeting and a visit to the Museum of Modern Art came the long flights back to Belgium. Another Agile200x has gone. Next year’s conference will be in Nashville, Tennessee, home of Country music 🙂
Most of today’s sessions are about business analysis. This Feature Injection approach looks a lot like what I do, but explained at a very high level. Essentially it boils down to:
- Identify Value: make sure you have a business value model which defines the type of value projects seek: increase revenue, decrease cost, protect revenue, reduce risk, increase information…
- Identify Capabilities: what is the minimum set of capabilities we need to realise the value(s)?
- Get lots of examples: understand what exactly happens in different circumstances
Or stated differently:
TO realise < identified value> AS A <actor> I NEED <identified capbility>. GIVEN <example situation>, WHEN <example action> THEN <example outcome>.
Now we just need a way to find those pesky actors who deliver the value.
This session focused on the requirements that don’t neatly fit into the User Story mold: non-functional qualities, implementation and design constraints, cross-cutting concerns. How do we represent these?
- Write specific User Stories. E.g. AS A CTO I NEED the solution to be deployed into environment X SO THAT our support costs remain constant. The advantage is that the rationale is clear. The disadvantage: this story is never done.
- Add extra constraints to the User Story. E.g. AS AN accountant I NEED report X in 5 seconds SO THAT….. The advantage is that the information is directly associated with the story and has user meaning. The disadvantage is that there are usually several criteria, so the User Story might get very complicated.
- Add constraints to the “iteration definition of done” or “release definition of done”. E.g. all modified or new functionalities must be documented in the User Manual before the iteration ends. Advantage: useful for recurring needs. Disadvantage: may lead to implementing and testing these requirements late, so that nothing is really DONE until the end of the iteration or release, batching up work at the end.
- Add acceptance criteria. E.g. GIVEN a session at the conference WHEN I select the details THEN the full session description is displayed within 3 seconds on any web browsing device. Advantage: concrete, leads to lots of questions as we explore scenarios, leads to automated acceptance tests. Disadvantage: where do you put the tests: story, module, application, global?
- Other techniques like planguage or simplified text descriptions of constraints.
One extra tip I would add: define service levels.
Service levels
For many non-functional criteria we can define a limited set of “service levels”. For example we could have three security levels:
- Top secret: nobody can see it, until it’s published in the newspaper
- Private: only the person concerned + HR can access the information
- Public: anybody can access the information
Or we could do the same for response levels:
- Blistering: answers within one second
- Snappy: answers within 3 seconds 98% of the time
- Relaxing: answers within the time to take a lunch break
Now, instead of discussing (haggling) over details of non-functional requirements (“is 1.5 seconds fast enough? No? 1.4 seconds?…”) we put each story into a service level “bin”. Most User Stories can be classified quickly. We can annotate the User Story with the appropriate set of Service levels in each of the dimensions. We can subject the User Story to standardised acceptance tests that verify if the implementation does indeed comply with the rules of the service level.
For those few stories where the standard service levels aren’t a good fit, we can create customised criteria and tests. And of course, we’ll review and update the service levels when we see that the classification doesn’t fit any more. As long as we keep it simple, with few levels, we can communicate and work efficiently.
More games
This afternoon I go to see two more games:
 Games, games games
 We innovated with The Bottleneck Game to be able to accomodate more participants: Portia and I ran two parallel simulations with two groups. Between each round, everybody got back together to share lessons and improvements. As it was only the second time we’d run the game this way, we were a bit nervous. But the game went very smoothly. By the end our smiling participants were uncertified Theory of Constraints consultants. From now on, they’ll see bottlenecks everywhere.
One of the participants who played the role of consultant when so far to as to plot the game on his portable whiteboard so that we knew our cycle time and could see where there were hiccups in the process.
The Business Value Game was too crowded and noisy. We wanted to limit the number of players because we know that too large teams have difficulty to reach consensus. Unfortunately, the room wasn’t large enough to let extra participants sit on the sides as observer.
In this interactive workshop we got to tell stories with the help of different sets of cards. A simple, fairytale-like set of cards led us to tell a meandering story about foxes, witches, queens and treasure. A more complex set of cards with multiple meanings led to a nightmare-like, surreal story with incoherent jumps.
Telling stories allows us to add meaning and emotion to the information we’re giving. The cards add a tactile and visual element to touch on more of our learning modes, not just hearing or reading. These techniques are useful for retrospectives, training and coaching.
Another interactive session, where Jenni and Ole used a flirting metaphor to help us to connect and communicate better with our co-workers. The session was built around and eight step model:
- Radar: first you have to be aware of yourself and your environment
- Target: you have to choose who you need to connect to
- Move in: show interest in the other’s perspective and connect
- Back of a little: give the other person the room, the option, to connect with your or not
- Open up: share something personal
- Dance: have fun together
- Get real: overcome problems together
- Enjoy!
The flirting metaphor was unexpected and could have been awkward, but Jenni and Ole’s humour and the openness of the participants made it a fun session.
Thursday
There are a lot more interesting sessions on Thursday. Looking at the program the theme for the day is likely to be “Business Analysis” because I think it’s essential and we’re still not getting it right. Unfortunately, that means I’ll have to miss Tsutomo Yasui’s Kanban Game.
More about today’s sessions later.
|
|
