My Innovation Games Project Box experience

I was lucky enough to attend an Innovation Games workshop facilitated by Luke Hohmann at SDEC12. If you get a chance to attend a workshop facilitated by Luke Hohmann, I encourage you to jump at the chance. I learned as much about facilitating workshops and sessions as I did about Innovation Games. It was fascinating and impressive seeing the attention to detail that Luke gave to every facet of the session. Everything in the session was well-prepared and all the activities reinforced the principles and concepts taught.

I especially appreciated the insights Luke gave into the psychology behind serious games and the methods behind them.

Product Box

In the workshop we were able to try out the Product Box game. We used the idea of Google’s Internet-enabled glasses as a case study for the workshop. We had three separate teams that each designed their product boxes collaboratively and then presented them to everyone else to ‘sell’ them on what they felt was important.  The insights and innovations that were captured from that session were very powerful and impressive.

After the session I was very interested in trying the Product Box game in a real situation.

Project Box

I am currently on a major systems integration project and I thought it would be interesting to use the Product Box game and combine it with the Remember the Future game to hold a retrospective on the current project. We had about 15 attendees that all were on the project in different roles. I spent quite a while trying to frame the question that I thought would allow for the most open thinking and ideas related to the project. I eventually settled on:

“Imagine we have completed the project and it was a huge success. The company is now trying to re-sell the solution we developed. Imagine that the solution could be sold on a store shelf. Design the box that would communicate the strengths and functionality of the product”

The Results



Just like we saw in the workshop, the ideas that were presented we truly original and delivered some insights that were unexpected. Here are a list of some of the capabilities the teams thought were important:

  • Business Rule Based
  • No Assembly Required
  • Made in Canada Solution
  • Low Monthly Fee
  • Low Risk
  • Industry Standard
  • Strategic Partnerships
  • Compatible with SAP
  • Easy Integration
  • Cost Effective
  • Standard Interfaces
  • Increased Automation

While some of these items were expected, I was surprised by some of them and also by the items that weren’t there. There was no mention of cost at all. One observation that Luke was that cost usually isn’t one of the first things people focus on, it is usually just about the functionality and capability.


Everyone that attended thoroughly enjoyed the session and they felt they benefited from the ideas generated. Everyone also agreed that this activity would be great to do with the business users at the start of every project to confirm/validate the business requirements and the relative importance of those business requirements. I can’t wait for the opportunity to use the Project Box game as part of a Project Charter meeting. I think it would generate excitement, enthusiasm, ideas, and a shared vision as part of a project charter.

When is the last time a Project Charter Meeting could say that?



More #Agile and less #computers in the classroom

As a parent whose children are entering grade 1 and grade 2, I find myself being more and more interested and concerned about the trends and proposed practices that are being used in the educational system now and in the future. One aspect I find myself having concerns with is the addition of computers to the classroom. My concern is not related to the use of computers in general, but more to how computers are being integrated into the classroom activities themselves. As we have seen in Agile and in Software Development in general, adding technology to a system rarely improves the system by itself. In fact I have had experiences where the introduction of technology to an existing system has made the system much worse.

I find it ironic that as we are re-discovering new ways to collaborate in Agile, the educational system seems to be going in a different direction. In Agile, we are looking at non-technology solutions as a better way to collaborate and communicate. From User Story Mapping to Innovation Games to Silent Brainstorming to Paper Prototyping to UI Design Studio, we in Agile have discovered that getting the person-to-person communication maximized has an immediate and impressive effect. In addition, we have also discovered the incredible increase in communication and comprehension when moving from textual to visual communication.

The science behind Silent Brainstorming as a means to generate new ideas and innovate is startling. Steve Rogalsky made an excellent presentation at both Agile 2012 and SDEC12 on the topic. You can find the slide deck by following this link.

More Stickies less Texting

I understand that the computers will be used for educational research purposes and this makes perfect sense. Everyone I know consults the Oracle of Google daily. I feel the more concerning use of technology is to use technology to replace basic mathematical and communication skills. For example, I have heard that exercises will require the answers to be texted or emailed to the teacher. I understand that this is being done to increase the engagement of the children. Although this may very well increase the engagement of the children, I fear that the value of the skills being taught is being lessened. I also believe that any use of technology to perform mathematics that the individual cannot do without the computer is fundamentally wrong. The computer should be an aid for execution, not a replacement for learning.

