Progressive Development : HPT

Motley says: "Affinity exercises? How do I work that sideways "8" into brainstorming?"

James Waletzky — Tue, 11 Mar 2008 18:30:00 GMT

Summary

Motley: Affinity exercises? How do I work that sideways "8" into design brainstorming?

Maven: Use affinity exercises for generating lots of ideas and prioritizing them. Define the topic, generate ideas, categorize, discuss, prioritize using dot voting, add up the votes, and create the summary.

______________________________

[Context: After the talk on team checklists, Motley was motivated to create a team code review checklist, but had some difficulty]

Motley: After our recent discussion on checklists, I was inspired to create a team checklist for use in code reviews. A few common problems appear fairly regularly, and I want to ensure everyone looks for them during a code review.

Maven: Sweet! Glad to see you are implementing some quality practices. Checklists provide a great reminder of frequent errors, as we discussed.

Motley: I thought I would get everyone together to determine what issues to look for in code as a team. We ended up focusing on one or two things and had in-depth discussions. By the end of the hour-long meeting, we didn't have much that was useful. I then had a chat with Mort and we came up with too many ideas - the opposite problem. We didn't know how to narrow them down. In the end we had nothing. Pretty much a waste of my time and the team's time.

Maven: Ah, yes - the unstructured brainstorm session. Brainstorming with a team is actually a very difficult exercise if you don't set some ground rules and put some structure in place. Have you ever tried an affinity exercise?

Motley: Affinity exercises? How do I work that sideways "8" into brainstorming?

Maven: Affinity. Not "Infinity".

Motley: Oh.

Maven: An affinity exercise is a brainstorming technique for many types of problems. By following a very simple structure, you can generate a lot of ideas in a short amount of time and come out of the meeting with a list of the most important ideas to the team.

Motley: As long as I keep all my limbs and I don't end up taking anyone else's, I'm game to hear more. Doesn't "affinity" have something to do with attraction? Is this exercise appropriate for a work environment???

Maven: Sometime I'd like to get a look into the depths of your conscious as I am sure there are some scary things in there.

Motley: Get on with it.

Maven: Ok. The affinity comes from the fact that you are going to generate a lot of ideas and examine the relationship between those ideas. First you need to stock up on Post-It notes, find a room for the team, invite a few people, and schedule an hour for the exercise.

Motley: What are the Post-It notes for?

Maven: You will soon see.

Motley: Hmmm… I think I'll have to bring back a few pads that I, um, borrowed for home use because our supply cabinet is running low. How does the exercise work?

Maven: The first part of the exercise is to define the topic to be brainstormed. Provide an overview to the team on the problem for which ideas will be generated.

Motley: Ok - we are generating a checklist for reviewing production-quality code. Next?

Maven: Great. Individuals generate as many ideas as possible. An easy way to do this is by presenting each person in the room with a stack of Post-It notes to be used for writing down one idea per note. Give the team about 15 minutes of silent time to write down as many ideas as possible. Write down an idea, rip off the Post-It note and put it beside you, then repeat. There are no wrong answers, we don't worry about duplicates between individuals, and there is no discussion at this point. Anything goes.

Motley: One idea per Post-It note. Everyone is quiet, heads-down and writing for about 15 minutes, or presumably until they run out of ideas.

Maven: Exactly. Once all of the ideas have been exhausted or the time limit exceeded, everyone posts their ideas on a flat surface (wall, whiteboard, paper, etc.). If two people come up with the same idea, they overlap the Post-It notes. The overlap provides a real-time filtering of duplicates. I recommend using a Whiteboard for this if possible so that you can draw on the surface.

Motley: What if the ideas are similar but not identical?

Maven: The next step after everyone has their Post-It notes on the wall is to find the relationships between ideas and categorize the ideas together. Create logical groups based on the types of ideas that were generated. For example, if you are creating a code review checklist, there may be several items related to security like checking for correct buffer usage. Group those items together, draw a box around them, and label the category/theme. The category helps provide context around the ideas, and may even be a checklist item in itself if the ideas within the category are too specific or really represent one central idea.

Next, you want to discuss the ideas to ensure everyone understands the complete set of notes. Because the Post-It notes typically do not contain much text, some explanation is required from the authors. The explanation may also lead to a few more ideas, so as people in the group have them, they can post a few more on the board.

Motley: What about the dumb ideas - presumably we don't want to waste time discussing those?

