Wednesday, December 26, 2012

Tips for Facilitating a User Story Mapping Session

In an earlier post I described how to create a user story map. Here are a few additional tips that you might find helpful.

Tip #1. Silent Brainstorming isn't mandatory. 
While using silent brainstorming is great for creating a map, you don't always need to use it. Sometimes you may find yourself in a situation where a full set of requirements has been written or the app is a re-write of an existing and well known application. In those cases I often skip the silent brainstorming and create the map from the existing documentation. Of course, I still do this with the team.

Tip #2. For your first map, reference the email map.
When you are creating your first map you may find that some people have difficulty finding the right level of detail for the second row in the map ("things people do" - the user tasks). In order to reduce the confusion walk them through the first two rows of the email map first. You can simply write the basic map on a few post-its as an example:

Finally, as they are writing their 'things people do', walk around and take a look at what they are writing. Encourage them when they are writing the correct level of detail ("Compose Email") and ask questions when they are getting into too much detail ("Set an email to High Priority").

Tip #3. Tear horizontally, not vertically
There are two ways to tear a post-it note off of the pad. If you tear it off horizontally (left to right or right to left) the post-it note will lie flat when it is stuck onto the wall. If you tear it off vertically (bottom to top) then it will have a curl.

Tip #4. Big Post-its
Quite often it isn't possible to create your map in the team room. If this is true for you then create your map on the large 3M Easel pads so that it can be transferred back to the team room.

Tip #5. Use name brand post-its
Post-its made by 3M seem to stick longer than other brands.

Saturday, December 15, 2012

A Systems Thinking Alternative to Performance Reviews

I tried something new based on the concerns and research around annual performance reviews. I'm not qualified enough to make categorical claims about the typical annual performance review process, but I can say that by trying something different I enjoyed the performance review process more than any other year and I had some great conversations with my co-workers. Here is a quick report of some of the concerns, what I tried, and what I learned.

The concerns:
W. Edwards Deming is often quoted when expressing concerns over annual performance reviews. Deming's 85-15 rule implies that 85% of any employee's performance is based on the system they are working in rather than their own individual actions. If this is true, then any significant performance increases or decreases are not under the employee's control but rather those who control the system (i.e. management). This means that if employees are under-performing we should look to the system first and not the individual.

As a parent, coach and change agent, I have noticed one consistent trend with respect to individual improvements. If I try to push improvements on people then they will tend to resist the change. However, if I try to pull improvements from them (ask them what they want to learn/improve) I encounter much less resistance and more actual improvements. How might this influence the annual performance review process?

The experiment:

Note: At Protegra we have a flat structure so we don't receive feedback from managers but rather from the people we've worked with over the last year. As a company we've tried various approaches and are still experimenting to uncover better ways. The experiment I tried this year was based on the concerns above and also conversations with co-workers. In the end I came up with five questions to augment my involvement in our yearly process. After receiving permission from each person, I sat down with them and had a conversation that centered around the following questions:

a) What are you proud of? (Pull)
b) What do you want to learn or improve this year? (Pull)
c) What part of our team's system is preventing you from doing your job better? What should we improve or change? (Systems Thinking)
d) How is the company enabling or inhibiting you from achieving your best? (Systems Thinking)
e) What do you need from me? How can I help? (Pull)

The results:

I had fantastic conversations with several of my fellow employees on what they love about their job, what they are proud of, and the things they are doing to try and make their work environment better. I discovered some common interests and swapped ideas for personal improvement and growth. I learned more about what makes each person 'tick' and how I can support that. In the conversations I had with each person I left feeling inspired, listened to, and encouraged. I think we all felt a greater sense of ownership over our improvement plans for the year.

Just as importantly, I learned more about the value of Deming's 85-15 rule and its impact on performance. We had discussions about our system and the things we could (and did) change. In more than one case it became clear how powerful a simple systems change could be. Our conversations were slanted towards being a performance review of the system instead of a performance review of the individual.

This experiment was a lot of fun and I plan on doing it again. In fact, I have added an item to my backlog to extend this conversation to other people on the team throughout the year.

Some final thoughts:
After reading this some of you may be asking questions like "how does this help us address those individuals that actually have 'performance' problems?", or "how does this help us set salary?". I'm not sure it does in the way you might like. For the former, please don't wait until the annual review to deal with the issue (short feedback loops please!) and make sure to look at the system first. For the latter I'll leave that to other experts to discuss (see the TLCLabs blog below for one example). However, I'd guess that taking this approach nudges a group of people towards having a better system, being a more effective team, and becoming a more effective organization.

System Thinking References
- Demings 85/15 rule
- If Ackoff had given a Ted Talk
- It's not a behavioural problem its the system

Performance Review References
- Why performance reviews don't improve performance
- Why we don't do forced ranking and performance reviews - TLCLabs
- The Elephant in the Room: Appraisals and Compensation - Mary Poppendieck
- Get Rid of the Performance Review! (and some info on Performance Previews)

Subscribe to Winnipeg Agilist by Email

Tuesday, November 27, 2012

Blog Challenge!

Hello readers,

This is a quick post to let you know that a few friends of mine have started a blog challenge. The challenge (led by Dylan Smith) is to blog bi-weekly over the next six months with a winner take all purse. Be sure to check out their blogs as well:

Dylan Smith:
Tyler Doerkson:
David Alpert:
Dave White:
Aaron Kowall: 

