Subtitle: How we created and played a brand new game all in one day.

On Day 2 of DeepAgile, Michael McCollough and Don McGreal got us started on with a game design workshop. From there we used open space to invent and play the game with other attendees. This blog shares what we learned about product backlogs and game design.

Getting started: A room with a view

The first job in open space was to create 3 consecutive session in the open space (one for each of: objectives, design and play – see photo). I announced that each open space session was independent and that people could attend just one or all – we would do a re-start at the beginning of each one. Working and collaborating with others – what a great way to use Open Space.

I scoped out an amazing room at NERD with a round table, ceiling-height whiteboard and a spectacular view. Perfect for inspiring a team and encouraging collaboration.

Learning Objectives: Keep it simple

We started with a long list of learning objectives at the end of Mike & Don’s workshop (see photo on left). We knew this was way too long and had it winnowed down to the three within the next hour (see photo on right). By the end of the day we had stripped it down even further to just the first objective: there are multiple ways to represent a backlog. KISS strikes again.

The Problem: Product Backlog Management has challenges

The starting place was to help product owners to organize and prioritize their backlog. We spent discussed the topic for a while to get on the same page. We figured out there are a whole bunch of steps involved in building and maintaining a backlog (See diagram below):

1. Identify Stakeholders
2. Identify work (Stories)
3. Estimate work (units, T-Shirt sizes); identify risks
4. Organize & Prioritize <– Focus of our game is on organizing
5. Communicate
6. Execution & tracking (Release burndown/up)
7. Re-prioritize

(We had a great diagram on the whiteboard but can’t find it. So I redrew it from memory and added some flourishes.)

The simple act of preparing brainstorming objectives for the game led to a better understanding for all of us on the full life cycle of a product backlog. The big picture allowed us to focus in on one part: organizing and prioritizing. Even this was too big! We split approaches and concepts into ones that were more about organizing and ones more about prioritizing. At this point we had three game concepts:

1. The missing stakeholder game – who are my stakeholders and why are the missing? (prioritization)
2. “Malfunction at the stakeholder junction” – AKA the dysfunctional stakeholder game. “I want this.” “No, I want this.” (prioritization)
3. The Backlog is in the eye of the beholder – all about organizing based different stakeholder perspectives. (organization)

We did a strawman vote and there was a clear consensus around moving forward with the last one – on organization of the backlog.

Working together on the game

It was fun. Really fun. I played the role of product champion and facilitator.

We started with the Pomodoro Technique to stay focussed and on track (yes, I even drew tomatoes on the whiteboard).  In the design session, we got into a state of flow and just kept going to meet our timebox.

We had to deliver a game since it was announced and on the open space board! As my thesis supervisor said – “Nothing concentrates the mind like a deadline.”

We did lot’s of brainstorming. Everyone was really good about coming up with ideas and letting go of ones that weren’t working out. One idea Greg Ott came up with was that of a garden (see photo on right). After a while this turned into the the farm metaphor we decided to use for the game. In retrospect, having a huge wall to keep ideas alive was invaluable.

Playing the Game

Playing the game was a lot of fun. You could feel the energy in the air (see photo) and the room was packed with designers, players, and observers. We got mostly very positive reviews.

You can find the game rules and feedback here: Backlog is in the Eye of the Beholder Game v0.7 This is our current version. It is also posted on TastyCupcakes game site. Feel free to use and make your own.

Thanks to everyone who designed, played and supported us. Special thanks to core co-inventors: Warren Elliott, Greg Ott, Mary Gorman, Dan Zaino, Judy Rivais.

(This is part of a series on DeepAgile 2010 Games Weekend).

Michael McCollough and Don McGreal ran a valuable workshop on how to create your own game. Mike and Don have been creating simple, fun games for years and have noticed an approach they follow. See TastyCupcakes for lots of great games. As a caveat, they outline one particular style of game development – simple games. This is in contrast with complex games such as XPGame and Business Value Game (which are favourites of mine).

It all starts with a problem. What do you notice going wrong? What do you want your teams to understand better?

Next come your objectives. Pick one to three things that you want the game players to learn.  For extra points you may want to consider the Dreyfus model or Bloom’s taxonomy. These were suggested by attendees. Mike and Don keep it simple.

