Agile Project Management for an Agile World

Facilitating Product Development through Innovation Games – Part Two

Introduction

This post is part two of a two part series discussion on Innovation Games.  In part one, I talked about the games Start Your Day, Prune the Product Tree, 20/20 Vision, and Remember the Future.  For more information on these games and why I found Innovation Games so fascinating, please read Facilitating Product Development through Innovation Games - Part One.                 

In this second post, I'll cover the following games:  Speed Boat, Buy a Feature, Give Them a Hot Tub, and Product Box.    I'll give you the game name, its primary purpose, either how we used the game in the two day course (to shape our software development process) or how I have used it elsewhere, and a picture from the sessions (if available).  Again, I hope you enjoy!

The Games

Speed Boat

Purpose: Understand what your customers like and/or dislike about your Product or Service.  Stated another way, what is holding your Product or Service back and what is propelling it forward, in the eyes of the customer.

During the two day course we used the online version of this game.  The online version makes it very easy to run the game with participants who are not co-located.  At press time, registrants of the Innovation Games class get a free one year subscription (a $1,995 value!) to the online games.  Additionally, I recently facilitated this game at the APLN Houston Midyear Checkpoint in June, using a manual process.  Since the pictures I'm showing here are from the APLN Houston Midyear Checkpoint, I will describe how we used Speed Boat during the Checkpoint. 

Using a boat as a metaphor for APLN Houston (our product), we wrote characteristics that are propelling APLN Houston forward and holding APLN Houston back onto colored Post It notes.  Blue/Green Post Its represented "Wind" and Red/Pink Post Its represented "Anchors".  Like Prune the Product Tree, the symbolism has meaning.  Wind was placed above the water line and anchors below the water line.  The further ahead of the sail the Wind was, the stronger the characteristic propelled APLN Houston forward.  The deeper the anchor, the more the characteristic held us back.  It's easy to see how Speed Boat allowed us to visualize our strengths and weaknesses relatively quickly. 

Here are some photos:

    

Buy a Feature

Purpose:  Prioritize features by channeling your inner capitalist!

Using an online market place, participants were given a set amount of money to spend on product features.  Product features were listed for all to see and through the course of the game, we put money down on features that we wanted to "buy". One of the key strengths of this game is that it encourages collaboration because, when setup correctly, participants won't have enough money (individually or collectively) to buy everything.  For an added twist, features can be priced so that they exceed the amount any one participant can afford to purchase, requiring them to collaborate with other participants to purchase the feature.

I found this game particularly applicable to situations where the Product Owner is not the sole expert for the product.  I've seen this in several large organizations where an enterprise class application spans multiple departments or lines of business.  While I am firmly a champion of the one Product Owner rule for Agile projects, the reality is, the Product Owner may not have the expertise to correctly prioritize all the features going into the product.  In this case, Buy a Feature is a great way for the experts to come together to help the Product Owner correctly prioritize the product features in a way that makes sense for the organization. 

While we played this game online, it could be played manually very easily.  Unfortunately, I don't have any photos from this exercise.  I will upload photo's at a later date if available.  In the meantime, if you would like to play a free online demo to see how it works, please visit the Consulting and Training page for my contact information.  I would be happy to setup a demo with you.

Give Them a Hot Tub

Purpose:  Use outrageous features to find hidden breakthroughs.

Using outrageous features, this game capitalizes on a condition called "cognitive dissonance"; which means that your participants will become uncomfortable in the face of something that defies their logic and/or belief system.  If a feature is outrageous enough it should make the participant uncomfortable enough to either dismiss it entirely or transform the idea into something more practical.  However, the key is to encourage a transformation. 

During the game, participants are given a preselected list of features to choose from.  Most of these features will be very practical (i.e. "ability to view year over year sales trends"); however, some will be outrageous.  For example, a feature might state that, every time a sale is lost, the song "Another one bites the dust" plays on the user's machine.  Outrageous right?!?!?  A transformation of that might be that the sales tracking system sends an email to the sales team notifying them of a lost sale.  It's easy to see how Give Them a Hot Tub encourages more out of the box thinking than your typical brainstorming session.

Unfortunately I don't have any photo's from this exercise.  I will upload photo's at a later date if available.

Product Box

Purpose: Identify the most important Product Features.

Using a blank cereal style box as a metaphor for our software development process, each person in the class decorated their box with writings, stickers, and magazine clippings that describe the benefits of their product.  As you can imagine, this exercise generated some friendly competition among the participants. At the end of the session each of us presented our Product Box's to the class in an attempt to sell our product. 

While the creation of the boxes was fun, I found that the real magic happens during the presentations.   We all saw features on each others boxes that we wanted on our boxes.  My suggestion is to not vote on who's box is best, as this encourages an individual reward system which is an Agile anti-pattern (in other words, contrary to Agile values).  Instead, use this exercise as a starting point for future collaboration in understanding how you can take the best features from each box and prioritize those into future product releases.