(P.S. No - this post doesn't count in the challenge)

Celebrate Failure? [Part 2]

Earlier this year I wrote about Agile's perspective on failure. In that blog I indicated that my brother-in-law (a psychologist) sent me some of the latest research on failure. In particular, there were two fascinating studies that helped me understand why failure is indeed a cause for celebration. In the first part of this series I summarized the results of a study looking at the effects of failure and success in the orbital launch industry. In this blog post I'll look at some interesting research that examines the role of attitude when failure occurs.

Your attitude towards failure (and your organization's attitude) does matter.

A group of researchers led by Joel Albert Kahn set out to discover what the effect of failure norms - or attitudes towards failure would have on closing gaps in performance. Is failure enough incentive for an organization to find ways to improve or does their attitude towards that failure matter?

In an exploratory study they surveyed teams within an automotive manufacturer to look for teams that had both strong and weak "failure acceptance norms". A team with weak failure acceptance norms would be characterized by defensive attitudes when failure occurs. A team with strong failure acceptance norms would be characterized by team members that have an acceptance of failure as normal.

Using survey data they identified the teams with the strongest and weakest failure acceptance norms and then observed those teams over a two year period. What they found is that attitude mattered - the teams with the strongest failure acceptance norms were the teams that closed performance gaps the most effectively.

To those familiar with Carol Dweck's book "Mindset: The new Psychology of Success" or who have seen Linda Rising talk about her research, this should come as no surprise. According to this research, people generally find that they have one of two attitudes.

The first group of people believe that each person is either smart, or not smart - they have a fixed mindset. In this group failure is a strong indicator that you are not smart - they become defensive when failure occurs and gravitate towards easier tasks that allow them to be successful. This group has weak failure acceptance norms.

The second group of people believe that if you work hard you can improve and overcome problems - they have an agile mindset. In this group failure isn't an indicator of intelligence but rather a challenge to try again and work a little harder. This group has strong failure acceptance norms.

Interesting - Carol's research on individuals matches that of Kahn's research on organizations and teams.

One further note about Carol's research. She found that it was relatively simple to move people from the first group to the second. Our words can be powerful. When failure occurs, celebrate it as a learning opportunity!

To end this series I have a suggestion: The next time your team fails, promote an agile mindset and buy them a cake to celebrate:

Further Reading:
- Linda's presentation on this topic
- Linda's keynote from Much Ado About Agile
- Carol's website:
- A short video of Carol describing the effects of praise on children

Subscribe to Winnipeg Agilist by Email

You can get the full research from your neighbourhood PhD student but here are a few more details on the studies mentioned above:

"Failure construction in organizations: Exploring the effects of failure norms - Kahn, Joel Albert, 1995, University of Michigan. School of Business Administration. 

Two exploratory studies were used in this research to develop an understanding of the effects of failure norms at an automotive manufacturer. Using the survey data, the two teams with the strongest and the three teams with the weakest failure acceptance norms were identified. These five teams were observed for two years and cause maps were collected from 31 members of the teams."

"Early models of organizations as rational systems assumed that a gap between what is expected of a performance and the performance as it actually occurs will stimulate a search for an alternative approach to a problem. An interpretive perspective, in which performance gaps are socially constructed, suggests that such a search is not the inevitable consequence of performance gaps. Instead, people interpret performance gaps defensively by retrospective rationalization and external attribution to avoid acknowledging failure. People will search for alternatives only when performance gaps are interpreted as failures and not when they are interpreted defensively. Whether or not people interpret performance gaps defensively is determined by norms that are communicated and enforced within an organization an that are considered binding within its teams. Thus, the central idea of this dissertation is that search is not an inevitable response to performance gaps as is often presumed. Instead, search is a response to failure only if people are encouraged to accept failure by strong acceptance norms. …it is the acceptance of failure (strong failure acceptance norms) that encourages the interpretation of performance gaps as failure."

Monday, November 5, 2012

Celebrate Failure? [Part 1]

Earlier this year I wrote about Agile's perspective on failure. In that blog I indicated that my brother-in-law (a psychologist) sent me some of the latest research on failure. In particular, there were two fascinating studies that helped me understand why failure is indeed a cause for celebration. This is the first in a two part series.

"We find that organizations learn more effectively from failures than successes" 

In a 2010 study (more details at the bottom of this post) on the effects of failure and success on organizational learning, a team of researchers found that failure was a crucial ingredient for longer term success.

In order to find suitable organizational data to support their research they searched for and found an ideal candidate - the Orbital Launch industry. This industry was ideal for the following factors:
  • Every launch had a high incentive to succeed due to the high cost of failure.
  • Placing objects in space is a relatively new activity so data is available for all launches ever attempted.
  • Because it is a high profile industry the records were relatively easy to find.
  • The sample data contained 4663 launch attempts, 443 failures, 36 organizations, and 9 countries. The data starts with the launch of Sputnik 1 on October 4, 1957 and ends March 2004.
(Note: The Orbital Launch industry is responsible for sending rockets into space to place a payload into orbit around the earth.)

As researchers their goal was to look at the causes of improved organizational performance. Did success drive improvements? What part did failure play in future success? Here are a few of their key findings:
  1. Organizations learn more effectively from failures than from successes. Success causes organizations to be complacent in the belief that they have figured it all out. On the other hand, failure increases the desire to learn and challenge existing beliefs. Those organizations that fail end up being more successful in the end.
  2. Success breeds complacency and overconfidence and reduces the incentive to learn. Organizations who regularly succeed may in fact suffer from this experience in the long term. 
  3. Organizations learn more from large failures than from smaller ones. As part of a community that believes in failing (learning) fast, this one is the hardest for me. But at the least it supports the notion of celebrating failure when it occurs in the larger or the small.
  4. Organizations should embrace failure so that they can learn from it. One response to failure is to punish those involved or hide the failure. Organizations that are open about their failures have an increased chance of learning and then improving because of it.
As many people like Luke have pointed out - failure isn't the goal. However, when it happens we can either run from it or celebrate it. The evidence from the Orbital Launch industry strongly suggests that celebrating failure is in order. For even more reason to celebrate, take a look at part 2.

Subscribe to Winnipeg Agilist by Email

You can get the full research from your neighbourhood grad student or PhD but here are a few more details on the studies mentioned above:

Failing to Learn? The Effects of Failure and Success on Organizational Learning in the Global Orbital Launch Vehicle Industry

Abstract: "It is unclear whether the common finding of improved organizational performance with increasing organizational experience is driven by learning from success, learning from failure, or some combination of the two. We disaggregate these types of experience and address their relative (and interactive) effects on organizational performance in the orbital launch vehicle industry. We find that organizations learn more effectively from failures than successes, that knowledge from failure depreciates more slowly than knowledge from success, and that prior stocks of experience and the magnitude of failure influence how effectively organizations can learn from various forms of experience"

Discussion and Conclusion: "These findings do not imply that organizations that fail in period t are more likely to succeed in period t + 1 than are organizations that succeed in period t. But they do imply that organizations that fail in period t improve their own likelihood of succeeding in period t + 1 (relative to their likelihood of success in period t) more than do organizations that succeed in period t. Our definition of learning is inherently self-focused - change in organizational performance as a result of prior experience. ... Consequently, the result presented here suggest that experience with failure allows organizations to improve their performance relative to their own previous baseline, but that experience with success does not generate similar levels of improvement. 

Indeed, this study not only yielded strong evidence that organizations learn by observing their own and others' failures, but also failed to uncover evidence of significant learning from observation of their own or others' successes. In the full models, coefficients estimating the effect of success experience on future performance are indistinguishable from zero. We don not interpret these results as evidence that organizations cannot learn from success to improve performance. But the fact that launch vehicle organizations (which face significant incentives to learn from success as well as failure) did not experience demonstrable learning from success suggests that organizational learning from success is far from an automatic process."

Implications for Practice: "Failure is often difficult for organization members to cope with. Because failures - and those that appear to be involved in them - are often stigmatized, organization members frequently refuse to acknowledge failure, refrain from communicating about it, or redefine it as success (March et al., 1991). Indeed, in Vaughan's (1996, 2005) analyses of the Challenger and Columbia disasters, she noted that the most significant organizational antecedent to both tragedies was the institutionalized practice of ignoring failures. 

Nonetheless, given failure's central role in organizational learning shown here, organizations that stigmatize failure may be depriving themselves of major opportunities for improvement. Consequently, the most significant implication of this study of practice is that organization leaders should neither ignore failures nor stigmatize those involved with them; rather, leaders should treat failures as invaluable learning opportunities, encouraging the open sharing of information about them. Indeed, this suggestion dovetails with existing evidence that members of organization that treat failure nonpunitively report more errors, but experience fewer serious failures, than member of organizations that seek to assign blame for failures (Edmondson, 1999; Weick, Sutcliffe, & Obstfeld, 1999)."

Thursday, August 2, 2012

Build Quality In: Applicable in Football too

One of the lean software principles is "Build Quality In". In short, we try to build it right the first time in order to reduce or eliminate re-work and defects. I turns out that this same rule is applicable when training a running back not to fumble.

Here is a story in Yahoo about the Patriot's running back Green-Elllis who at the time of the article had an incredible streak - no fumbles in four seasons. His college coach said:

"Far too often, he has seen players fumble and then heard the coach afterward demand that his players protect the ball by not carrying it carelessly into traffic. This always struck him as backward. Why talk about ball security after a fumble? Why not before? What are the preventative measures? You’ve got to put running backs in a position where they can eliminate fumbles." 

To put this statement in the context of software development:

"Far too often, he has seen the number of failed tests rise and then heard the project manager and testers afterward demand that the software developers write better quality code. This always struck him as backward. Why talk about tests after development? Why not before? What are the preventative measures? You've got to put software developers in a position where they can eliminate defects."

Test first my friends, test first.

Monday, July 30, 2012

An Example of a Self Organizing Team

After a recent presentation where I talked briefly about self organizing teams, someone came up to me afterward and said (I'm paraphrasing) "That team stuff is great and all, but some people are just lazy and need to be told exactly what to do and when." Argh.

But before you judge that person, let me tell you a story. In this true story you'll have the opportunity to judge me for having the same thoughts before trying a different approach. This is the story of my self organizing daughter.

My kids go to a great school - the kind of school that fosters engaged teachers who go the extra mile to create engaged students. Throughout the school year the teachers run numerous clubs before school, at lunch, or after school including run club, football club, circus club (complete with unicycles!), reading club, wrestling club, girls club, gymnastics club, etc. My kids love attending these clubs and my oldest (aged 10 during this story) was determined to be in every one of those clubs.

This is great, except there were a few problems. Many of the clubs started before the school day so she had to be ready and out the door pretty early. Since most of the clubs had a strict attendance policy (if you miss two days, you are out of the club), being on time was important. Further, because of our cold winter weather, she received a ride on many of the mornings with one of her friends. If she was late getting out the door, her friend also risked being late and missing out on the clubs.

So, being the responsible parents that we are, we nagged her out the door each the morning. "Time to get out of bed", "Have you brushed your teeth yet?" "Go comb your hair",  "It's time to make your lunch now!" "Hurray up, you're going to be late!" It made for some pretty frustrating mornings for all of us. We treated her exactly as the statement above: "some people are just lazy and need to be told exactly what to do and when." She would do the task we asked her to do and then wait to be told what to do next. Looking at it now, she was disengaged and dis-empowered. I cringe at the memory.

While this was happening, I was reading the 7 Habits of Highly Effective People by the late Dr. Stephen R. Covey. I had my "Oh crap" moment when he said this:

"You cannot hold people responsible for results if you supervise their methods. You then become responsible for results and rules replace human judgement, creativity, responsibility...  Effective leaders set up the conditions of empowerment and then... get out of people’s way, clear their path and become a source of help as requested.“

After talking it over with my wife, we approached our daughter and apologized. We then discussed a new plan with her. Since she clearly was capable of getting out the door on time on her own, she would take over that responsibility. We would make ourselves available to be a source of help if requested but otherwise stay out of it. She jumped at the chance to take ownership of her morning routine. On the first day of this new arrangement she was ready fifteen minutes early and there hasn't been a day since then that she wasn't ready on time. Not so lazy after all I guess - just the victim of well intentioned managers.

After getting over my embarrassment, I pondered how this is a great parallel to self organized teams:

1. Status is known daily. We had daily status of her progress - if she was late she would miss her ride or be kicked out of a club. Our agile teams have daily standups, visual boards, frequent deliveries and demos so that everyone understands that status of the project at all times.

2. Agreed upon goals. She understood the goal (get out the door on time so that she can keep going to clubs) and desired to reach it. Self organized teams need to understand the goals of the project, not just the tasks to complete the project.

3. Freedom over methods. She started out being assigned tasks and moved to taking ownership of her own methods. Self organizing teams are given freedom to achieve the project goals and pull their own tasks rather than being assigned tasks.

4. Ask for help. She wasn't abandoned if she ran into trouble (oh no! I can't find the shirt that matches these pants!) - we stepped into help when asked. An effective scrum master, agile project manager, IT director, etc helps the team in a similar manner.

5. Empowerment brings results. This change turned a painful morning routine into a simple one because she was given the trust and responsibility to achieve the goal. When a team is given the trust and empowerment to accomplish the goal using their own methods, great things occur.

(Note :You can ready a similar story about Dr. Covey and his son entitled "Green and Clean")

Wednesday, March 14, 2012

How to create a User Story Map

User story mapping is becoming a popular technique through the efforts of Jeff Patton and others that allows you to add a second dimension to your backlog. Here are a few reasons you should consider using this technique:
  • It allows you to see the big picture in your backlog.
  • It gives you a better tool for making decisions about grooming and prioritizing your backlog.
  • It promotes silent brainstorming and a collaborative approach to generating your user stories.
  • It encourages an iterative development approach where your early deliveries validate your architecture and solution.
  • It is a great visual alternative to traditional project plans.
  • It is a useful model for discussing and managing scope.
  • Allows you to visualize dimensional planning and real options for your project/product.

Want to hear more? I talked about the value and use of User Story Mapping with Richard and Carl on show #750 of DotNetRocks.

To create your own user story map:

1. Form a group of 3-5 people who understand the purpose of the product. 3-5 seems to be the magic number. Any less and you might miss some ideas. If you add more people, it slows the process down and there are diminishing returns on the quality of ideas generated.

2. Start by gathering the major user tasks of the project/application in silence - the “things people do”. Each person takes the same coloured post-it and silently writes down one user task per post-it. Once everyone has finished writing their post-its, have each person read their post-its aloud and place them on the table in front of the group. If anyone has duplicates they should be removed at this point.
  • Depending on the size of your application it can take 3-10 minutes to get all the major tasks, but you can watch the body language to see when they are done. You will see that the group goes from huddled in at the beginning to standing/leaning back at the end.
  • Likely each post-it starts with a verb. (eg. Compose E-mail, Create Contact, Add User, etc)
  • These are the high level user stories called “User Tasks” which forms the "walking skeleton" of the map.
  • When they are done, point out to your team that in a few minutes they gathered most of the high level scope and that if they missed a user task or two, someone else probably didn’t. This might be their first ‘aha’ moment for silent brainstorming.

3. Next ask the team to group the post-its in silence. Simply ask them to move things that are similar to each other closer to each other and things that are dissimilar to each other should be moved farther apart.
  • Use silent grouping simply because it is faster than grouping them out loud.
  • If duplicates are found, remove them.
  • Groups will form naturally and fairly easily.
  • Once again, body language will help you see when they are done - usually 2-5 minutes.

4. Using another colour of post-it, name each group and put the post-it on top of the group. This step can be done out loud.

5. Arrange the groups left to right in the order a user would typically complete the tasks.
  • If the group can't decide on an order between two or more tasks, it probably doesn't matter.
  • The groups are called “User Activities” which form the backbone of the map.
  • You should now have the first 2 rows of the user story map - something similar to this:
A1       A2    A3          (user activities = backbone)
T1 T2 T3 T4 T5 T6 T7 T8 T9 (user tasks = skeleton & timeline)

6. Now walk the skeleton to make sure you haven't missed any major user tasks or activities. You can walk through user scenarios, or even bring in users and ask them to walk through their job functions to make sure everything is accounted for.

7. With a finished framework for the map, you can add more detailed user stories below each user task before breaking your map into releases. I like to use the same silent brainstorming technique to generate the initial set of stories for each user task and augment it with other techniques such as user scenarios and personas. Once you have a good set of stories, then you can put your release lines in the map and ask your users to prioritize top to bottom.
  • I like to put the first release line on the map pretty high on the map so that it only allows for 2-3 user stories per user task in the first release. This has been an effective way to encourage prioritization and scoping.
  • Because all the stories end up on small post-its, you can forgo the traditional 'as a' format and just put the story title on the post-its. This will allow you to read the map a little easier.

8. Finally, I like to take all the user stories in the first release and do some serious user story slicing to make sure we have sliced the first release as thin as possible. As a guideline, you should strive to be able to create the whole app (at least one small user story slice for each user task) in the first iteration or two.

"An example would be handy right about now" (Brian Marick)

(click to enlarge)
Here is an example user story map for creating the next email client competitor:
  • The second row contains the "things people do" in an email client such as Compose Email, Send Email, and Create Appointment. 
  • The first row contains the groupings for those things people do. 
  • The first yellow row is the smallest user story slice for each user task. For Compose Email, that means a basic form with To, Subject, and Body text fields plus Send and Cancel buttons. Functionality for RTF support, HTML support, adding attachments, getting email addresses from your contact list etc, are not included in this user story but are included as user stories lower in the map. 
  • The small blue and orange post-its on the larger yellow post-its indicate the status of that user story. The blue ones say "done" and the orange ones say "wip" so that you can see your project status flow down the map.

If we now build the first row left to right before working on any stories in the rest of the map we can deliver all of the basic functionality quickly. This enables us to validate our messaging architecture (i.e. Send an email and then make sure you can Read it). It also allows us to test all the basic functionality in the application end to end so that we can make sure it all works together while getting feedback on whether or not it will solve the business problem. If we were building the very first e-mail client, we could release to the public at this time. Notice also that we did not have a user story for "Delete Contact" in the first release - we don't need to deliver functionality for each "User Task" in each release.

Finally, some definitions:

(click to enlarge)
  • The post-its you create in Step 2 are the User Tasks (blue post-its in the diagram). 
  • The groups and group names in steps 3 and 4 are the User Activities (orange post-its). Jeff calls these top two rows the backbone and walking skeleton of your application. 
  • The user stories (yellow post-its) are organized under each User Task in order of highest to lowest priority for that User Task. 
  • The chronological order of how users will typically use the application goes left to right (Time).

Subscribe to Winnipeg Agilist by Email

Wednesday, February 22, 2012

Agile Chartering - an Agile Documentation Alternative

Last spring I wrote two posts about agile documentation (Part 1: Introduction and Part 2: Guiding Questions) and asked you to consider this statement: 
"A document isn’t the only vehicle for expressing or transferring good thinking and ideas."
Recently I coached a team that was converting an application from VB6 to VB.Net. One of the challenges of the project was to agree upon and define the rules for when to fix the old code, when to just get it working, when to re-write whole sections, etc. One method to gain agreement on this approach could be to schedule a series of meetings and write up the conversion rules and strategies in the project charter document. Here is what we did instead:

Using a variation of the silent brainstorming technique we spent about 20 minutes creating a light weight conversion manifesto we could all agree upon. As you can see, we had some fun when we named the groups. The manifesto was 'documented' using an easel pad, post-its and sharpies. We placed it on the wall in the team room and referenced it often throughout the project. Situations we could not have documented up front surfaced during the project and were discussed quickly while referencing the post-its. This light weight manifesto served as a great vehicle for expressing our good thinking and ideas.

A meeting and a word document could have accomplished this as well, but not in the same amount of time, with the same effectiveness, or with the same mirth. In addition this is a great team building experience for teams that already have enough experience with long meetings and longer documents.

For more ideas on how to streamline your project chartering, take a look at this new book by Diana Larsen and Ainsley Nies: Liftoff: Launching Agile Teams and Projects

FYI - here is a quick explanation of the manifesto:

Image Via
"Hold your nose, just get it working!": Yes, the existing legacy code isn't beautiful, but it works and the users are happy with the functionality. We focused on delivering the functionality as is without any modifications unless absolutely necessary. (see “If you have to pass gas, fess up”). This included ignoring existing known issues and defects.

"If you have to pass gas, fess up": In the rare occasion that code or design must be changed, you must discuss and gain agreement with the team before doing so. Any issues or resolutions that come up must be shared with the team.

“Don’t paint the outhouse”: We are going to be making changes to the application after we deploy the .Net version so there is no need for a fresh coat of paint at this time. No UI "clean-up" is allowed except for minor formatting issues and we won't do any re-factoring unless absolutely necessary.

“You can’t get out of the mob unless you get out of the city”: We used VB Migration partner to do the initial conversion to VB.Net. The tool was a big help to speed up the project but some of the converted code is a little ugly and the team wanted to dive in and fix it all right away. If we were to focus on fixing the ugly code now it would not deliver value to the user – just less ugly code. So we put our focus first on converting the code and getting it live (i.e. getting out of the city) so that we could leave the mob behind in later projects as we replaced parts of the system.

Subscribe to Winnipeg Agilist by Email

Wednesday, February 15, 2012

Agile's perspective on failure

In the fall of 2011 I did some research regarding agile and failure for a presentation at Much Ado About Agile 2011 in Vancouver. The research was focused by a blog post by Philippe Kruchten describing some of the agile elephants. He listed "commercial interests censoring failure" and "using Elitism as a defense (against failure)" as two of the elephants. I consulted my brother-in-law Dr. Jason Ediger who is a psychologist to learn a bit more about the psychology of failure. After a brief explanation of what agile is, he responded with this:

"The assumption of failure is built into the agile process. The traditional method is built on the presupposition that we can plan failure out of the process. We don't have to test for it because we've taken everything into account. Agile assumes that humans are going to fail. By it's very nature, agile can't ignore (or censure) failure. If the accusation is that agile suppresses failures, then by definition - that is not agile. If agile is done properly then it can't* fail because it tests for failure all along. If you suppress failure, you guarantee it. Agile has a different perspective on failure. It doesn't see failures as catastrophic, but as expected. That difference in perspective allows us to celebrate failure rather than suppress it."

Pretty interesting comment don't you think?

Agile tests for failure all along in order to succeed. We aren't hoping for, or even planning on failure, but we do test for it regularly by delivering frequently, having daily stand-ups, keeping project status visible, etc. We do all this so that we can discover and react to our failures quickly in order to succeed.

Subscribe to Winnipeg Agilist by Email

Friday, February 10, 2012

Agile is simple but not easy: advice for agile beginners

As we prepared for yesterday's user story mapping session at Agile Winnipeg, Jon Labun and I reflected on agile stories that we've been a part of or heard about. A common theme emerged - agile is simple but not easy. We touched on this in the presentation and argued that user story mapping should be a central part of your agile practices in order to make many things 'easier'. Many agile stories start off well with organizations and teams wanting to give agile a try, but then fail to put in the investment to understand what being agile is about. The teams assume that agile is simple but lack the knowledge of how all the pieces fit together and end up running a project that is just an agile facade - agile words on the surface, but traditional methods (or no methods) underneath. It isn't the fault of agile that the projects end up in trouble or fail. 

Some common problems:
  • Unending backlogs that are hard to visualize and prioritize
  • Definitions of done that don't include testing & deployment
  • 20 page requirements documents for one user story
  • Incorrectly assuming that agile means 'no planning'
  • Planning at the task level vs. the story level
  • Testing after development is done rather than throughout the project.
  • Out of control scope
  • Out of control change management
  • Never ending projects
  • Significant quality issues
  • etc
If you are beginning your agile journey then welcome to the club! It can be a lot of fun and very rewarding. But please, please, don't start without gaining some knowledge first. The agile community has a good head start on you and can help you through some initial hurdles to make your 'simple' journey a little easier. Please do read some articles and books, listen to podcasts etc, but your best learning will come from interactions and conversations with others who are further along the journey. Here are two important pieces of advice for you:

1) Find your local user group and support it with your attendance. Bring real questions and ask the group to help you find some answers. If you are in Winnipeg, visit If you are elsewhere, consult the Agile Alliance's list of local user groups.

2) Attend conferences. Many of the successful agile teams I know point to ideas and practices they learned at conferences as crucial steps in their organization's agile journey. But don't expect to only 'attend' sessions - plan to interact with the audience and speakers during the sessions and also over lunch, dinner, drinks, or even indoor sky diving. There are several great conferences you can attend, but I'll highlight one in my region - PrairieDeveloper Conference in Calgary, Alberta from March 12-15. Regardless of your location, this is a can't miss conference with 80 sessions + full day workshops. See you there?