More importantly, where are we teaching the critical thinking skills, creativity, innovation, and problem solving skills? These are the skills that will drive the economy in the future. I honestly can’t see how the addition of computers to the classroom will help in this regard.

I sincerely hope that group activities and group projects are still a critical component of the education, but how much better would the curriculum be with exercises in Silent Brainstorming? Teams would experience how to self-organize, facilitate, and that the best ideas don’t always come from the loudest or best speakers. There is an excellent TED Talk on the Power of Introverts by Susan Cain that you can find by following this link.


When my child’s teacher requires computers in the classroom, I know I will be asking for a description of how they plan to be used. I’ll probably even take the opportunity to discuss principles recently presented by both Steve Rogalsky and Susan Cain.

Our children are worth it. Spread the word.

#SDEC12 Conference Review #Agile

Well another Software Development and Evolution conference has come and gone. (You’ve always wondered what SDEC stood for didn’t you?) It was a lot of work and effort to make it all happen, but in the end it was very enjoyable. I learned an immense amount and cant’t wait until next year.

My Highlights

      • The Joe Justice/Wikispeed Keynote on day 1 was entertaining and inspiring. If you aren’t familiar with the Joe Justice and Wikispeed story, I highly recommend you doing a search on YouTube or Google. Inspirational stuff on what can be accomplished when you ask why not? WikiSpeed
      • The Luke Hohmann/Innovation Games keynote on day 2 was energizing. I have been a fan of Innovation Games for a long time and it was energizing to hear Luke speak and provide the context on how and why Innovation Games are successful. InnovationGames
      • Adam Yuret @AdamYuret brought Lean Coffee to SDEC12. It was a highlight of mine to attend his session on Lean Coffee and learn how we can have our own Lean Coffee discussions. Although I must admit, I would prefer an afternoon coffee instead of an early morning one.
      • Chris Dagenais @MDChris had a couple of engaging and informative sessions on team building and peer feedback. Great sessions and audience was very engaged and interactive.
      • Lightning Talks made their first appearance at SDEC and were very well attended. There were great talks and tons of practical information compressed in 5 minute chunks.
      • Best presentation I attended was presented by Mark Kulchycki and Alyson Teterenko of Manitoba Hydro International. It was a real life tale from the trenches on how their team evolved and incorporated Agile principles into their PSCAD product development team. Awesome presentation, pragmatic approaches that everyone can use.
      • My personal highlight of the conference was the Innovation Games workshop with Luke Hohmann after the conference. It was an excellent session where Luke not only covered the Innovation Games themselves, but also the science and psychology of the games and the art of facilitation. Probably learned more in one day than I have for a long time.
      • I loved presenting my Agile Data Warehouse talk. I’m hopeful that I can have a follow-up presentation at SDEC13 that illustrates more how we used Innovation Games and show the actual models that were created.
      • It was great being able to just talk and share with everyone at the conference on what worked for them and what people are still struggling with.


It was a great conference with over 200 attendees. This was a new record for SDEC and caused us to be flexible to modify the lunch process for Day 2 to be more efficient. 🙂

I can’t wait for next year. We are gathering the feedback forms and listening to our Advisory council to assure the content and structure is even better next year! Thanks for your support and see you at SDEC13!

How an #Agile Data Warehouse leveraged an #InnovationGame – Iteration 2!

A few weeks ago I authored a post that explained how were leveraging an Innovation game on my current Agile Data Warehouse project. You can find the original post here.

Iteration 2

One of the aspects I love about Agile is the freedom it allows you to be bold as it acknowledges it is impossible to get it perfect off the bat. I find that this encourages people to take a chance and try new things. If it doesn’t work? No problem, we will just adjust and get better as we progress.