Maven: Encourage people to be as creative as possible and think outside the proverbial box. There are no "dumb" ideas. If, in your head, you feel an idea is not feasible, keep it to yourself. It will come out later in the exercise.

Motley: We have the ideas generated and displayed, and we have an understanding of what they are. This still doesn't solve one of our big problems - too many ideas posted and either no idea how to prioritize them or some disagreements on how to do so. This technique looks great for generating the ideas, but prioritization is still an issue.

Maven: I'm not done yet! Of course, the members of the team may have differing views on which are the highest priority ideas. We discussed previously that checklists should be kept to around a page in length to be useful. Chances are good that after an exercise like this you have multiple pages worth of ideas. The group must narrow them down.

Motley: I'm waiting…

Maven: Here is a good technique: make sure everyone has a pen or marker. Each person gets seven votes to use how he or she pleases. The votes can be distributed across the ideas in any way. For example, perhaps Marcy really wants to see two of the items on the team checklist - she can put 4 votes on one idea and 3 votes on another. If Mark sees 7 ideas that he feels should be on the checklist, he can put 1 vote on each of 7 ideas. Voting is typically done by placing one dot per vote directly on the Post-It notes. Not surprisingly, we call this "dot voting."

Motley: Simple but effective. After everyone has had all their votes, we tally up the total number of votes for each of the items and take, say, the top 10 for the checklist.

Maven: You got it. Those top 10 will be the ideas the team is most concerned about for code reviews. Notice, too, that the ideas that are not feasible get left out, but no one feels bad because someone insulted their idea. The exercise allows us to wade through a large number of ideas, prioritize them appropriately, and produce a result that the team is happy with.

Motley: Awesome - we're done!

Maven: Not quite. Someone then needs to take action and write down the checklist in whatever form your team uses (e.g. wiki, InfoPath form, etc.), ensuring it is made available to everyone in a place they have access to. The exercise was useless unless we capture the results and the checklists is used by the team.

Motley: That goes without saying. I could see us using this technique for lots of different kinds of brainstorming activities, from where to go for dinner to what weekly practical joke to play on you.

Maven: Please, no more practical jokes. I'm still trying to get that tree sap off my jeans.

______________________________

Maven's Pointer: There is no magic to using 7 votes for dot voting. Using an odd number helps people prioritize more than using an even number that they can split evenly. For larger groups of people, you may want fewer dots, like 5 or 3. For smaller groups of people, stick with 7 or 9 or larger as there will be fewer dots to go around due to less people in the exercise. The risk with fewer people, however, is that one person can manipulate the results a little more by putting the majority of their dots on one item.

Maven's Double Pointer Indirection: When the exercise is complete, take a digital photo of the whiteboard containing the Post-It notes in case you want to review the session later or see what other ideas were generated should some items start disappearing off the checklist as they are no longer frequent errors.

Maven's Triple Pointer Indirection: Remember the discussions on Human Performance Technology. You can use the Six Boxes to guide people's thinking a little bit more in various areas that may be relevant to your problem, particularly if the number of ideas being generated by the team is low.

Maven's Resources:

In-depth description of affinity diagrams: http://www.mindtools.com/pages/article/newTMC_86.htm

Motley says: "Reflection is for mirrors" (Scrum Part IV)

James Waletzky — Tue, 12 Feb 2008 19:50:00 GMT

Summary

Motley: Reflection is for mirrors. We just finished a sprint. Why open up old wounds?

Maven: At the end of a sprint, do a demo for stakeholders, customers, and the team. Do a retrospective to reflect on what went well and what requires improvement. Continually improve the team from one sprint to the next.

______________________________

[Context: In a continuing conversation about Scrum, Maven is about to enlighten Motley on the most effective ways to wrap up a sprint, or short iteration]

Motley: At the end of the sprint, we followed the Scrum process. Everyone did a quick one minute summary of the work they accomplished during the sprint. We then chatted for 5 minutes on how things went. That's it. Don't tell me there's more. This is a lightweight process, right?

Maven: I guess "lightweight" means different things to different people. There are some best practices for the demo and retrospective. It is a valuable exercise to take time to reflect on the past sprint.

Motley: Reflection is for mirrors. What's the point? We just finished the sprint - why open old wounds?

Maven: Hopefully ripping apart flesh is not a good analogy describing your last sprint. It is extremely important to reflect on your last iteration. Let's take the demo. You may wonder why we bother demoing the work we just did. We met on a day-to-day basis and everyone was aware of what each other was doing on a high level. Well, the demo serves a few purposes:

The demo allows stakeholders that may not be directly involved in the sprint to get a first-hand look at the progress the team made. Feel free to invite people not directly involved in sprint work.
The demo allows your customer(s) to provide feedback on the work you did, allowing the team to fold in changes in priority or requirements into the next sprint. Remember, customers love to see working software. Solicit them for feedback and changing priorities and update the product backlog. Incorporate that feedback into your next sprint planning session.
The demo is a chance for the team to celebrate their accomplishments over the past sprint. Seeing working software can really be a morale boost for the team.

Motley: One problem I have with all this is that I don't want the team spending a bunch of time creating demos for the end of sprint meeting when they could be doing real work. Seems like a waste of time.

Maven: Actually, that is a common misunderstanding. You are not out to create a really flashy demo to show off the product. You are simply doing a demonstration of the functionality you just built. There should be no extra gold plating just to look more impressive at the demo meeting. It's not about creating a glitzy demo.

Motley: But what if some members of the team did not work on software directly? They are going to feel left out at demo time.

Maven: Again, don't take the word "demo" too literally. A demo could be a review of a wiki page that was created, a tool somebody wrote, a document that is important to the product, a description of a consulting engagement, or anything else concrete that the team can see some created value from. The demo is typically a 1h meeting that occurs during the slack time between sprints. Make it fun. Bring donuts or burn CDs with interim builds for your stakeholders. Think of the demo as a team building exercise with a celebratory feel.

Motley: Ok, we obviously have room for improvement there. What about the retrospective? What's the point? We just finished the sprint, so we know what just happened.

Maven: The retrospective is a chance to do two primary activities:

Examine what went well in the sprint. It's important to analyze those processes and team procedures that lead to success and to continue to do them. Having a clear idea of what is working ensures everyone on the team knows the best practices and allows you to encourage them to continue doing them. It is also a bit of a morale boost knowing that what you are doing is working. You also want to avoid turning the discussion into a negative whine/gripe session. Remember the retrospective 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."

From <http://www.retrospectives.com/pages/retroPrimeDirective.html>

Examine what requires improvement. Perhaps the biggest reason for a retrospective is to focus on continuous improvement, which is one of the principles of agile development. In Japanese, this is called Kaizen ("Kai" = change, "Zen" = good), where you look a system and consider the results and process to get to the results with a non-judgmental focus and goal of improving how you generate results. We want to look at how we can be more effective in the next sprint. Think about what you would do differently next time. Use any metrics you gather for quantitative analysis and use those measures to drive improvements (e.g. Were the estimates off? Why? How can we improve?)

Motley: So we have a quick chat and then improve for next time. Easy.

Maven: Well, there is a bit more to it:

Clarify success. As a team, determine what success would have looked like for this sprint, and will look like for upcoming sprints. "Begin with the end in mind", as Dr. Stephen Covey says. If we apply Human Performance Technology (HPT) as we discussed previously, we can measure the gap between our current state and desired state, determine root causes, and implement interventions to help the team succeed.
Ask everyone to prepare. A bit of up-front reflection prior to the retrospective meeting helps ensure the conversation is valuable.
Give everyone a chance to speak. Chances are good that most people on the team are critical thinkers with a desire to improve. Ensure everyone gets a chance to contribute at least one thing positive about the sprint and one thing negative. Draw out the introverts - they have opinions too. Treat the exercise as a brainstorm - there are no wrong answers. As a last resort, make the comments anonymous.
Create tasks for improvement areas. Write down everything that is said in the meeting, particularly areas for improvement. Create concrete action items out of the improvement areas with assignments and due dates. Put tasks on the next sprint if needed. Make sure the discussion leads to positive change.

Motley: Jeez, Mave. You always put so much structure on everything. Can't we simplify?

Maven: Actually, this is quite simple. Most of this is just small tips to make you more effective. Just remember to focus on what went well, and what requires improvement.

Motley: One other thing that still isn't clear to me though. What the heck was the point of gathering all the data during the sprint? The data seems as useless as most other metrics. You didn't even mention it as part of the retrospective. We spend a lot of effort capturing them, and then no one ever looks at it again.

Maven: Actually, there is great reason to capture the data. And yes, we do use it in the retrospective and throughout the sprint. It's getting late though. Why don't you head home for the day and we can pick this up in the morning.