To paraphrase Mike Cohn, the agile community has helped me up my game - now up yours.

* P.S. Prairie Developer Conference is more than just agile of course, bring your whole team, your IT pros, your managers, etc.

Sunday, January 29, 2012

Multitasking game - Hands/Numbers/Song

Most of us find ourselves multitasking at some point and are possibly even proud of our multitasking skills. Here is one game that was created by Alan Cyment with collaboration from Tobias Mayer and introduced to me by Gerry Kirk and Yves Hanoulle at SDEC11 that allows you to simulate the costs of task switching. I've since used it elsewhere and the results were quite effective for shaking the multi-tasking misconceptions.

(Note: Alan added a comment to this blog and I've incorporated some of his new ideas and changes - thanks Alan!)

The Game

Materials needed

  • 6-20 people (note - if you have more than this, just split into multiple groups. In theory you can handle as many people as you have space for)
  • One facilitator
  • One stop watch
  • White board / Easel or equivalent to record a few scores.

Suggested questions to ask before the game

  • Who values multitasking?
  • How many projects are you working on right now?
  • Can we juggle tasks well?
  • Who is great at multitasking?

Practice / Warm-up

  1. Have each person pair up and then line up in two lines facing each other like this:
  2. A1 A2 A3 A4 A5 (A1 faces B1, A2 faces B2, etc)
    B1 B2 B3 B4 B5
    • If you have an uneven number, you can ask one person to be your time keeper. If you have some sceptics or others who don’t want to participate, you can ask them to be observers ;). However, you need at least 3 pairs and more is better.
  3. Have each pair practice the Hands activity as below
  4. Now switch pairs by having everyone in line A move one spot. A5 will have to move all the way to A1. Your line should now look like this:
  5.   A5 A1 A2 A3 A4 (A5 is paired with B1, etc) 
      B1 B2 B3 B4 B5 
  6. Have each new pair practice the Numbers activity below
  7. Now switch pairs again by having everyone in line A move one spot. You should now look like this:
  8.   A4 A5 A1 A2 A3
      B1 B2 B3 B4 B5 
  9. Have each new pair practice the Song activity below