My initial blog proposed using a visual Innovation Game with Visual Report Boards to allow for brutal transparency and the management of the data requirements for an Agile Data Warehouse project. Each Visual Report Board had an object at the centre with 6 dimensions around it that illustrated how the object could be reported on. (I affectionately refer to these boards or diagrams as Hexes) Our Objects were the people who the corporation were interested in. It turns out that this method has been successful. It has allowed us to create a visual backlog of data requirements and have the clients prioritize the work and guide the work according to the overall business priorities.

Why am I writing this blog then?

Well it turned out that once we started placing the data requirements or reporting stories on the Visual Report Boards, it became apparent that our objects and dimensions of the diagrams required tweaking.

Initially I had placed a Person object at the centre of the diagram. The dimensions where then aspects of how we need to report on that person. Although this object and dimensions may work for other projects, it did not work for our project. (Actually I think that most Data Warehouse projects would probably make the same change we did, but I’ll let you decide that for yourselves)

Our experience was that most of the reports or data requirements were very clustered on the Visual Report Boards and the diagrams did not allow for the visual communication of what the report was or what data was required. I was starting to worry that this process might not provide the brutal transparency that allowed for the efficient creation of a Data Warehouse in an Agile way.

Just the Facts

After reviewing the requirements, it became apparent I had the wrong objects at the centre! Rather than people at the centre, the objects at the centre should be transactional data. The centre objects needed to be the actual data that was summed, aggregated, filtered, sliced, and diced. Once I made this change, the value of the Visual Report Boards increased exponentially. Now they communicated the content and purpose of the data requirements.

The real indication that I was on the right track is that the Revenue and Expenses Hexes I now had were also the first two Fact tables that were needed in the Data Warehouse! This method of visualization and analysis was aligned 100% with the Data Warehouse design process. Of course the Hexes were Fact table. This made perfect sense. I imagine more Hexes will be needed in the future as we discover the need for more Fact tables.

In addition, we created one more Master Data Hex as some reports and data requirements are not related to transactions.


I am convinced the use of these Visual Report  Boards and the related use of an Innovation Game enable the creation of a Data Warehouse in an Agile manner. We are executing in Iterations and not increments and the clients are thrilled with the control, visibility, and value they get every 2 weeks. I’ll post another blog once we have created enough of the Fact tables to provide more lessons learned.

How an #Agile Data Warehouse leveraged an Innovation Game #agile2012 #sdec2012

On my latest project I have been doing a lot of research and learning on how to conduct a Data Warehouse project in an Agile manner. Actually I’m really honoured to be able to combine my two passions in my career: Data Modeling and Agile.

This investigation has led me to what I feel is a unique approach to an Agile Data Warehouse project. Many of the Agile Data Warehouse projects I hear of and read about typically seem to follow a somewhat standard process. This process usually involves building a Data Warehouse in increments by working with departments within the corporation to understand their data requirements. (in many situations, this is a very detailed analysis of their data requirements) In this way, the Data Warehouse is built up over time until an Enterprise Data Warehouse is created. While this is a far cry better that trying to analyze the data requirements for the entire corporation, I do believe there are some limitations with this approach.


1) If the Data Modelers are not experts in the existing data domain, this process may involve significant rework as data modeled for one department may need to be modified as new information is learned and existing data structures need to be integrated with data structures designed in subsequent releases. This risk can be significantly reduced if the data modelers are experts in the data domain, but this can be a real risk for consultants that are not experts.

2) We are still not implementing a Data Warehouse in an iterative fashion, only incrementally. While this is a step in the right direction, it is still falling short of being able to implement a Data Warehouse iteratively and get even quicker feedback. Since we are also essentially time-boxing implementing data requirements on a department by department basis, we are also only working on the most important data requirements on a departmental basis. We are not working on the prioritized data requirements for the entire corporation. If every department receives the same time allocation, we may work on some data requirements while other more important ones are left in the backlog. And finally, the data requirement for each department can get quite detailed. In many ways, we are still doing Big Design Up Front – in chunks.

Our Approach