Motley: Ah, I get it. That's code for you having to head home and do whatever geeky thing you do in the evening. Have fun washing your pocket protector!

______________________________

Maven's Pointer: One of, if not the primary reason for short iterations in agile development is to ensure we get rapid feedback. We want to create a culture of continuous improvement of the product, the team, and ourselves. Although sometimes feedback may be difficult to accept, it is necessary for forward progress. Encourage feedback early and often on not just the product but all parts of your life. It is the best way to get better!

Maven's Resources:

http://www.restrospectives.com: A web site dedicated to the growing practice of looking back to move forward. The retrospective prime directive is found here.
Agile Retrospectives: Making Good Teams Great, by E. Derby, D. Larsen, K. Schwaeber, Pragmatic Bookshelf, ISBN: 0977616649, July 2006

Motley says: "Human Performance Technology? I guess I better brush up on my robotics." (HPT Part 3)

James Waletzky — Tue, 18 Dec 2007 21:08:00 GMT

Summary

Motley: Training is the best solution to most problems. If a developer doesn't know how to do something, teach that person. Problem solved.

Maven: Training is only one solution, and may not be the best one. Consider Human Performance Technology and address the problem with a results focus from both an environmental/team perspective and an individual perspective.

______________________________

[Context: Maven is about to enlighten Motley on 3 dimensions of leveraging Human Performance Technology focusing on individuals]

Maven: Last time we were talking about Human Performance Technology (HPT) and how to use the technique for root cause analysis and problem solving. If you recall, there were six dimensions that we talked about when analyzing a current situation:

Expectations and Feedback
Tools and Processes
Incentives
Knowledge and Skills
Capacity
Motivation

Previously we talked about the first three on the list, which identified areas to investigate in terms of the overall environment. Much of the time, those three are to blame for larger problems in an organization. However, to do a thorough analysis we have to consider individual factors as well.

Motley: You mean like when there are some obvious bugs in the system it is usually one of your individual code check-ins that's to blame?

Maven: Not quite like that. Let me explain. The first one we'll talk about is #4 on the list - knowledge and skills.

Motley: Isn't that the solution to most of our problems? If we knew how to solve them we would just solve them! Knowledge and skills acquired through training fixes everything!

Maven: Knowledge and skill in a particular area is important. For example, if you want to improve performance in an application, you may consider a multi-threaded design. If you have never written a multi-threaded application before, you may need some training in how to do it. However, if the schedule doesn't give you time or there are no tools to facilitate the job, no matter how much you know, the feasibility of that approach is limited. Lack of skill or knowledge is often a contributor to a problem, but not necessarily the root cause nor is training the key solution.

Motley: I guess that makes some sense. If my boss has the expectation that we cannot take time from the schedule for training, I cannot fill the skills gap via training - we have to reset the expectation first. Pretty smart, Mave.

Maven: Why thank you, Mot! Individual development plans for employees should be part of the equation, and that should include training. Training isn't usually THE answer, but it can help. The next dimension to look at is capacity.

Motley: Why are we talking about electronics concepts here??

Maven: That's capacitance!

Motley: Um, yeah. I knew that.

Maven: Capacity is all about having the right people in the right roles to get the job done effectively. If you want to tackle a concurrent multi-threaded design but your team is a group of students who don't even know what a thread is, well, perhaps the problem is better left to another team. Even beefing up the skills and knowledge side may (and perhaps will) still lead you to disaster.

Motley: So lack of capacity means fire the whole team and replace them.

Maven: Not exactly. In reality, capacity is generally not an issue, but it is an important dimension to look at when determining root cause and deriving solutions. You want to have the right people on your team and they need to be doing the right tasks for their skill set. The last area to discuss in the model above is motivation.

Motley: I'm motivated as long as the incentives are there!

Maven: That's an interesting statement. Motivation and incentives are often related and may be dealt with together. Motivation is all about creating a positive work environment and ensuring people feel appreciated for the work they do. As a senior developer, Mot, you must take extra strides to motivate people. Do your team members feel valued? If not, why not? Is there anything you can do to improve morale if it is low?

Motley: Alright. Let me take a crack at summarizing.

Maven: Awesome! Using active listening is a great practice to have - you validate what you just heard, make sure you heard correctly, it helps with memory retention, and it validates for the speaker what was said.