Performing the game

  1. This game will be performed in two rounds
  2. Round One:
    • You as the project manager will tell the teams which activity (project) to work on.
    • You will bark out instructions ("Shout-Driven Develolpment") and they are expected to switch tasks on your command. For each activity they need to switch to perform the activity with the pair they practiced that activity with. (This will involve a lot of movement.)
    • When each pair resumes an activity that they have already started they must pick up where they previously left off.
    • Your time keeper should record the time when the whole team (all pairs) have finished each activity.
    • Keep asking the team to task switch every 2-10 seconds (be random!) until all pairs have completed the activities.
    • Record the completed time for each activity.
  3. Round Two:
    • You as the project manager will tell them the priority of the activities (projects). You will ask them to complete Hands first, Numbers second, and Song third. You ask them to complete each activity (project) before starting the next.
    • Your time keeper should record the time when the whole team (all pairs) have finished each activity.
    • Record the completed time for each activity
  4. Your results should look similar to the results in the image below. Note: we played this game twice after adding more people - the purple numbers are the results of the second game.

Additional Tips and or Alterations

Alan Cyment commented on this blog (see below) with some alterations and changes that he is using. Take a look at some of these additional tips and ideas:
  • Have the group decide how to rotate partners instead of defining the rotation for them.
  • Run the sequential round first and then the multitasking round.
  • Have the group choose their own song instead of Happy Birthday.
  • For larger groups, ask them to put their hands up when they complete each 'project'. This will help the time keeper to understand when each project is completed amidst the chaos.
  • Instead of acting as the project manager, act as the product owner who represents three different customers/stakeholders.


  • What did you think of the game? 
  • What are some conclusions you can draw about how you are currently working? 
  • Notice that in the second attempt you completed all three tasks before you completed the first one in the multi-tasking round. What do you think about that? 
  • For the two rounds, notice your time to market.
  • How different was the quality of your product in round one and two?
  • What did you notice about your stress level in round one and two?
  • What does this game teach us about sustainable pace?
  • Describe your discipline level in each round. How much did your team cheat or ignore the manager's orders?
  • How does that affect how you will work? 
  • What happens when you task switch? 
  • What are the costs to juggling tasks? 
  • How can we change the way we work to take advantage of this? 
  • What are the barriers to making this happen? 
  • How can you respond to someone who is asking you to switch to another task or to split yourself between two or more projects?