My background in Data Modeling has always been aligned with Bill Inmon’s thoughts rather than Ralph Kimball’s. So to no surprise I felt I needed a good understanding of the data domain for the Enterprise before I could start to model the data. To address this I proposed we create and Agile Enterprise Data Model. An Agile Enterprise Data Model is an Enterprise Data Model that takes 6 weeks instead of 6 months to create. (or 6 years) Its purpose is to validate the entities, relationships, and primary attributes. It is not intended to drive down into every single attribute and ensure alignment. In my experience, this excessive detail has derailed other Enterprise Data Model projects. (as consensus cannot be reached or the data is always evolving) But in creating an Agile Enterprise Data Model, we now understand enough of the enterprise’s data so that even though we may only be modeling one department’s data, we know what integrations and relationships are required in the future.

I felt this addressed the first limitation.

The second limitation was much harder. I felt it was much harder to engage clients in small slices or iterations of their data requirements in a light-weight fashion that wouldn’t require reviewing their current data requirements in detail. How could we get a picture of the data requirements for the corporation at a high level? Many of the clients were concerned that if the project operated in iterations they would not get all of their requirements satisfied. In addition, our current project had a list of existing reports that the clients would like to be migrated to the new environment. How could we engage our clients and work with them to determine what their corporation’s data requirements were in an iterative light-weight manner? How could we provide visibility of what the entire corporation  data requirement were?

I turned to Innovation Games.

I am a fan of Innovation Games and any light weight process that can help to visualize data and engage the clients better. I was searching for a way to use a variant of the ‘Prune the Product Tree’ game to use. But I didn’t feel that just placing data requirements on the Product Tree would truly help the engagement of the client and provide the visibility required. What we really needed was a variant of the Product Tree that helped the clients ‘see’ their data requirements to confirm that we got it right and that showed the requirements for the entire corporation on one wall.

We ended up merging a ‘Prune the Product Tree’ game with a ‘Spider Web’ game with some unique additions.

Here is what are doing:

1) We are seeding the visualizations with 30-40 enterprise level reports that are used internally and externally.

2) We have asked for the top 20 reports from each department to further seed the visualizations. This will help to populate the visualization and I believe help the clients to generate other data requirements that we are missing.

3) We are capturing data requirements or reports in the simplest mode possible. We decided to leverage the Goal, Question, Metric method proposed by Victor Basili. Our data requirement stories will specify the following:

  • Noun : The object of primary interest
  • Question : The main inquiry about the noun
  • Reason : What is the business reason for the question
  • Frequency : How often do I need the answer?

An example is provided below:

Noun Question Reason Frequency
Claims Amount > $1,000 To generate audits Monthly

We will capture these additional data requirement stories in Silent Brainstorming sessions with users. This Silent Brainstorming will occur after we present the visualizations and review the data requirements that have seeded the visualization.

The final piece of the puzzle

Even with those first three pieces, it was still unclear how we could visualize the data and reporting requirements and gain engagement with the clients. Then during an Innovation Games course that was educating us on how to customize and create our own game, it struck me. The Product Tree is the wrong metaphor for our data requirements. We need something that visualizes the data requirements themselves. We iterated through a spider web metaphor, to a 3 dimensional axis metaphor, until we ended up on a hexagon. I’d recommend you find the shape that best fits your data domain. The hex and its six dimensions fit our data domain nicely.

The hex diagram below is our customized Innovation Game we will use to seed data requirements and generate new requirements.

The Concept

Usually for all data requirements or reports there is a person object at the centre. This is no exception. We will have a data hex for each type of person that the corporation needs to know about. The six accesses were chosen by understanding the data domain and by reviewing existing reports that are used by the client. The existing data requirements and reports will be translated into the data requirement stories and placed on the hex. Sessions will be facilitated to add additional stories onto the data hexes.

Once all of the stories have been placed on the data hexes we will prioritize the stories by moving the data requirement stories based on priority. Data Requirement stories that are high priority will be moved near the centre. Stories of less priority will be moved to the outer rings.

The Rationale

Using this metaphor we are able to do the following:

1) Visualize the hundreds of data requirements and reports of the corporation at once and prioritize them.

2) Ensure we are working on the true data requirements across the entire corporation.

3) Work in a true iterative fashion in how we deliver data requirements and ultimately build the Data Warehouse iteratively.