Motley: Thanks, Einstein. I know all that. That is why I'm summarizing! Anyway, using this Human Performance Technology (HPT) stuff is supposedly great for finding root causes to problems and identifying solutions you may not otherwise have thought of. You examine your business needs around the current situation, specify the details of that current state, identify the "to be" state that is your ideal future, determine the gap between the current state and future state trying to find root causes, and then apply these six dimensions - expectations and feedback, tools and processes, incentives (these from the environmental and team perspective), and skills and knowledge, capacity and motivation (these from the individual perspective) - to determine suitable solutions in some areas that may not have been obvious. That's it, right?

Maven: Very good! There is one last step though. As many of the other processes we have talked about, this one is iterative as well. Early on and also while deriving solutions, you want to come up with a way to determine in the future if your interventions (solutions) were successful. You do that by deriving some measurements that allow you to evaluate your solutions.

Motley: Won't it be intuitively obvious whether something worked or not? What's the point of all the extra effort?

Maven: You don't want to leave any question as to whether the solutions that addressed the problem caused an improvement. Remember: HPT is results-based. You want to have a concrete measurement as to whether your results are what you want. "Measurements" don't have to be purely quantitative, but you need something concrete to aim towards. For example, if we are addressing build breaks, we need to know the current state (e.g. 4 breaks per week) and the future state (e.g. zero build breaks per week). Just by examining the future state we have a measurement in this case. It's not always that obvious, and there may be interim measures, but you want something to track.

Motley: And I guess if quality is a problem, there are all sorts of metrics around that, such as defects found by the test team, defects found by the customer, defects after check-in, etc.

Maven: You got it.

Motley: Great. I am intrigued by this HPT thing. It really brings to light that training a team member in some area may not be the best way to address a problem. You have to look at the problem from other angles.

Maven: Yep. Feel like buying me lunch for all this great information?

Motley: I believe you already know the answer to that question. If I apply HPT here, the root cause to the stupidity of that question is probably your lack of skills and knowledge - and ultimately your capacity - in reading people.

______________________________

Maven's Pointer: Human Performance Technology is in wide use at Microsoft in the Engineering Excellence Group (EEG). Microsoft's engineering central body used to be exclusively aimed at training, and was previously called Microsoft Training and Education. However, the current focus is much wider. EEG takes an HPT approach to solving engineering problems across the company. Training is still one part of it, as mentioned in the sixth dimension, but there are five other factors. Carl Binder built on the work of Thomas Gilbert and calls these dimensions the "Six Boxes". It is highly recommended that you explore this model when attempting positive organizational or team change.

Maven's Resources:

The Six Boxes: http://www.sixboxes.com
HPI Essentials, by George Piskurich, ASTD, ISBN: 1562863150, June 2002.

Motley says: "Human Performance Technology? Do I need a profiler for that?" (HPT Part 2)

James Waletzky — Tue, 04 Dec 2007 17:53:00 GMT

Summary

Motley: Human performance technology is about behavioral psychology? I have no background in that, so I can't use it!

Maven: Leverage a very simple model that encourages root cause analysis and problem solving along 6 primary dimensions - expectations and feedback, tools and processes, incentives, knowledge and skills, capacity, and motivation.

______________________________

[Context: A continuing conversation about Human Performance Technology and how to use it to identify and solve problems in the workplace]

Motley: Ok, get to the point. We talked about this weird "Human Performance Technology" to identify and solve problems, but you haven't gotten to the details of how to identify different types of problems and come up with non-obvious solutions! I'm not seeing the value!

Maven: Patience, my friend. Patience. We talked about identifying the business needs for a given situation, the "to be" state, and current state, and doing gap analysis. The next step of the process is to help figure out the root causes of those gaps. One way to do that is break the problem down into six dimensions that come from behavioral psychology:

Expectations and Feedback
Tools and Processes
Incentives
Knowledge and Skills
Capacity
Motivation

These dimensions allow us to put a framework around our thinking. Notice that 1-3 have to do with the environment and 4-6 have to do with an individual. We need to look at problems systemically and consider all of these axes.

Motley: This sounds complicated! Behavioral psychology? I have no background there!

Maven: No problem. The core concepts are really quite easy to understand and anyone can do it. Let's start by tackling the first three categories on the list above. These three focus on environmental and team factors - things that affect the team overall and much less the individual. The first is expectations and feedback.