The Activities:


  • Clap your own hands / Clap your both of your partner’s hands 
  • Clap your own hands / Clap your partner’s right hand 
  • Clap your own hands / Clap your partner’s left hand 
  • Clap your own hands / Clap your right hand to your left foot 
  • Clap your own hands / Clap your left hand to your right foot 
  • Repeat once


  • First person holds up 1 finger / second person claps once 
  • First person holds up 2 fingers / second person claps twice (up to five) 
  • Then switch roles and repeat once


Sing/say the Happy Birthday song alternating each word. One person says the first word, your partner says the second, you say the third, etc:
  • Happy birthday to you 
  • Happy birthday to you 
  • Happy birthday dear <name> 
  • Happy birthday to you 
  • Repeat once

Additional Resources:


From QSM 1, Systems Thinking (Dorset House, 1992). Jerry Weinberg:
  • # of tasks = 1 - Time spent on task = 100% 
  • # of tasks = 2 - Time spent on task = 40% 
  • # of tasks = 3 - Time spent on task = 20% 
  • # of tasks = 4 - Time spent on task = 10% 
  • # of tasks = 5 - Time spent on task = 5% 
  • # of tasks = more than 5 - Time spent on task = random.

Links on Multi-tasking

Links on combatting multi-tasking

 Subscribe to Winnipeg Agilist by Email