4) Use a light weight method that limits detailed design up front


If you want to hear how this process worked, the results will be presented at Agile 2012 in Dallas and at SDEC2012 in Winnipeg! I’ll also have a subsequent blog post that publishes the results. So far the feedback has been encouraging and we will be expanding the use of the process over the next few weeks.

How do I encourage #innovation on my projects?

I actually think about this topic quite a bit. There is mention of innovation in almost every job ad and project charter I see. But really what is innovation? How do we innovate? How do we encourage innovation?

I think we frequently believe that innovations are large changes rather than small incremental improvements. When we think about how to innovate we get stuck on trying to find that next big idea. Or else we try to find the software tool or process no one has heard of so we can present a significant change from the current status. So we try to come up with the new idea and then revert back to the current status when the next big thing can’t be found.

Then we hear from management and others that we need to be innovative. Like we aren’t trying. 😦

I have found that two concepts help out greatly in helping to make projects more innovative.

1) Encourage the small innovations

If you encourage the small innovations in people, process, and technology, I have found that the large innovations will follow. If you analyze what is perceived as large innovations, you will actually find that they were made up of a lot of small innovations along the way. How do we encourage the small innovations? Recently I’ve reviewed incremental improvement statements with my teams to get them thinking about small improvements. The small improvement statements I reviewed on my last project were:

  1. I will strive to be a better team member tomorrow than I am today
  2. I will strive to be a better [BA/PM/DBA/Developer] tomorrow than I am today
  3. I will strive to help to make the solution better tomorrow than it was today
  4. I will strive to help to make problems, issues, and risks less tomorrow than they were today
  5. I will strive to help to provide more value to the client tomorrow than they had today
  6. I will strive to help to create better processes tomorrow than we have today

These statements have helped the team focus on continuous improvement and innovation.

2) Build a team culture of safety and confidence

If you can build a culture where people feel safe in making suggestions or recommendations and where people are confident their ideas will be heard and truly considered, I firmly believe you will get more ideas and ultimately more innovation. I think frequently people limit the innovations they bring forward because they feel they might be blamed if the innovation has unintended consequences. (or they may be criticized for an incomplete idea) In addition, people want to be sure that the idea will be seriously considered if they are going to put the time in to develop the idea or innovation.

To accomplish this, I try to do two distinct things:

I) Abide by the Agile Prime Directive

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

–Norm Kerth, Project Retrospectives: A Handbook for Team Reviews

I absolutely love the Agile Prime Directive as it removes blame and us versus them thinking from the project. It sets the stage for people to feel comfortable in raising ideas and suggestions without the fear of initial criticism and blame somewhere down the road. It also places the onus on the individuals to hear their team mate’s ideas without being critical off the bat. It places the emphasis on “seek to understand” rather than “seek to find fault”.

II) Let the team innovate

This sounds like obvious common sense not worth mentioning. Let me explain. Many teams that have a perceived lack of innovation share the same structure. There are a few leaders that ‘approve’ the innovations that will be implemented and they expect their team members to submit their innovations for approval. This very structure stifles the innovative process. How can the few leaders at the top have the same wealth of ideas and domain knowledge as all the members of the team to evaluate what is a good innovation? Anytime there is an approval process, you can be sure there is not going to be much innovation.

“As a leader, you don’t need to be convinced or believe in every innovation, you just need to believe in your team.”

Many times, you may believe that the innovation may not work. But you again need to trust your team. Otherwise, the team will get a sense of what ideas you are likely to approve and only raise those ideas to your attention. And before you know it you are only getting one person’s idea of innovation from a team of many. And then in the Project Retrospective we will bemoan the lack of innovation.

The team doesn’t submit ideas or innovations for approval, they just inform as to what innovations or ideas they are currently implementing.

But won’t you have constant change? Yes and No. Yes, you will have a lot of change and change that you could not have foreseen. But isn’t that the point of innovation? But if you set expectation and the entire team has a shared vision of success and the ultimate solution, the team itself will determine when it can innovate and when it should not.

The team understands that the project still needs to live up to the client expectations, but how the team meets the expectations should be up to the team to decide. We need to manage by destination rather than by route. The team will determine the best route to take.