Motley: Well, since this is all about getting to root causes and finding solutions, I'm assuming there are some questions that we should be asking. What kind of questions apply to a category like expectations and feedback? I'm expected to write great software and if I don't someone is going to tell me about it.

Maven: You're right on the questions! With expectations you want to make sure that everyone is on the same page with respect to what is required to get the job done. This is important to getting the right results. In your example, what does "great software" really mean? Different people may have different definitions. You really want to get to the bottom of whether people know what the expectations are. And when people are not meeting expectations, they should know about it and be given concrete actions on how to correct the behavior. Here are a few questions to ask:

How are performance expectations communicated to employees? Make sure they are not dictated and that employees are clear on expectations. Perhaps everyone writes a set of commitments in your organization?
Are employees given timely feedback regarding their performance? Waiting for the end of a software release to correct actions that occurred at the beginning is ineffective. Feedback needs to be early and often.
Do managers in the group support this direction? If the team is going in a direction that differs from the business, it may not matter if they do a great job. If a team wants to do unit testing to beef up quality, but management does not provide time in the schedule, it's a lost cause.

Motley: I bet this is probably the most important dimension. No matter what other solutions you put into place to solve problems, if management doesn't buy in and provide feedback on how you're doing, forget it.

Maven: Great observation! When you really get to root cause of many problems, you'll often find that expectations and feedback are at the source. The next dimension to talk about is tools and processes.

Motley: Something every developer is concerned with. Plus, I'm talking with the right person - a real-life living "tool"!

Maven: Another great colloquialism from Mr. Motley. Tools and processes are important ways to enable the right results. Tools that review code automatically or organizational processes that get in the way, such as build verification tests that are too comprehensive, are items to explore here. Here are some questions to ask:

What processes and tools are currently used? Is there a gap in our current inventory? Software teams, particularly large teams, always leverage tools and processes to get the job done. Determine if there is a gap in processes and what we can do to solve it.
Do these processes and tools meet team needs and/or solve the problems that the team is having? Why or why not? Find out if there are redundant processes in place or tools that do not fully solve a problem. Replacements may be in order. Learn from other teams what they are doing to solve the identified problem.

Motley: As a developer, I spend a lot of time with various software tools. As for process, you can have it. It just gets in the way!

Maven: It shouldn't. Process is necessary to make for repeatable high quality results, but if it is too formal or complicated that it gets in the way, well, that's a problem that needs addressing. The next dimension to discuss is around incentives, which is often grouped with consequences.

Motley: Ah, like our previous conversation on punishing people for build breaks!

Maven: Sort of. On the incentives side, if an organization does not have suitable incentives in place to reward people for a job well done, it can be difficult to (a) find good people to do a great job; and (b) convince the people you have to do a great job. Some questions to ask here are:

Do the employees know what success looks like? Related to expectations, but what does success look like with respect to incentives?
How are employees rewarded for successful performance? Successful organizations reward employees for performing well and producing solid business results. Teams that are not rewarded in some way tend to crumble.
Are there opportunities for career development? Solving technical problems and producing great results is less significant if employees are in dead end jobs with no opportunity for advancement.

This dimension is usually less of a problem, but is one worth considering when examining human performance.

Motley: This all still sounds pretty complicated. I'm sure there are lots of details to each of these dimensions as well that we haven't covered!

Maven: Yes, there are. However, what these six areas do is help ensure that you examine a problem and think about solutions from various different aspects of human performance. Often people jump to one solution - often training - as the cure to all their woes, but in fact, there are other things that may be further up the root cause chain. For now we've only talked about the first three around environmental factors. Let's shift gears and talk about root cause analysis and solution identification of individual problems...

______________________________

Maven's Pointer: Attend an International Society for Performance Improvement (ISPI) conference if you get the chance. Although the conference may not be specific to your organization's problems, it is useful to get yourself in an HPT mind frame for a few days and chat with people in other industries about how they apply HPT. You will hear about other HPT processes and get more information about what was presented above. The conference may provide you with a logical frame around solving tough business problems, particularly for larger groups of people.

Maven's Resources:

The Six Boxes: http://www.sixboxes.com
Human Competence: Engineering Worthy Performance, by Thomas F. Gilbert, Pfeiffer, ISBN: 0787996157, Reprinted March 2007.

Motley says: "Consulting? I guess your answer from here on out is 'It depends'" (HPT Part 1)

James Waletzky — Tue, 27 Nov 2007 19:08:00 GMT

