Here is the way one way to see Innovation Games® (Click for hi-res image).
The diagram came out out Luke Hohmann’s Innovation Games® Master class in September. In my search for order, I decided there were three main categories of innovation games:
- Generative – for generating new product ideas
- Prioritizing – understanding relative priorities of different features
- Understanding Product Use – all about how customers use the product today
In the diagram I have bucketed each game in it’s primary category. The one that resists this classification is Prune the Product Tree which can be very unstructured and generative (participants write features) or highly structured and used for prioritization (features are pre-selected). It all depends on who writes the leaves.
A big thanks to Luke Hohmann for sharing the images under creative commons license.
Here are the slides and reference links for the session Gino Marckx and I are giving at Agile 2010 in August
Selecting and delivering the most important work is a critical success factor in Agile projects. But how do you know what is important? Unless you are psychic, some help would come in handy. Consider the diagram below to help make sense of the wide variety of strategies and tools.
We explain three different perspectives: Company, Customer, Team.
The product backlog needs to be structured so that it informs the team of the vision and the work. Whenever the company or the customer priorities are not clear, the team will need to rely on general information and it’s common sense.
Theme Scoring & Screening – Relative or numerical weighting based on criteria (Mike Cohn)
Story Map – structure the work in a grid that reflects actual product usage (Jeff Patton)
- Jeff Patton’s blog
Software By Numbers – prioritize work by Net Present Value of Minimum Marketable Feature
The product backlog prioritization is done from the customer’s perspective, from the perspective of whoever is paying for the product in the first place, whether this customer is internal or external to the company doesn’t really matter. What is most valuable to the customer will be on top. Techniques focussing of this view require strong product domain knowledge, and a good understanding of the impact of specific features on the business.
Kano Analysis – Structured Questionnaire to determine feature relevance: Mandatory, Linear, Exciter
- See materials of Mike Cohn from Team Perspective: Theme Scoring & Screening
Innovation Games® – 12 Games to better understand your product and what’s important (Luke Hohmann)
Companies need to find a balance in distributing the effort over multiple customers and/or products. But they also need to take the company and product strategies into account, deprioritizing features that might be very valuable for customers but aren’t in line with the company’s vision. As well, this takes into account stakeholders other than customers and sales – support, professional services, etc.
Company and Stakeholder Strategy
Business Value Game – Simulation to illustrate how organizations can define their own business value model.
- Game instructions
Allocation Model – helpful to balance priorities with divergent or competing interests
- See example by Alisson Vale: Slides 40-49
Where to go from here?
The most common questions we have gotten after presenting these techniques are “How do I decide where to start?” and “How do these work together?”
These are complementary techniques and are used to solve related problems. Our recommendation is to start with the area that is the biggest challenge for your project. Maybe this means talking to stakeholders you normally don’t talk to. Maybe it means putting a Story Map up on the wall. It depends.
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):
- Identify Stakeholders
- Identify work (Stories)
- Estimate work (units, T-Shirt sizes); identify risks
- Organize & Prioritize <– Focus of our game is on organizing
- Execution & tracking (Release burndown/up)
(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:
- The missing stakeholder game – who are my stakeholders and why are the missing? (prioritization)
- “Malfunction at the stakeholder junction” – AKA the dysfunctional stakeholder game. “I want this.” “No, I want this.” (prioritization)
- 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
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).
Derek Longmuir presented ThoughtWorks QTB on working with legacy systems. You can see the video and slides on InfoQ.
I like the definition given by Michael Feathers:
Legacy code is simply code without tests.
Legacy Systems have Value. They are usually business critical and feature rich. They may even be stable and reliable (YMMV). Hint: in the MindMap below, start at 3 o’clock and go clockwise.
Why change from a legacy system? There are number of good reasons: obsolete technology, can’t add features, system is fragile.
This is an important problem since most systems we have 10% of the effort to build and 90% effort to maintain. So to manage costs, we need maintainable systems.
What to do? Traditional approaches such as Big Bang (think explosion) and wrapping/hiding legacy systems rarely achieve business objectives.
Do a system health check. Look at the code. Get complexity measures. Look at test code ratio. What state is the system in?
Before getting started, there are some tools that you will need for basic technical hygiene. The equivalent of brushing and flossing your teeth is test and build automation.
How to tackle this?
With the Strangler approach, the goal is to strangle the existing application by building a new system that runs in parallel. The idea is to put a new interface in place and begin migrating the functionality in a piecewise fashion. This approach takes a lot of effort and makes sense when there is no hope for the existing code base.
The Phased approach is about rehabilitating the system piece by piece. How do you eat an elephant? One bite at a time.
Strangely, there was no mention of the bible on this topic: Working Effectively with Legacy Code by Michael Feathers. This book is a must-read on this topic. As is Refactoring, Refactoring to Patterns, and Clean Code.
Part of my standard training for Product Owners is to help them understand how they relate to everyone else in an Agile/Scrum world. Hence the drawing below.
Project Community Diagram
The Product Owner is not part of the team since their role is to ask for more to keep productive tension in the system. I like the way Ron Jeffries narrates about the Product Owner Role without ever using the term. This is a good story. So is the follow-up one.
I like the XP notion of the customer team to reflect the group representing the customers interests. (If anyone can suggest a good link/definition, I’ll add it.)
Why is the ScrumMaster outside? Their primary role is to act outside of the system to help it function and grow. Why is the ScrumMaster cheering on top? Ooops. That’s a bug. If I had time to re-draw, I’d put them underneath holding up the whole system as a servant leader.
So what do you do, if you don’t like the way I have parsed the world? Please help me understand your perspective – draw a picture to show me the world through your eyes.