I have combined the small improvement statements and Agile Prime Directive into something I have termed the Team Member Manifesto on my recent team. So far the amount of ideas and innovations have been very high.

Top 11 #Agile Books and top 3 Information Technology books

I just finished presenting at SDEC and I realized that I did not have a Blog post on my Agile reading list. Many people asked about how to get started on Agile and a list of books that influenced me. In a future post, I will list the practices that I tried first and my success with them. (Somewhat of my personal Agile roadmap)

Without further ado here are my top 11 Agile books that have influenced me and helped me to learn about Agile.

And yes, they are in order! Not in the order they have to be read, but in how much I found them valuable.

1) User Stories Applied – Mike Cohn

2) Agile Estimating and Planning – Mike Cohn

3) Innovation Games – Luke Hohmann

4) Lean Software Development – Tom and Mary Poppendieck

5) Agile Database Techniques – Scott Ambler

6) Art of Lean Software Development – Curt Hibbs

7) Lean-Agile Software Development – Allan Shalloway

8) Test Driven Development – Kent Beck

9) Lean Architecture – James O. Coplien

10) Agile Testing – Lisa Crispin

11) The Art of Agile Development – James Shore

And the top three Information Technology books that EVERYONE should read in the industry regardless of their role or methodology:

1) Code Complete – McConnell

2) Beautiful Code – Oram & Wilson

3) Godel, Escher, Bach – Hofstadter

The Godel, Escher, Bach addition might surprise some people, but it was a book that profoundly influenced me and the way I think about problems, models, and solutions. Highly recommended.

#Innovation Games – Rapid Discovery Event

We had our second Innovation Game meeting earlier today and it was very interesting. This meeting was more of a standard application of Innovation Games unlike my previous two posts. It was a meeting that we at Protegra call a Rapid Discovery Event. A Rapid Discovery Event is a Discovery meeting with Innovation Games combined with a User Story Mapping session to quickly gain an understanding of the true business problems and potential solutions.

All the people that attended had never done Silent Brainstorming before.

Here was the agenda for the session:

Two Things – This is a very quick Silent Brainstorming warm up activity where we ask the participants for two things about the proposed solution. One thing that the solution MUST do, and one thing the solution MUST NOT do. This was a good warm up session and quite well received.

Who/What/Why – Silent Brainstorming exercise to start to get everyone to think about Who is going to use the solution, What are they going to do, and Why are they going to do it. Very good exercise and the group started to build up momentum and throw out a lot of ideas. We had an excellent diversity of styles and opinions in this group. Very nice to have and it is making this session very productive. We also had a good diversity in the two facilitators. My co-worker has more of a Business Performance Consulting focus while I have a technical background. I think this is an excellent match and allows for us to ask more of the right questions.

Personas – We take a break from the Silent Brainstorming and have an interactive session on the Personas or people that will use the solution. While we did not capture all the attributes about Personas that would normally be done in a standard Persona session, it was still a very valuable session. This session generated the most discussion and new ideas of any session. The amount of information we captured on the separate Personas and how they would use the solution was incredible. We easily captured at least 4-5 new Personas and ultimately functions of the solution that we were totally unaware before we started. Easily the best session. I think varying Silent Brainstorming with Interactive Sessions also helps to generate more feedback. Need to remember this.

User Story Mapping – The last Silent Brainstorming exercise was a User Story Mapping exercise. This exercise generated some excellent new ideas on what the solution needs to do. I think this session really benefited from having the three sessions held previously. With the results and discussions from those three sessions in hand, people were able to come up with the User Stories very easily. If anything, we had to end some discussions prematurely due to running out of time. It was fantastic to be in a 3 hour meeting where people are passionate and energized to continue talking. I’ve seen User Story Mapping sessions take 20 minutes. Everyone had their stories up in 5 minutes.


I’m an Innovation Games convert. It was a great session and we captured much more information than I had hoped. We have a larger group schedule next week and I am very excited about the information we will gather from that session to combine with this one. If you haven’t checked out Innovation Games online, I recommend that you go there and try out some games as soon as possible. You won’t be disappointed! Don’t be afraid to customize then to your specific circumstance….