Here are some photos:  

 

 

Conclusion 

This concludes the second and final installment of our Innovation Games discussion.  I hope I have provided you with some new ideas on how you and your team can unlock the creative potential of your customers and your organization, thereby allowing you to take your product or service to the next level.  Again, Innovation Games creates a FUN environment for stakeholders to come together for some serious discussion around how to improve your product or service. If you're interested in training I encourage you to contact Derek Wade at Kumido Adaptive Strategies.

What has been your experience with Innovation Games?  Do you have additional questions about Innovation Games?  Share them here!

Facilitating Product Development through Innovation Games – Part One

Introduction

As Project Managers we are often tasked with uncovering what our customers need vs. what they want when developing products.  Sometimes this creates tension because the desire to create the right high value items for the organization can come into conflict with the desires of departments and/or individuals.   Furthermore, our ability to maximize business value for a product relies heavily on a strong relationship and high level of collaboration with our customers.  Activities that diffuse this tension and create an environment that fosters greater customer collaboration are high value in themselves.  This is why I found Innovation Games so fascinating!

I was recently exposed to the power of Innovation Games through a two (2) day training session delivered by Kumido Adaptive Strategies.  Our instructor, Derek Wade, provided a very balanced and interactive experience.  We had five people in our class, which led to a more intimate and personalized experience. Not only did we learn creative ways of working through real world business problems, but we also had fun doing it, the latter of which in my view makes Innovation Games remarkably powerful!

We played eight (8) games out of the twelve (12) available.  We did not play Show and Tell, Me and My Shadow, The Apprentice, or Spider Web primarily for logistical reasons.  If you are interested in learning more about these games; as well as, the ones I’ll cover in this article, I encourage you to visit the Innovation Games website.

In this first post, I’ll cover the following games: Start Your Day, Prune The Product Tree, 20/20 Vision, and Remember The Future.   I’ll give you the game name, its primary purpose, how we used the game in the two (2) day course and a picture from our session (if available).   Our product under study was either a software development process we were currently using or have used in the past.  I hope you enjoy!

The Games

Start Your Day

Purpose:  Understand when, how, and where your customer uses your product

Using print outs of calendars in the day, week, month, and year format, we wrote down which aspects of our software development process we practice regularly (ie. Daily standups, release blackout dates, etc).  By visualizing these items on the calendar, we were able to better understand our current process.  It's not hard to see how potential waste can quickly bubble to the surface using this method.  At the very least you will get some clarity on why your organizations does certain things.

Here are some photos:

    

 

                          

Prune the Product Tree

Purpose:  Evolve your product so that it reflects your customer's needs

Using a print out of a tree, we uncovered how our process would need to evolve over time.  The apples we pinned to the tree represented features.  By visualizing the apples on the tree, we got a better understanding of how our process would evolve and in what order.  In other words, the symbolism means something.  For example, the roots represented the must have features in order for the product to be successful.  As we progressed up the trunk and defined the tree canopy, various themes emerged.  We then identified zones around the tree that represented releases.

Here is a photo:

 

 

20/20 Vision

Purpose:  Understand the priorities of product features, market requirements, and product benefits

Using the names of games printed on oversized note cards, the class prioritized the games they wanted to play during the two (2) day course.  The Y axis represented the priority of the game.  The X axis represented whether we wanted to Discuss, Play, or Facilitate a particular game. Our instructor asked us what was more important and then moved the cards either above or below existing ones based on our responses, to show priority.  Some games naturally fell to the bottom since they were not logistically possible.  For example, in Me and My Shadow, the players are supposed to shadow a customer using the product.

Here are some photos:

Remember the Future

Purpose:  Understand your customer's definition of success by seeing how they shape their future

I had played this game before under the name "Futurespecitve".  Like a Retrospective (reference Scrum), the players reflect back; however, they imagine first that they have traveled into the future and use the future as their basis for reflection.  In other words, we imagine that our present is the future and we discuss the steps we took to reach where we are today (with a successful product).  Using a long sheet of paper, we created a time line and placed post it notes at various intervals.  The time line started with Now (or present state) and ended with Outcome (or future state).  In between is the future’s past.  Looking back from the perspective of the future can often present activities and/or challenges that might not be visible by looking forward from the present.

Here are some photos:

 

 

Conclusion

This concludes the first installment of our Innovation Games discussion.  In the next installment I’ll cover some additional highlights from the class.  I’ll wrap up with Speed Boat, Buy a Feature, Give Them a Hot Tub, and Product Box.  All exciting games in their own right!  If you have any feedback you’d like to share, please add to the discussion through this blog or email me directly.  You’re feedback is welcome!