Tuesday, January 24, 2012

Sea Star Wars: A lesson in organizational change

Sometimes in order to make a change happen, all you need to do is change the environment.

This summer I witnessed a great example of this in a small but fantastic aquarium in Ucluelet, BC. When you see a sea star in the ocean or at the aquarium, you rarely or if ever see them move. However, the staff at the aquarium instigated a sea star race by changing the environment. They put the feared Morning Sun Star in the same tank with other sea stars including the very large Sunflower Sea Star. Once the other sea stars detected the presence of the Morning Sun Star they all started to move away from it as fast as they could. The sudden reactions and speed of those sea stars was a sight to see – a turtle would have been proud!

If you have analysts, developers, testers and users who don’t communicate very well you can help encourage better communication by changing the environment. Create a co-located space and then have them all work in that space together. The environmental change forces them to acknowledge each other’s presence and begin working together. Instead of “Hey, there’s a dangerous Morning Sun Star in here and I have to run away before it eats me”, you should get reactions like “Hey – there’s a user in here, I guess I’ll show them the changes I’m making to this screen to get some feedback”.

Subscribe to Winnipeg Agilist by Email

Wednesday, January 18, 2012

SOPA Blackout

I couldn't find a SOPA gadget for blogger, so in solidarity with all the other blackouts today here is a link to an article on why SOPA should concern you:

Here is the conclusion of that article:

"In Conclusion

It is my strong belief that both PROTECT IP and SOPA:
  1. Will not stop the piracy they are targeting
  2. Contain language that is highly ambiguous and extremely broad making them ripe for abuse, and
  3. Introduce regulation and enforce censorship on what should be a free and open internet."

Sunday, January 15, 2012

Estimating tasks in hours is local optimization. Stop doing it!

This weekend I was listening to Eliyahu M. Goldratt's "Beyond the Goal" where he expands on the Theory of Constraints. In chapter three I listened to him explain how estimating in hours is in fact local optimization and therefore "idiotic". Here is a portion of that chapter loosely transcribed:
"The way to ensure that the project will finish on time is to ensure that every task will complete on time. This is the local optima policy that leads to a huge conflict. Placing a person on such a project jeopardizes the most important thing for them - their own image.

Suppose you are this person and you are asked how much time will this task take? You are extremely reluctant to give any number. And when you give that number the Project Manager will try to squeeze it. Why are you reluctant? Because you know that the number you give is an estimate but that it will be converted to a commitment - because the project needs to finish on time.

So what situation does this place you in? This common procedure of turning estimates into commitments puts you into a huge dilemna. Why? The objective of every person is to be regarded as a reliable person by your boss, by your peers, by people. But what is the meaning of being reliable? For example, if you give a commitment and you don't meet it - once is ok. But if you give a commitment and many times don't meet them do you expect to be regarded as reliable? Of course not. So one of the conditions of being a reliable person is to meet your commitments.

Also - if you are fighting for something (an estimate) and then it turns out that you have exaggerated by a mile? If it happens once, fine. If it happens frequently, then you will get the name of someone who exaggerates wildly - so kiss goodbye the image as someone who is reliable. In other words, another consideration for being a reliable person is to not be considered as someone who exaggerates. Now look what is happening when I come and ask you how long it will take to finish this task?

Now look - whatever you do, you are doomed. This is a huge personal conflict. How do we in reality deal with this conflict? Let's face it - this conflict is so important we must find a way to break it. We want to not only be reliable, but to be considered reliable. How do we do it? We cheat.

So we finish our estimates on the nose and sometimes a little more. They become self fulfilling prophecies. If there is a danger of finishing too quickly we add some more tests, do a more thorough job, we add another function in, we check things a little more thoroughly, and we finish on the nose. Do you see what's happening?

