Archive for the ‘Voice of the Customer’ Category

• New Offering – Innovation Games®

  Date: 2010.09.02 | Category: Agile, Collaboration, Design Excellence, Games, Innovation Games, Product Owner, Scrum, Tools, Voice of the Customer | Response: 1

  On May 6^th and 7^th, I attended an Innovations Games^® consultant’s class hosted by Luke Hohmann.  Innovations Games^® are collaborative games designed to help business people develop and prioritize new product ideas.  In the context of Scrum, these games are tools the Product Owner and product designers can use to engage the customers and different business stakeholders in defining the requirements for a product and thinking about product roadmap and multigenerational release plan.  Not a lot is written about the “fuzzy front-end” for Scrum teams and Innovations Games^® fill that significant gap in way that is consistent with the Scrum values and principles.

  It was quite instructive to hear about the games and how they work from Luke.  From the different case studies discussed, we really illuminated the dynamics involved with selecting the right game for problem.  In addition, a few of my misunderstandings about the purpose of the games and how they are played from reading the book were cleared up as well.  What I liked most about the class was in addition to talking about the games, we played a lot of them in the course of two days.

  1. Remember the Future (played)
  2. Prune the Product Tree (played)
  3. Speed Boat (played)
  4. Product Box (played)
  5. Buy a Feature (played)
  6. 20-20 Vision (played)
  7. Show and Tell (played)
  8. The Apprentice
  9. Start Your Day
  10. Spider Web
  11. Me and My Shadow
  12. Give Them a Hot Tub

  Below are pictures of the Product Box I created for Look Forward Consulting announcing the new service available.  I look forward to using these games more and helping Scrum teams with improving prioritization and collaboration with their customers.

  

  