For a while you will need to spin and loop around as you search for an idea. As this happens, it is helpful to be constrained by some principles: stick to objectives and keep it simple (KISS). Inspiration will come from material (cards, balloons, etc), as well as games in other industries. Their mantra is “Beg, borrow, steal” and them make it your own. Learn from your participants – they will tell you a lot if you listen.

Finally, summon the courage to try it (or just do it). Start as soon as possible and iterate.

And remember, the whole point is the debrief. Give ‘em space and let ‘em discover.

(This is part of a series on DeepAgile 2010 Games Weekend).

Tobias Mayer led a fun and effective session (Agile Playground) at DeepAgile where we played games for building team and collaboration.

Movers and Shapers for team dynamics

I first played this game with Tobias at Agile 2009 and found it very powerful for teaching the impact of our behaviours on team dynamics. There are three rounds of simulation with different focus on how to interact with others. A detailed write-up of the game is on Tobias’s blog. Very handy for shifting thinking and focus to team behaviour.

Hypnotizing Hypnotist for pairing and collaboration

This is a very cool exercise to provide participants a sense of directing, following and collaborating. The group is formed into pairs. One person is the hypnotist and guides the other person with their hand. The hypnotizee’s job is to keep their face 1 foot from the hand of the hypnotizer (see Tobias hypnotizing on left). Debrief. Roles are reversed. Debrief.

Now it gets really fun. In the next stage, pairs hypnotize each other at the same time (see Lyssa and Tobias on right). This generates some laughs and interesting behaviours. I think we also ran it with one half of the room at a time so we could see what was happening. Remember to applaud.

Other stuff

There was other really cool stuff I am skipping over:

• Failure Bow – give people the freedom to take risks and recover from mistakes. This allows them to be available and productive rather than discouraged and disengaged.
• Pair storytelling – One person puts their hands behind their back and the other stands behind them and becomes their arms and hands. Once a story topic is established, the participants get to tell a story together with the hands leading.

(This is part of a series on DeepAgile 2010 Games Weekend).

Lyssa Adkins ran a very practical session at DeepAgile that shared several tools for team formation or for tuning up existing teams. She often uses these right at the project start since team members may know very little about one another – even if they have been working together for years. Here is a run-through of three of the exercises.

Constellation – Understanding each other through motion

I love this exercise. It provides the team members as well as the coach important information about everyone on the team. It is called constellation since everyone arranges themselves around an object on the floor (in our case a roll of tape) depending how they feel about a statement such as “I like getting results”.  People align their bodies with the statement: standing beside the object signifies strong agreement while standing far away to signifies strong disagreement. It is very powerful since people are engaging their whole bodies. To learn more, there is a full write-up on Lyssa’s blog.

 

Timeline – sharing our pasts

In timeline, each participant draws a timeline of their life with peaks, valleys and major life events. In turn, each person describes their timeline to the team. Team members listen and note skills or talents (on sticky notes) that stand out. These are then posted at the bottom of the timeline and reviewed as a team. This approach is about figuring out who the person is and what special perspectives they bring to move the project forward. When we did this, it helped the demo subject feel more positive about their talents. Nice.

 
 

Marketplace – sharing our talents

In marketplace we pretend we are a vendor in an open-air market place and decide what wares we have to sell. What are our special skills and talents that pertain to this project? We even get to create a banner to attract people. Under the table are things that are true for us, but may not directly relate to the project. The debrief is the same as timeline. Usually a coach will use one or the other (in the training session half of us did marketplace and half did timeline).

Below is my marketplace as an Agile coach.

(This is part of a series on DeepAgile 2010 Games Weekend).

At DeepAgile2010 this past weekend Mike McCollough led a session on Retrospective Games. We played a brand new game called Balloon Madness as an excuse to use several different retrospective formats. The game is in the conference booklet but is not yet posted on TastyCupcakes (check site for lot’s of fun Agile learning games).

What I learned about retrospectives

• Change the format on a regular basis. One attendee switches things up every retrospective.
• You can get great results by focussing on more of what works. This is inspired by appreciative inquiry. We are so used to looking at what the problem is, that looking at success can have a powerful shift.
• Another was to have each person write a personal commitment story card for something to do in the next iteration. They signed the card and someone else agreed to pair with them on it to provide support. The cards were posted beside the scrum board as a reminder. They were reviewed at the start of the following retrospective.
• Liked-Lacked-LongedFor was also suggested as a powerful way to connect with people’s deeper selves.