#Strategy #Innovation Games – Recap

In my last post I described some customized Innovation games I was going to try in a Strategy Meeting. So I guess the obvious questions is how the games worked?


The games were met with a good level of skepticism and optimism. The group was about 20 people very familiar with different types of Silent Brainstorming. So they were not new to the method or process. They was a lot of feedback and ideas generated and at the end of the day we generated the initial problem statements that the session was intended to generate.

Overall, I’d give the session a B+.

Whole Product Game – The game was a great, repeat great, ice-breaker. It really worked well as an introduction exercise to get everyone thinking about what the company is and what the clients expect from the company. I would definitely use it again. Solid B.

Company Report Card Game -Probably the best game. People really liked the metaphor about being able to grade areas in addition to stating what was working well and what could be improved upon. There was some discussion on whether we needed guidelines for the letter grades. At the end, I think I am comfortable that we don’t need guidelines because it isn’t the absolute grades that matter. Rather, it is the relative grades of each area that are important. By looking at these relative grades, it becomes quite apparent what areas people think are the highest priority. I also created a plus/minus score for each area. (Good old Canadian hockey influence) The plus/minus just tracked the votes on positive items minus the votes on items needing improvement. Another data point that indicates where people believe there is a problem. The relative grades and the plus/minus scores were very consistent. Solid A.

20/20 Game – We adapted quickly and did not do this game as we were running out of time. I’d still like to try this game and maybe the next time we can see about the feedback we can gather using this game. No Grade.

So overall, I feel it was a very good session and I looking forward to more chances to play games at work.

#Strategy #Innovation Games

I don’t know when I have been more excited to be facilitating two sessions in one week. The reason is that both sessions are using types of Innovation Games. Now both sessions are using some unique customizations of Innovation Games and I am very interested in seeing the results. The meetings are drastically different. One is a Strategy meeting and the other is a Rapid Discovery Meeting.

Strategy Meeting

In the Strategy meeting, we are using three different and customized Innovation Games. We were going to take a somewhat traditional approach to this Strategy session until we sat down and thought about the process we should use to present current state. The question was then asked about whether we should present on current state, or let the group tell us what the current state is from their perspective. We loved the idea. Instead of he traditional approach of presenting the opinion of what current state is, why not get the team to create the current state through Silent Brainstorming. We were assuming that everyone would agree as to what the current state is.

So the three games I am proposing to get us to review current state and start to think about Strategy are:

Whole Product Game – To get us to start thinking about current state, we are going to use a slightly altered version of the Whole Product Game. It will be changed to solicit input on the entire company rather than a product. I believe this game will provide some interesting insight as to what people view as the company’s differentiators.

Company Report Card Game – I based this game based upon the ‘Grade a Feature’ Exercise. I believe the grading metaphor is something that we all can relate to and can allow for excellent insights. Instead of grading features, I have customized the game so that we will be grading the company according to the following categories:

  • Locating Opportunities (Sales)
  • Satisfying Opportunities (Offerings and Products)
  • Delivery Opportunities (Delivery and Manufacturing)

For each category a person will do the following on a stickie:

  • Provide one overall grade per category on how they think the company is doing in that category – denoted by circling it
  • Provide an item or items which they feel the company is doing well in that category – denoted by a plus sign in a circle
  • Provide an item or items which the company needs to improve to be able move up to the next higher grade – denoted by a minus sign in a circle

20/20 Game – I based this game on the 20/20 game contained in Luke Hohmann’s excellent Innovation Games book. There is also an excellent website available with online games. (although the 20/20 game is not one of the online games) This game will be based upon the results of the Company Report Card Game and each person will be asked to asked if the company is better or worse for each of the items that came out of the Company Report Card Game as compared to two years ago. This will be done by using stickers for voting. Each person will get 5 green stickers for voting for the items the company has improved and 5 red stickers for voting for items the company has  regressed on.

I’m very excited to gather the groups ideas and also for the ability to capture trends.

I’ll save the Rapid Discovery Innovation games I will be using for my next post…