Summary

Motley: How could a consulting methodology help me? There's no way - I work in a product company.

Maven: Human Performance Technology (HPT) is an effective consulting methodology that uses a simple process to identify the root cause of human performance issues and build creative solutions to those problems.

______________________________

[Context: Maven and Motley are having a discussion on what Maven used to do before joining the company]

Maven: Did I ever tell you that I was once in the consulting world?

Motley: It depends. Hahahaha. Isn't that the consultant's answer for everything?

Maven: Very funny, wise guy.

Motley: Yeah, I'm quite the comedian. I'm not surprised in your background though given that you are always trying to solve people's problems around here. I even heard you talking to Morton the other day about some problems his daughter is having. You get your hands into everything!

Maven: Sometimes I can't help myself. I love to see the world improve! Did you know there is a method to my madness? I use a technique called Human Performance Technology, or HPT. You don't have to be a consultant to use it - all you need is a systemic human performance problem to solve. It's more of a problem solving technique than a consulting technique.

Motley: "Human Performance Technology"??? You make it sound like we're all robots. So you use computers to pop out the answer when faced with a consulting problem?

Maven: Not exactly. "Technology" is used in a broader sense. Here is an overview of the technique:

Motley: Wow. That looks like a bunch of psychological gobbly-goop. I'm not sure I even want to hear all the background on that stuff. Looks complicated.

Maven: Actually, it's quite easy! Here's how-

Motley: Wait! I, errrr, have a plane to catch.

Maven: You have to work on your "stretching the truth" skills, bud. Anyway, this won't take long. What do you do when you have a problem to solve? Say, for example, someone comes to you indicating that builds keep breaking. What is your process for solving that problem?

Motley: Easy. Put continuous integration in place as we discussed.

Maven: You've been paying attention! Well, continuous integration may or may not be the right solution. The trick is not jumping to solutions, but examining the problem. The first step is to assess the business need.

Motley: Well of course the business needs no build breaks.

Maven: Yes, but it is important to understand why. What is the impact to the business' bottom line? Should we solve this problem over something else? What makes this problem more important than others? You want to ensure you are putting effort into the right problem.

Motley: Well, for build breaks, it's pretty obvious. The daily build is our lifeline. Without a build everyone on the product team is blocked and we potentially delay shipping the product, which affects the business. It's also a quality issue.

Maven: Cool. Next you want to think about what your ideal future state looks like. This is called your "to be" state, or where we want to be when we are executing near perfectly. What is that ideal future state?

Motley: Hmmm… for builds, we want a build without compiler and link errors every day. I would also think we want the Build Verification Tests (BVTs) to consistently pass. In addition, I want statistics gathered on every build around code churn, I want instantaneous communication in the rare event there is a problem with the build, I don't want a full-time build person looking after it, and most importantly, I want a latte automatically made for me every time the build passes.

Maven: Well, I'll try and forget the last one, but the rest are great! Before we can get there, however, we need to understand the current state. What is the state of the build today?

Motley: Periodic build breaks that still happen too frequently. Developers that are still too sloppy. We've been trying to address the issue with continuous integration (CI) but the CI server is being overloaded by the problems that developers are checking in. It's far less than ideal. Plus, I am not getting my lattes.

Maven: Now that we have an understanding of where we are and where we want to go, it's important to understand the gap that is getting in the way of us getting there. Not only do we want to understand the symptoms but the real problems that are causing the gap.

Motley: Right. Back to the root cause analysis discussion we had. The "Five Why's" for example.

Maven: You bet! In addition to asking "why", we can leverage the six dimensions shown in the diagram above to help us get to the root cause of our issues, and also help us come up with creative solutions to our problems.

Motley: I thought you said this won't take long!!!

Maven: Bear with me here. Doesn't this model sound great? Don't you want to know more?

Motley: I just felt another gray hair pop out, and it's your fault. Fine - finish off your model...

______________________________

Maven's Pointer: There is a central organization that focuses on HPT called the International Society for Performance Improvement. HPT analysis leverages various other disciplines including behavioral psychology, instructional systems design, organizational development, and human resources management. The central idea is to improve human performance by focusing on measurable results while looking at the big picture (a systems view). HPT is a systematic approach at identifying and solving performance problems in the workplace and beyond.

Maven's Resources:

International Society for Performance Improvement: http://www.ispi.org
What is HPT? http://www.ispi.org/hpt_institute/#What