Product Camp Toronto was above all a great networking opportunity since there were lot’s of breaks between sessions for conversation. The day started with people sitting at tables chatting – and boy was there a buzz!

In this post I am going to give a quick pass at the four sessions I was at:

• Keynote on what is a product manager
• How to treat Customers like a Market and Markets like a Customer
• Open forum on Crowd Sourcing
• Market Research with Innovation Games

 What is a Product Manager?

The short answer is: someone who makes choices on product every day. John Stetic used the graphs below to show the breadth of skill required for product management and walked through some of the archetypal product managers and where they shine.

How to treat Customers like a Market and Markets like a Customer

Nick Van Weerdenburg had an engaging and insightful session. For me, the most engaging concept is to conceptualize a market as a person. Really ask yourself – what are they like? Personality? What do they think of you? Do they know your product? Good stuff. Read more below.

Open Forum on Crowd-Sourcing

I offered to facilitate this session (since I am getting pretty good at facilitation) and there was no one else around. As it turned out, we had a great mix of curiousity, skepticism and practical knowledge.

At the end there seemed to be consensus that:

Crowd Sourcing is a valuable activity that makes the Product Manager’s life easier, results in a better product and all this with minimal additional workload.

Below is a summary of the Crowd-Sourcing Flow:

Market Research with Innovation Games

Like crowd-sourcing, Innovation Games®are a powerful way of connecting with customers. The main difference is that Innovation Games® are focussed on real-time collaborative games as a means of engaging customers and stakeholders to reveal what really matters to them and to get breakthrough ideas.

I ran the session to give people an idea about using in-person and online games support envisioning, identifying hidden needs, and prioritization. We also briefly played Buy A Feature game online – and there were more than a few people hooked on it.

Slides are below:

Also, for reference, here is the handout summarizing the games:

Summary

I had a great day a Product Camp and would definitely recommend it.

Have you been on a software project where each release gets harder and harder? Many projects fall into the tar pit of the Design Dead Core.

Why do nearly all software projects fail to balance short term choices with long term consequences?

Through game-play you will experience how hard it is to make effective choices. Game learnings will be tied into well-known models in and beyond software such as Technical Debt, Stephen Covey’s Production Capability, and Alistair Cockburn’s theory of competing games.

Recipe

• Game Objective: Participants experience the attraction of short-term thinking and feel the long-term consequences. The game helps executives and managers understand the importance of investment in sustainable development practices. The game is intended to help them get through a Red Pill, Blue Pill moment.
• Number of participants: 6 to 50 (Has been playtested with 40 at XP Toronto User Group Meeting).
• Team size: 3 to 5 people per team.
• Duration: 90 to 110 minutes
• Materials: Game cards (can print or write by hand), pennies (15 per team), dice (two per team)
• Setup: (optional) video projector, tables for group work, whiteboard or flipchart.
• Credits: This game was created by Alistair McKinnell and Michael Sahota.

Session Timetable

1. Intro & Motivate Game [3 min]
2. Break into teams of four or five people. [2 min]
3. Setup Game [5 min]
4. Year 1 [30+ min]
5. Year 2 [20+ min]
6. Year 3 [15 min]
7. Debrief [15 min]

There is a backdrop story that motivates the game situation and is used throughout the game to provide entertainment and inject new rules.

What’s Your Choice?

Here is a photo showing the project choices available to management teams:

Game Narrative

Year One

Resources

• Sustaining Agility Game Options – PDF to print 3″ x 5″ index cards (one set per team)
• Sustaining Agility Score Sheet – Excel spreadsheet to print (one sheet per team)

Facilitation Tips

• It is useful to create memorable even stereotyped characters to help participants connect with the storyline. e.g. CEO has a Texan drawl, CFO is from NYC, Consultant is from California.
• Write Rule fragments on flipchart or whiteboard so everyone can see the rules. I suggest skipping text and just put keywords such as “Invest –>+1D6 Production Capacity”.
• If you have not played the game before, I suggest you playtest it on your own.
• It may be helpful to write up rules on flipchart in advance and then share them when it is time.

Feedback from first run (XPToronto)

• “Fantastic, Magical” – Jorgen Baker
• “Real pressures bottled up” – Alex Aitken
• “Good fun, valuable, opportunity to learn” – Tom Huras
• “Thought-provoking, Fun, Interesting” – Nick Faulkener
• “Lively, Interactive, Team-focused” – Hedi Buchner

Feedback from second run (Agile Games 2011)

• “This game relates hugely to my current work situation where we struggle daily to do thing the right way or increase our technical debt. This game can give great insight to our companies leader to make the right decisions as much as possible.” – A.F.
• “Very interesting game. I’m going to try it myself.” – A.J.
• “Good mix of presentation and game. Provided great thoughts about career goals, revenue and investing in production capability and the future.” – J.V.
• “Great, practical game about strategy and the impact of long-term choices and short-term consequences” – T.M.

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:

1. Generative – for generating new product ideas
2. Prioritizing – understanding relative priorities of different features
3. 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.

There are also other perspectives for viewing the games. Check out the book for perspectives based on prep time, scalability, etc. Another good resources is this one page summary of all the games.

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

Triangle Model

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.

Team Perspective

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)

• Video of Mike Cohn at Agile 2008 and Slides
• Agile Estimation and Planning (book)

Story Map – structure the work in a grid that reflects actual product usage (Jeff Patton)

• Jeff Patton’s blog
• Presentation

Software By Numbers – prioritize work by Net Present Value of Minimum Marketable Feature

• Software By Numbers (book)

Customer Perspective

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 Analysys - Structured Questionaire 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)

• For Speedboat® and Buy A Feature® + more - innovationgames.com and Book

Company Perspective

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

• Aligning and Balancing Your Backlog
• Blog: Why Prioritizing Your Product Backlog for ROI Doesn’t Work

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.

Slides

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).

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.