At DeepAgile in Boston, I played Yellow Brick Road: Fresh InsightsThrough Peer Coaching. The game was led by it’s inventor – Portia Tung who did a great job even with a very large group. If you haven’t played this, I suggest you make the time.

The game teaches people skills and resources to be effective coaches by practicing with peers. In the game, people take turns in one of 3 roles: Client (with a problem), Coach, and Observer.

Solve real problems

In the role of Client/Dorothy, you get to be yourself and bring up a problem that you want to work on. Over several iterations, new perspectives help you access the resources you already have. So a cool side-effect of this game is that you get fresh insights into whatever problem you want to work on.

Coach practices questions

The coach gets to practice listening and asking questions. We discovered that listening is something we need to practice since we are so used to jumping in with our expert opinion and solutions.

We also get practice with different types of questions (image by Portia Tung):

Observer provides depth

The observer roles gives you a chance to step back from the situation and really notice what is going on. Portia’s picture captures the simplicity of the task:

I was reminded that observation is a very helpful debugging technique. It is also less than easy – especially if you are like most of us and out of practice.

As the observer, I was able to get much deeper insights.

Go play this game

I am going to play this game again for myself and to help those I am coaching. The complete game instructions and presentation is available for download, so give it a go! I’m sure you will get value out of it. Even better, get Portia to come play with you so you can see some of the finer points.

(This is part of a series on DeepAgile 2010 Games Weekend).

Alternate Title: A model for understanding Scrum and Kanban