• QFD & Agile Process Roll Out

  Date: 2009.01.06 | Category: Agile, Agile SD, Collaboration, Design for Six Sigma, Presentations, Scorecards, Transitions, Voice of the Customer | Response: 0

  I have been wanting to blog on my last presentation at XPSD for a while, but have been so busy with the Holiday Season – so here are my thoughts on how to use the Design for Six Sigma (DfSS) quality function deployment (QFD) tool to gather the Voice of the Customer data around creating a customized Agile process for your organization based on the issues your organization faces and deriving meaningful measures which will allow your group to monitor and track the roll out.

  Step 1 - The first thing you need to do is collect the Voice of the Customer (VOC) about what you want your new process to do.  So, to look forward, we need to look back for a little bit.  Gather all the people who will be participating in the process change and ask them some variation on these two questions:

  1. What is your biggest pain point with the current process?
  2. What is the number one thing you would change about the current process?

  To gather the VOC data, I used the Wall of Wonder - allow people to work in small groups quietly for a few minutes, capture each comment on a Post-it note and hang them up on the Wall.

  Step 2 -The next step is to group the VOC data into logical categories using an affinity diagram.  I find the best way to do this is ask the participants to get out of their seats and rearrange the items on the Wall of Wonder until everyone is satisfied with the groupings.  In DfSS parlance, each of these categories is called a user need.  A user need is simply trait the new development process must satisfy in order to be considered successful.

  After we have labeled all the groupings, I ask the participants to force rank the user needs with the most important traits of the new process receiving the highest ranking.  In my example, addressing issues surrounding requirements and adequate resources were the highest priority for the new process.  You can also rank the user needs from 1 to 5 and allow some user needs to have equal wights.

  Step 3 - Once we have ranked user needs, we enter them into the rows of the QFD chart (Room 1 in DfSS language).  Either as a big group or smaller work teams, I then ask the participants to think about what sorts of requirements the new process must have in order to meet our user needs.  This is the point where someone (usually an engineer) gives a solution to the problem and I need to remind the participants that requirements are solution agnostic.  The requirements are then listed as columns along the top of the QFD chart (Room 2).  Requirements are allowed to fulfill more than one user need, but more on that in Step 4.

  Step 4 - OK, we have our user needs which define the characteristics that our new process must provide our organization and we have requirements that fulfill those user needs.  How do we make sense of the requirements and find out which requirements are critical to the success of our new development process?  Or put in the language of DfSS, what requirements are critical-to-quality (CTQ)?

  To find the CTQ, we first need to complete the interrelation matrix between the user needs and the requirements (Room 3).  For each requirement we need to identify the degree they are related to each user need using the scale of 9 (strongly related), 3 (moderately related), 1 (weakly related) or 0 (not related).  It is best not to spend too much time discussing each of the relationships since they are a lot of boxes to fill in, so a tool like Planning Poker helps move things along.

  Step 5 - Next we rank the requirements by multiplying the interrelatedness score of each requirement with the user need ranking in each row and sum each requirement-user need product into a total at the foot of the column.  This example shows how we arrived at the total of 162 for the “on-time delivery” requirement:

    Total = [3 x 8] + [9 x 7] + [3 x 6] + [9 x 5] + [0 x 4] + [3 x 3] + [0 x 2] + [1 x 3]
          = 24 + 63 + 18 + 45 + 0 + 9 + 0 + 3
          = 162

  Repeat for each column to rank the requirements from high to low.  The requirements with the highest score are the CTQ and are the MOSTimportant requirements our process must fulfill in order for the roll out to be a success.  Or put another way, these requirements provide us the most leverage on making a successful product for our customers.  If we cannot meet these requirements, it does not matter what process we use – we have a very low probability of making a product that will satisfy our customers.

  Step 6 - The final step is to derive our measures that allow us to monitor our CTQ with a scorecard.  In order for measures to be meaningful, they need to tie to something that the organization or customer (this even better) cares about.  It is time well spent to create the measures as a group and reach consensus that the measures are indeed meaningful and what the organization chooses to evaluate itself against, otherwise people will game the scorecards and there will be no accountability.  I find it useful to have about 50% of the measures tied to the customer so they process is grounded in the market.  Too much process transformation is done for the sake of the organization and the improving the customer or the bottom line is often an afterthought.

  So where’s the beef?  Really – the word Agile has not even been mentioned up until this point.  Actually, that is the point.  A lot of Agile transitions start out backwards – we want to do Scrum\XP\whatever, so let’s find our problem.  QFD says let us examine and analyze our problem, find out what is most important for US and monitor those items with a scorecard to know if we are on track or not.  This approach is superior because once we have the QFD and the scorecard, we can then begin to think about what Agile process and\or practices that allow us to meet our CTQ and enhance our measures.

  Maybe for your organization, you have a CTQ around requirements, then perhaps you can try our user stories and see if they move your metrics?  Perhaps you have another CTQ around quality, then maybe having cross-functional team moves that metric?  The beauty of the QFD is it allows you to mix-and-match to meet your objectives, not what it says in some book.  At least now you have thoughtful information to help you tailor your Agile approach and an objective way to know if the change you are making are having the intended affect.

• Pay Attention to the Obvious

  Date: 2008.07.25 | Category: Design for Six Sigma, Practices, Voice of the Customer | Response: 0

  The other day we were talking about DfSS and how much training material we were going to produce and what sort of timelines we could commit to. I was having a hard time wrapping my head around the scope of the problem because it seemed very large and undefined. Specifically, I was thinking I had a LOT of original training I needed to create around some Agile code practices. Somewhere along the way I had missed aan important concept about my role on the DfSS rollout team. For some reason, I was under the impression that DfSS was about making better engineers.

  “Noooo. DfSS (DESIGN for Six Sigma) is about taking good engineers (people with good skills and proven engineering aptitude) and training them to become good designers.”

  While had been consistently told that DfSS is the program is about “designing quality into the system”, what I heard was “building quality into the system”. During the implementation (ostensibly the work that happens after DfSS), quality engineering practices are monitored and controlled via the scorecard. It is through the scorecard that good engineering practices like continuous integration, automated unit tests,refactoring, etc., etc. are implied to the Team. During implementation, you have to do “something” which will satisfy the scorecard, that “something” is up to you.

  Call me a bit skeptical about using the scorecard as a control mechanism for good engineering practices. I feel comfortable that the design coming from DfSS will be excellent, reflect the Voice of the Customer and be marketable, but leaving implementation as a black box to be monitored via a scorecard at phase gates ,or through periodic in-process reviews, leaves me less than satisfied. It seems to me that DfSS relies heavily on the ability of the DfSS Black Belt to bring both an excellent design AND quality engineering practices to the implementation team. In many of the environments I have encountered, there is big gap between the skills of the designers and the implementation team. It might be a bridge too far, I don’t know.