Product Owner Participates in Estimating User Stories

Background

What is the role of the Product Owner during User Story estimation?  In Scrum, the Product Owner pulls from her backlog of User Stories, the top stories she wants to accomplish over the next several iterations.  The Product Owner reads the story out loud then starts a conversation about what she expects from the story. If she wishes and/or the team desires it, she can pass the story around for the team to read.  The team can ask questions related to the User Story; after which estimating begins. For this discussion, I am referencing Story Points (as opposed to t-shirt sizes, etc.) as the estimation method.  All of this happens within a few minutes, but can take a little longer if your team is new to the technique. Traditionally, the Product Owner has been kept out of the estimation process.  After all, the argument has been made (and in my experience rightfully so in many cases), that the ones doing the work should be the only ones doing the estimating. 

Something unexpected

At one of my recent clients, I had the good fortune of being given a Scrum project that was already in flight and responsible for building out a widely used corporate application.  The team had already used Story Points to estimate User Stories in previous iterations.  However, one thing that was radically different then what I had experienced before, the Product Owner participated in the estimating process.   Another thing that was radically different from what I had learned previously, it actually worked for the team!

I have been involved with organizational change for several years now and one thing I have learned is that it is very important to know when to put your foot on the gas, when to take your foot off the gas (i.e. coast), and when to apply the brakes.  In this instance, I decided to take my foot off the gas to see how the team progressed.  I was amazed at what I saw.

The Product Owner:

• Was more actively engaged
• Took greater ownership for the User Stories that were in the backlog and put into the Sprint
• Had a greater understanding for the work required to implement the User Story
• Enjoyed a shared sense of camaraderie with the development team
• Felt like he had a voice that was heard

The Development team:

• Appreciated that the Product Owner was taking a stake in the process
• Appreciated that the Product Owner listened to their points
• Had a greater understanding of the work required on the part of the Product Owner to implement the story ( In many instances during a given Sprint the Product Owner needed to follow up with other people in the business to get finer grained details on how the story should be implemented)

My Thoughts on Why it Worked

In my experience, I found this situation to be unique and I think there were a few factors that led to the success of this estimating approach.

First, the development team had a track record of delivering on commitments within the Sprint.  Based on that experience, the product owner had built up enough trust with the development team that he put great weight on their estimates.  Therefore, he often (in most cases) yielded his estimate to that of the team’s. 

Second, the Product Owner had a consulting background which I believe contributed to his flexibility and openness.  From my experience as a consultant, I have found that in many cases consultant’s have a greater ability to listen, learn, and adapt to a given environment then their client’s employees.  Because a consultant’s work is project based and they work with multiple organizations (and cultures and personalities) over the course of their careers, consultants are often times more in tune with the variability that exists within the organizations in which they work.  I believe this experience helped our Product Owner align estimates more closely with the team.

Third, the development team was extremely good at articulating what was needed to develop the User Story in terms the Product Owner could understand.  I found this trait to be different from most of the development teams I’ve worked with in the past.  Usually, the development team is more comfortable talking in technical terms (i.e. stored procedures, XML serialization, etc) when discussing the complexity of the story.   Explaining things at a level the Product Owner could understand helped add clarity on what it would take to develop the User Story.   

Fourth, the development team was assertive with their points of view.  Again, this is something that I found in contrast with most of the development teams I’ve worked with in the past.  Often what I experience in large organizations is that the Product Owner (or anyone from the business for that matter) is in a position of strength and the development team is unlikely to challenge the Product Owner.  Obviously, in these situations, it is not a good idea to have the Product Owner estimating with the team.   However, this was not the case in this situation.  If the development team held up a number that was higher than the Product Owner’s, they stood their ground on why they felt it should be the higher number.  Any disputes were worked out by the TEAM (inclusive of the Product Owner).

We estimated like this for the duration of the project, until its successful conclusion.  I even complemented the team on their estimating techniques and skills (they laughed!) at our last retrospective. Have you found yourself in a similar situation or have a differing view point on this?  If so, I’d like to hear! 

Blog Start

When I broke the champagne bottle on my blog and wrote my first post, I initially thought it would be something safe.  I thought it would conform to what most of the books, articles and presentations seem to be saying.  However, the more I thought about my first blog post, the more I wanted to talk about something that diverged from the purist and/or more traditional Agile views.  After all, we are living in an Agile world, and executing Agile Project Management means adapting our projects to the changing environments that we are forced to operate in, even if it means applying practices that are contradictory to mainstream thinking.  In other words, as Joe (Jochen) Krebs says, “Making tradition means breaking tradition”.  While many posts on this blog will conform to tradition (because they have worked for me), I hope you also learn from the traditions that have been broken in order to make my projects successful. 

Enjoy!

Alan