Due to the result that our local optimization turns any estimate into a commitment, we have developed the habit of giving estimates which includes in it the safety. If murphy (i.e. Murphy's Law) doesn't hit, we waste the time rather than giving it to the next link in the chain or project. If we do give it to the next link then we are declared as exaggerating and next time they won't give us the extra time. So look what a horrible situation this is. And this... is what kills the project. This is totally idiotic"
When you read this story the first time you will likely notice there are several examples in there of how not to run a project, of poor leadership, and his concluding statement is a little harsh. As many commenters have pointed out, this style of project management is not similar to how we typically run agile projects. However, at the core of the story is the desire of each person to be reliable by meeting hourly estimates whether they are created by the team, by yourself, or by someone else. When I first listened to this argument I was fascinated by that part of it. So, if that part of his argument is correct, then what alternatives do we have if we need to estimate? (This paragraph has been updated based on the comments - thank you)

If your project requires an estimate:
  • Stop estimating tasks or user stories in hours - hopefully the argument above has already given you enough reason to at least consider this 'radical' change.
  • Don't estimate user stories in hours or convert relative points to hours. OK - I do understand that it can be valuable to look historically at hours vs. points, but don't use this conversion for guessing how long a task or user story will take.
  • There is some evidence that due to variability, counting the number of stories completed in an iteration is of equal value to counting the number of points completed in an iteration (velocity). This would help keep the focus off of hours per user story or task.
  • Where possible, avoid asking how many hours are left for a task or user story. I understand why and how this information can be valuable, but understand the risk you take when you ask this question. 
  • If possible, estimate at higher levels (epics) rather than lower levels (user story).
  • Give broad project estimates with ranges like 1-2 months, 3-6 months, 1-2 years instead of doing detailed estimates. Most projects don't need a detailed estimate in order to determine if they should be completed or not. For many projects on our list we already have a good enough guess about their size to understand their value compared to the cost. (Unfortunately, as a consultant that usually doesn't include the projects I work on).
  • This logic also suggests that relative estimating might be dangerous. I still have to think about that one as there are significant benefits to exercises like planning poker even if estimates are not created as output.
If your project does not require an estimate:
  • Do a little song and dance!  
In either case, continue to break down your project into smaller projects and small deliverable pieces of value and working code. Build the high priority pieces first in an iterative  fashion. Make a decision about whether the project is done after each completed story or each iteration to avoid the problem described above - the temptation to finish on your estimated completion date. Continue measuring your progress using completed stories but consider using cycle time (average time to completion for all stories) vs. velocity (average number of points completed in a given time frame) to avoid some of the local optimization that could occur for each user story.

For further reading on the Theory of Constraints, check out any of Goldratt's books. I highly recommend starting with The Goal which is also available on iTunes Canada as an audiobook for $2.95.

Subscribe to this blog by Email

Monday, January 9, 2012

Silent Brainstorming

I read an interesting article earlier this week that summarized some of the latest research on brainstorming. The research found that group brainstorming (out loud) doesn't restrict the amount of ideas generated, but it does restrict the variety of ideas. By contrast, brainstorming as individuals allows a greater variety of ideas to be generated. They also found that once the ideas were generated, having a group discussion about the ideas was beneficial in order to combine and improve upon the ideas. Here are some interesting quotes:
"Cognitive fixation causes people to focus on other people's ideas and are, inevitably, unable to come up with their own."
"If the goal is to come up with a bunch of unique ideas or solutions to problems, then the group should be split up so that individuals can come up with their own ideas and these ideas can later be combined with other members' ideas."
"...a group session after an individual session might be the optimal brainstorming technique."
So how can you combine both individual and group brainstorming? Here is an approach that I have been using that I've put together based on my experiences facilitating and participating in other sessions. This approach can be used for any brainstorming session whether you are trying to generate user stories, ideas for a retrospective, or strategies for your community group.

Step 1: Establish the goal.
Make sure everyone understands the purpose of the brainstorming session. For many sessions this can be communicated to attendees before the meeting begins.

Note: If your group is larger than 10, I would recommend splitting the group up into several smaller groups for steps 2 through 5. The groups can present their best ideas to each other at the end of the exercise and re-open the discussion and voting at that point if appropriate.

Step 2. Individual (and silent) brainstorming.
Hand out post-it notes to everyone in the group. Ask each person to write down one idea per post-it until they run out of ideas. This part of the session should be performed in silence. There are a few cues to look for to understand when the group is done but the most consistent one I use is to watch their body language. When most of the group is leaning back or looking up, they are probably done. If you are having trouble reading their body language, a good rule of thumb is to wait until most people have at least 3-5 ideas written down. Also - be prepared with extra post-it notes in case someone runs out. I once had a participant say "I stopped thinking when I ran out stickies" ;).

Step 3. Describe your ideas
Once everyone has finished writing down their ideas, choose one person and ask them to describe their best idea and then place that post-it on the wall or the table. Continue going around the table asking each person to describe their top one idea until all ideas have been presented. It should take several rounds and each person will have the opportunity to present several ideas - one during each round. While the ideas are being described encourage everyone to keep writing additional ideas down. This allows the group to combine and improve upon ideas presented by others.

Step 4. Group the ideas
There are several ways to group the ideas depending on your group size.

a) If your group size is five or less I prefer using silent affinity grouping because it is fast and collaborative. Ask your team to silently group the ideas. Things that are similar to each other should be moved closer to each other. Things that are dissimilar to each other should be moved farther apart. Groups should form naturally and fairly easily. Once again, body language will help you see when they are done - usually 2-3 minutes.

b) If your group size is more than five I prefer to have one person group the post-its as they are presented because it is faster. Simply put the post-it near other post-its with similar ideas.

Once the groups are created you can name each group with a short title.

Step 5. Silent Voting
If you need to vote on the ideas or on the groups, I prefer using silent voting. Number each post-it and then ask each person to write down their top three on a post-it. Once all the votes are in, tabulate the votes to identify the top ideas.

This method of brainstorming combines the best of both individual and group brainstorming techniques and is consistent with the latest research. However, I initially started using it not because it conforms to the latest research but because it allows everyone to have a voice - the loud people can't dominate the conversation and the quiet people are given a way to contribute. That it reduces the effect of cognitive fixation when generating the initial list of ideas is an added benefit.