(Cool diagram below – skip down if you are in a rush Or check out the 3 minute video explaining why Scrum and Kanban are complementary.

As I flew home after LSSC10, I wondered how Kanban-style software development would shape my world in the years to come. I self-identify as an Agile/Lean Coach and wondered what the road ahead looks like for me.

Someone at the conference commented that Kanban was going to dominate discourse in our community. Some people in the Kanban community say it is more widely applicable and is a more rigourous approach. Another commented that software processes historically have a 7 year run and so it is time for the age of Scrum to wane. The arguement goes that even if Kanban isn’t better, the community needs a new buzz to keep things going. All this made me wonder.

Is this true? If it is true, what does this mean for me? How can I reconcile this with what I know works? Before we delve deep, I need to share where I am coming from.

I use Agile

I have used Scrum for many years as a starting point for Agile transitions. It is compact, creates visibility, and builds a team culture. I also use XP practices.

I use Lean/Kanban

I have been using Lean concepts for many years and very heavily in the last year. I have made extensive use of Kanban-style Scrumboards as well as pure Kanban boards for business and support groups. I have had great success with other tools as well: root cause analysis, the A3 technique, and value stream mapping. This winter, I implemented Kanban with a 18 person software group and shifted behaviour with a cumulative flow diagram.

For me, Agile includes Kanban

When I read the Agile Manifesto and principles, I don’t see anything that excludes Kanban. All the XP technical practices still apply – perhaps even more so. Scrum notions of Product Owner, Product Backlog, and Retrospectives still hold value. Iterations may be gone, but they have left a trail of useful concepts of tools that the Kanban community enjoys. Maybe 80% is the same. Why am I making this point? Some proponents on Lean and Kanban highlight the differences rather than relationships: “Kanban is new!” “We are post-Agile” – as if that were cool. Our community is better served by focussing on the positive in every approach.

What I learned at LSSC10 that shifted my thinking.

At LSSC10, I started noticing contexts – what environments and circumstances encourage Kanban-style Agile.

Support Kanban What blew me away was a keynote case study on Kanban turned out to be about a couple of support groups who figured out that Scrum is not a good fit when there are lots of interrupts and emergencies. Ah, um, … not really news. This is the canonical case for Kanban.

Naked Planning or using XP for single-piece flow is about creativity and cross-functional teams swarming work (MMFs). The context here appears to be a team with a lot of focus working on innovations. This is much more similar to Scrum/traditional Agile rather than Kanban.

(Vanilla) Kanban Mike Fitterman and Rick Simmons of Constant Contact told the story of how Scrum wasn’t working out. Two development teams shared QA and product people and found there was too much planning and communication overhead. (Ooops, sounds like ScrumBut.) Anyway, the context in which they applied Kanban was with one with specialists and group that was too large to be a team.

Vale Kanban Alisson Vale described an environment with small work packages that come from a variety of demand channels. (See also video). It very much sounded like system evolution rather than discontinuous innovation. Interestingly, his model does not follow work decomposition by role but rather allows flexible routing and story swarming much like XP.

Production Line Kanban and (Vanilla) Scrum Most insightful of all for me to outline contexts was Clinton Keith’s session on video game development (go read it). He used a timebox for creative work both with takt-time in production-line style Kanban and with Scrum during design and problem solving phases. So, in this situation, they see Scrum for exploration and Kanban for cranking stuff out.

Scrum and Kanban fit different contexts

• Kanban can handle a lot of interrupts
• Kanban supports specialized roles with divergent skill sets
• Kanban excels at repeatable work such as a production line
• Kanban works fine for groups larger than 7+/-2 since communication and planning overhead is lower

• Scrum excels at projects requiring deep collaboration and innovation
• Scrum works best with small cross-functional teams (7+/-2)
• Scrum is great for providing shared goals and work context
• Scrum encourages generalists

For a more comprehensive list of similarities and differences see Kanban and Scrum – making the most of both. See also Jason Yip’s recent observations.

A model for thinking about Scrum and Kanban

I am a visual thinker so I need a picture to put it all together:

• The vertical axis differentiates environments with a strong focus from those with many interrupts and divergent needs.
• The horizontal axis indicates the spectrum from defined, repeatable work to exploratory and innovative work that benefits from swarming.

Every process has a sweet spot

I have indicated where I see various process styles play best. (For example, Scrum is good when there is focus and exploration.) The dashed lines suggest  that these are not hard boundaries. The regions and shapes are more illustrative than literal.

In this model, Kanban is at centre stage. I have repeatedly witnessed first hand that Kanban is very easy to implement and provides great benefits.

I also have seen the value in creating small, focussed teams using Scrum. For sure it is harder and yet very rewarding. On the downside: it doesn’t fit all contexts.

In truth, I am not 100% satisfied with the fidelity of this model, however, it helps me understand how to approach work with my clients

We need to know both Scrum/XP and Kanban

If all you have is a hammer, everything looks like a nail.

What tools do you have in your belt?

Henrik Kniberg gives the metaphor of comparing a knife with a fork. Which one is better depends on the situation. We need need to know both Scrum and Kanban. XP, too, but that goes without saying.

As an Agile coach I need to understand a client’s situation to know whether to start with Kanban or Scrum or both. Miyamoto Musashi – a famous Japanese Samurai spoke regarding choice of tools – said “You should not have any special fondness for a particular weapon, or anything else, for that matter. Too much is the same as not enough.”

Let’s build community

For my Scrum and XP friends, Kanban is here to stay and it is going to continue to grow; let’s embrace it and help mature it.

For my Kanban friends, let’s build bridges and create a strong inclusive community.

Hungry for More?

• Kanban and Scrum – making the most of both by Henrik Kniberg and Mattias Skarin
• Kanban by David J Anderson (Just released)
• Scrumban – Essays on Kanban Systems for Lean Software Development by Corey Ladas

Thanks

Many thanks to Jason Yip for helping me refine my thoughts and to Siraj Sirajuddin for getting me to attend LSSC10.

What do you think?

The picture I am painting may be missing something. Please share comments or get in touch with me directly to build a better model.

Alternate title: Most Scrum teams need a Kanban board

I am a big fan of Scrum, however, the notion that there are no interruptions during a sprint is simply not realistic in many environments – especially teams adopting Scrum.

Let’s dream of perfection

A key concept from Lean is to dream of perfection. In this case, perfection is “no interruptions”. This is good as a goal but not as a starting point.

Deliver Value

Let’s face it, there is a lot of business value in keeping a production environment up and running. Almost universally, this is more important than getting that new feature out. Unfortunately, this value is usually a form of waste since there may have been things that we could have done to avoid production issues in the first place. It even has a name: failure demand. When we dream of perfection, we dream of zero production issues.

Oops. We live in a world where there are external events. Yep. It’s true. Even Scrum teams. Maybe it’s more useful to drop a story or shallow out some functionality when some important external interrupt happens rather than abort the entire Sprint.

Ken Schwaber told the story of getting kicked out of a client close to home for attempting to veto the company picnic in favour of focus on the Sprint commitment. I keep telling the teams that they are part of a bigger picture and they need to be in tune with that.

I follow the rule of letting Product Owners swap out unstarted stories for new ones if the team agrees. This comes from XP. Darn, broke another Scrum rule in order to maximize business value.

A separate support team is an anti-pattern

I keep getting asked – hey, can’t we have a separate support team?  Then there won’t be any interruptions. NO! Funny thing is that most technical folks don’t want to be on the support team. But the main reason is that it is very useful to have people developing software fix their own bugs and appreciate what it takes to get something working in production. Otherwise defect rates will climb steadily and that’s the wrong direction to go. We want zero defects, not more.

Most Scrum teams need a Kanban board

For as long as I can remember most teams I have worked with have had a support board where we track the actual hours spent on support. Why actual hours? This gives us history and the ability to predict support workload – very handy information during a Sprint Planning Meeting.

More recently I have used a Kanban board for managing support issues.  See sample photo below.

So now, my thinking is that most new Scrum teams probably need a Support Kanban. How about at your company?

Sadly, I did not do as good a  job capturing the the LSSC10 keynote sessions as I would have liked, but maybe I captured something you missed…

Don Reinertsen really turned me off at the start of his session (The Easy Road to FLOW Goes through a Town named LEAN) which started with what felt like Kanban bashing 101. Many of his comments seemed aimed at a literal implementation of a production-like Kanban system in software – something I have not seen in practice. Despite this misdirection, there were some very strong points that I would like to highlight. See video/slides on InfoQ.

Elimination of Variability is Toxic. Great Product Development requires creativity, taking risks and encouraging failure. No errors means no learning. This reminds me of Jared Spool’s Keynote on building great products and aligns with efforts such as Enough Kanban! Use XP for Single-piece flow.

Don also introduced the Internet (TCP/IP stack) as a very different model for work execution. Again, I was a little disappointed since a lot of teams are already  implementing similar elements. e.g. Different quality of service through urgent tracks in Kanban boards. A number of people said the talk was a quick synopsis of his new book: The Principles of Product Development Flow: Second Generation Lean Product Development and contains ideas that will shape lean software for the next five years. These are smart people so I am going to have to get the book.

Risk, Lean Development and Profit

The second keynote was by Bob Charette.  I love the quote he shared with us about assumptions and risk:

“It’s not what you know that can hurt you; it’s what you know that ain’t so” – Will Rogers

I am reminded of the damage assumptions can bring every time I train people with my Scrum-friendly version of the XPGame. Bob points out that assumptions are risks we have accepted.

Profit = Exchange of Risk. There are three types of risk:

1. Information
2. Control
3. Time

We need to choose between these to maximize profit

Related Posts

Check out blog post: Above All, Stay Open to New Ideas, Humble to the Current Limits of Our Knowledge, and Be Ready to Innovate, Absorbing Ideas from Other Bodies of Knowledge

Mary Poppendieck gave her usual well-researched and convincing tour-de-force presenation at LSSC10 on several approaches to organizational change with a talk titled “What’s wrong with targets?”

The purpose of the whole talk is to trash Management by Objectives. See my related blog noting the damaging effects: SMART goals may not be that smart. As an alternative, Mary shares 4 effective models for organizational change.

I have heard a lot recently about the book Switch: How to Change Things When Change Is Hard by Chip Heath and Dan Heath. It uses the metaphor of the Rider and the Elephant. I like it a lot since it lines up well with my NLP tools and understanding of the unconscious mind. Anyway the change model is very clear:

1. Direct the rider – provide clear direction and objectives.
2. Motivate the Elephant – appeal to emotions to provide energy for change.
3. Shape the path – create a supportive environment that will keep things on track.

Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results by Mike Rother is a second approach for driving change. Check out the above description in the mind map. It reminds me of the A3 technique that I have been using for the last year with great success. I’ll blog on my experiments later.

Strategy and Deming’s systems analysis + PDCA + People were the two final models to round out organizational change approaches that involve people rather than measure them. Caveat: SMART is OK for projects; not people.