tag:blogger.com,1999:blog-79032272150353134442024-02-28T04:29:57.445-06:00Winnipeg AgilistSteve Rogalsky's thoughts on agile and lean in the contexts of software development and life.Anonymoushttp://www.blogger.com/profile/13339165557417141875noreply@blogger.comBlogger91125tag:blogger.com,1999:blog-7903227215035313444.post-18837497331427813342015-07-03T17:13:00.000-05:002015-07-03T17:13:03.200-05:00Powerful questions leaders can askI have been reading David Marquet's book "<a href="http://www.amazon.ca/Turn-Ship-Around-Turning-Followers/dp/1591846404">Turn the Ship Around</a>" which is an interesting story of turning followers into leaders aboard the <a href="https://en.wikipedia.org/wiki/USS_Santa_Fe_%28SSN-763%29">nuclear submarine Sante Fe</a>. In the weeks before he took over as captain, he spent time with the crew asking them questions in order to understand the current state and possible areas for improvement. Here are some of the powerful questions he asked: <i>(some questions modified slightly to reflect organizations instead of nuclear submarines...)</i><br />
<br />
1. What are the things you are hoping I don't change?<br />
2. What are the things you secretly hope I do change?<br />
3. What are the good things we should build on?<br />
4. If you were me, what would you do first?<br />
5. Why aren't we doing better?<br />
6. What are your personal goals in this organization?<br />
7. What impediments do you have that keep you from doing your job?<br />
8. What will be our biggest challenge moving forward?<br />
9. What are your biggest frustrations about how this organization is currently run?<br />
10. What's the best thing I can do for you?<br />
<br />
I'm a big fan of powerful questions that help drive empathy and improvement and I think these questions do exactly that. This set reminds me of an earlier <a href="http://winnipegagilist.blogspot.ca/2011/07/assessing-your-process-6-great.html">list of questions</a> I wrote about to assess your current process. I've used those questions in a few organizations with great results.<br />
<br />
Finally, remember that David began asking these questions at the beginning of his assignment, but had the long term goal of creating a leader-leader structure, and not a leader-follower structure. If you want to emulate what he has done, then eventually your whole organization should be asking these questions of each other.<br />
<br />
<i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to this blog by Email</a></i>Steve Rogalskyhttp://www.blogger.com/profile/06799015247942648718noreply@blogger.com0tag:blogger.com,1999:blog-7903227215035313444.post-16325630528441418352015-06-17T14:45:00.001-05:002015-06-17T14:45:49.758-05:00Effective Brainstorming – tweaking TED’s adviceEffective brainstorming has two basic elements. <br />
<br />
The first element is engagement. Getting everyone to contribute and not only those who are most comfortable speaking in a group is critical. Laura McClure recently wrote about this on <a href="http://blog.ted.com/how-to-run-a-brainstorm-for-introverts-and-extroverts-too/">TED.com</a> with some great tips for including introverts. It isn’t enough to simply ask introverts to contribute. When you use effective techniques to engage everyone in the room, you can feel the excitement growing as the list of ideas grows.<br />
<br />
The second element is divergence. To find the best idea, you need to start with the widest number and variety of ideas. This is where Laura’s advice needs tweaking. There is an incorrect assumption in her advice that brainstorming out loud will produce more ideas; that hearing a few ideas will kick start the idea generator in our brains. <br />
<br />
The overwhelming research on brainstorming <br />
indicates that we should first generate ideas on our own before processing those ideas as a group (see below for links). That is, write down your own list of ideas first, and then discuss and expand on those ideas in a group. There are a lot of social and psychological reasons why this is true, but the resulting advice is consistent. If you want the widest number and variety of ideas to consider, then brainstorm as individuals first before processing those ideas as a group. Diverge, before you converge.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEif9QeyTyC5aAAyw5wTO5GhsXbPivTMjraaOikGFwoWyJK4SthazOlAIR3aTxfM6niR2tW50GP-VLtWuD-SA-85yy5ouCR-0Ipi6AmF_QMU1B8qqWvTEDOIjJq9OI6hIlrNrDeCZx7DrvKy/s1600/DivergeThenConverge.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="205" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEif9QeyTyC5aAAyw5wTO5GhsXbPivTMjraaOikGFwoWyJK4SthazOlAIR3aTxfM6niR2tW50GP-VLtWuD-SA-85yy5ouCR-0Ipi6AmF_QMU1B8qqWvTEDOIjJq9OI6hIlrNrDeCZx7DrvKy/s400/DivergeThenConverge.png" width="400" /></a></div>
<br />
Based on that research, here are some tweaks to her article:<br />
<br />
1. <b>Start the session by asking everyone to write down their initial ideas in silence</b>. Her advice to “circulate the question or topic before you start” is great for everyone. But, in the likely case that everyone hasn’t prepared a list in advance, take time at the beginning of the session to give people a chance to write down their ideas. I like to hand out post-it notes and ask everyone to write one idea per note. This also allows us to easily group related ideas later on.<br />
<br />
2. <b>Don’t start by listing a few options you’re already considering.</b> Her passive brainstorming techniques sound fun, but don’t start with an email string that lists a few options you’re already considering, and don’t start with a blank canvas. Both of these will lead to <a href="http://winnipegagilist.blogspot.ca/2013/05/q-why-silence-priming.html">priming </a>and will result in fewer ideas. Instead, first hold a brief <a href="http://winnipegagilist.blogspot.ca/2012/01/silent-brainstorming.html">silent brainstorming session</a> to generate the initial list of ideas before posting them on the wall for everyone to interact with.<br />
<br />
In summary, whether you are trying to solve a recurring problem or discover the next great innovation, don't unintentionally limit the number of ideas you are considering. To effectively generate a wide variety of ideas, brainstorm as individuals first before processing those ideas as a group.<br />
<br />
<br />
<b>Brainstorming Research</b><br />
<a href="http://winnipegagilist.blogspot.ca/2013/05/q-why-silence-priming.html">http://winnipegagilist.blogspot.ca/2013/05/q-why-silence-priming.html</a><br />
<a href="http://onlinelibrary.wiley.com/doi/10.1002/acp.1699/full">http://onlinelibrary.wiley.com/doi/10.1002/acp.1699/full</a> <br />
<a href="http://www.businessinsider.com/brainstorming-team-building-effectiveness-2012-1">http://www.businessinsider.com/brainstorming-team-building-effectiveness-2012-1</a> <br />
<a href="http://charlannemeth.com/files/NPPGLiberatingRoleUSFR.pdf">http://charlannemeth.com/files/NPPGLiberatingRoleUSFR.pdf </a><br />
<a href="http://www.nytimes.com/2012/01/15/opinion/sunday/the-rise-of-the-new-groupthink.html?_r=2&pagewanted=all">http://www.nytimes.com/2012/01/15/opinion/sunday/the-rise-of-the-new-groupthink.html?_r=2&pagewanted=all </a><br />
<a href="http://www.newyorker.com/magazine/2012/01/30/groupthink?currentPage=1">http://www.newyorker.com/magazine/2012/01/30/groupthink?currentPage=1</a> <br />
<br />
<b>Slides and presentations on this topic:</b><br />
<a href="http://www.slideshare.net/SteveRogalsky/silent-brainstorming-a-guide-to-using-postits">http://www.slideshare.net/SteveRogalsky/silent-brainstorming-a-guide-to-using-postits</a> <br />
<a href="http://www.slideshare.net/SteveRogalsky/the-silence-of-agile">http://www.slideshare.net/SteveRogalsky/the-silence-of-agile</a><br />
<a href="http://www.infoq.com/presentations/Silent-Brainstorming">http://www.infoq.com/presentations/Silent-Brainstorming </a><br />
<br />
<i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to this blog by Email</a></i>Steve Rogalskyhttp://www.blogger.com/profile/06799015247942648718noreply@blogger.com1tag:blogger.com,1999:blog-7903227215035313444.post-53154709004448326622015-05-26T14:55:00.000-05:002015-05-26T14:55:36.169-05:00Journeying Towards #NoEstimatesI’ll admit that until I discovered <a href="http://en.wikipedia.org/wiki/Planning_poker">planning poker</a> many years ago, estimating was not my favourite thing to do. Even though I had experienced some estimating success, there was an underlying realization that every time I estimated, I was rolling the dice. It is probably why #RelativeEstimating through planning poker was such a big relief to me. The game was still rigged, but treating estimates in a relative way allowed me to be wrong early and adjust so that my odds of winning at the end were improved. It was a useful paradigm shift. <br />
<br />
The recent <a href="https://twitter.com/hashtag/NoEstimates">#NoEstimates</a> movement has brought increased visibility to an issue that many find contentious. Some assert that estimates are required for any professional software project. Others declare that estimates are harmful enough that we must find a way to reduce or eliminate them altogether. Personally, I’ve found the discussions about #NoEstimates valuable enough that I decided to do some research and then run some experiments of my own in order to move in that direction. Here are the results of two of those experiments:<br />
<br />
<b>Experiment #1: Relative Points</b><br />
<br />
For my first experiment, I decided to look at our data. We had already been using planning poker for some time, and we were working with a client who had requested that we track our actual hours per user story. <i>(We don’t always do this for various reasons that are outside the scope of this article.) </i>The question I was trying to answer when looking at the data was this: <br />
<br />
<div style="text-align: center;">
Will our actuals hold true to the relative sizes we had assigned them?</div>
<br />
That is – if a story worth 1 point has an actual average effort of 10 hours, will a story worth 2 points have an actual average effort of 20 hours, etc. For this project, we used points of 0.5, 1, 2, 3, 5, 8, 13, and 20. The “Actual” hours in the graph below are divided by a number so that the Y axis is similar. Here are the results:<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0Ai7UbmTSId6wAL3T75_HlYcFXtoDo50zDux-nvyCNhSJAwKfNEI9K_8E9C0Rg63fSuFsyU7zKccg1uPTqKSEuLgcYE9K4Yhe5kRH-QYwe8qEraWAYs6NBU9MfJquNIf2po10t3IbvrbE/s1600/PointsVsActual.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="242" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0Ai7UbmTSId6wAL3T75_HlYcFXtoDo50zDux-nvyCNhSJAwKfNEI9K_8E9C0Rg63fSuFsyU7zKccg1uPTqKSEuLgcYE9K4Yhe5kRH-QYwe8qEraWAYs6NBU9MfJquNIf2po10t3IbvrbE/s400/PointsVsActual.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Project 1</td></tr>
</tbody></table>
<br />
<br />
So, there it is – we were almost perfect at relative estimating for that project! That belief held firm right up until the next project: <br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQigjWRihUWQHU-yL38OzjgSIB-BpJMXGaOKA_gbIXPfNkYeFAPdyK4CIEDUJ0FeCdy3B5SAspyW1KfhuLvyYHw2r_vE87dTJpCAcCO-F4VKdVfSkyr8VDpAnv94QFPZ3DeBnM_twpI-I_/s1600/PointsVsActual2.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="218" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQigjWRihUWQHU-yL38OzjgSIB-BpJMXGaOKA_gbIXPfNkYeFAPdyK4CIEDUJ0FeCdy3B5SAspyW1KfhuLvyYHw2r_vE87dTJpCAcCO-F4VKdVfSkyr8VDpAnv94QFPZ3DeBnM_twpI-I_/s400/PointsVsActual2.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Project 2</td></tr>
</tbody></table>
<br />
That’s right, in “project 2”, our 1 point stories took longer on average than our 8 point stories. Still, the relative actuals of stories with points 2 through 8 weren’t too far off and we held on to some belief that the 1 pointers may have been an aberration.<br />
<br />
Enter “project 3”:<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1nEqYbR9urpL9JEzqSxcaL8i9tO2tDWXSfMEYsjts8wGI88YuyaAdJ5qpLxOk5WnJR7xql4qgHH2DcuYfkiXFjXoHVw2C_kb6s8VJVX1mwlJFdgHpG11S-rKii_FNKh9Tg7Z-XmQHwis7/s1600/PointsVsActual3.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="268" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1nEqYbR9urpL9JEzqSxcaL8i9tO2tDWXSfMEYsjts8wGI88YuyaAdJ5qpLxOk5WnJR7xql4qgHH2DcuYfkiXFjXoHVw2C_kb6s8VJVX1mwlJFdgHpG11S-rKii_FNKh9Tg7Z-XmQHwis7/s400/PointsVsActual3.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Project 3</td></tr>
</tbody></table>
<br />
“Project 3” took away any remaining belief about the accuracy of our points estimating by giving us what looked like completely random results. Roll the dice.<br />
<br />
<b>Experiment #2: Points to Count</b><br />
<br />
However, this wasn’t enough to convince me to run away from the data. By this time, there were multiple reports of people comparing the sum of their iteration velocities to the count of stories that were being completed. That seemed like a reasonable experiment, so once again I turned to the data. This time, the question I was trying to answer when looking at the data was: <br />
<br />
<div style="text-align: center;">
Is summing the number of points per period just as useful for planning </div>
<div style="text-align: center;">
as counting the number of completed stories per period?</div>
<br />
At this point we already had data for 3 projects so we could start graphing right away. Since the initial results were favourable, the graph below shows data from 8 different projects over the course of more than a year:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwXPgsb_Izcy2JCsRDxH1d4V6DOKQcp-kpgacgPD3hZJQ98IzUgXv0sv-tx30Eebgs95iwYcOJbBEwPaYdqsmDQsXvHvvk8ekfeiMq14Q7oAKMDijRwzD0yAadysIxFXaZpziEy8USmnMN/s1600/BurnUp.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="215" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwXPgsb_Izcy2JCsRDxH1d4V6DOKQcp-kpgacgPD3hZJQ98IzUgXv0sv-tx30Eebgs95iwYcOJbBEwPaYdqsmDQsXvHvvk8ekfeiMq14Q7oAKMDijRwzD0yAadysIxFXaZpziEy8USmnMN/s400/BurnUp.png" width="400" /></a></div>
<br />
<br />
This graph clearly illustrated to us that we could stop estimating in points and instead just count the number of ‘done’ user stories for planning and forecasting purposes. It has allowed us to move closer to #NoEstimates by removing one more estimating step. We no longer need to use planning poker to agree upon a number – instead we keep slicing stories until they are ‘small enough’.<br />
<br />
<b>Summary</b><br />
<br />
In summary, these two experiments didn’t lead us to stop estimating altogether, but they have definitely moved us in that direction. We can still use data to help us forecast and plan, but we are less dependent on estimates to do so. This helps us reduce some of the dangerous effects of estimates, with the additional benefit of getting to spend more time delivering value.<br />
<br />
As a bonus, these two experiments nudge us towards continued process experimentation - something I'm happy to endorse.<br />
<br />
<i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to this blog by Email</a></i> Steve Rogalskyhttp://www.blogger.com/profile/06799015247942648718noreply@blogger.com0tag:blogger.com,1999:blog-7903227215035313444.post-79962319312005157912015-04-02T09:16:00.000-05:002015-04-02T09:16:20.414-05:00Commitment as a Facilitation Weapon?I recently finished reading “<a href="http://www.amazon.ca/Influence-Psychology-Persuasion-Robert-Cialdini/dp/006124189X">Influence: The Psychology of Persuasion</a>” by Cialdini. The six ‘<a href="http://en.wikipedia.org/wiki/Robert_Cialdini">weapons of influence</a>’ that he describes in the book are fascinating and I found myself thinking about how any influence tool can be used for good or ill.<br />
<br />
One of the principles that caught my attention with respect to the work that I do was the Commitment principle. Cialdini describes several ways that people can be influenced using this principle. For example, two groups of people participating in an experiment were asked to donate to a cancer charity. One of the groups donated more money than the other through a simple influence ‘trick’. A week before being asked to donate, that group was asked to wear a cancer awareness button - something simple that they could hardly say no to. However, the simple act of wearing the button for one week influenced their donation habits later on.<br />
<br />
You may also recognize this principle in your own purchasing stories. For example, automotive dealerships will wait until you commit to purchasing your vehicle before talking about extended warranties, undercoating, or other extras. They know that asking for these extras after you commit to the larger purchase will increase the chance that you will spend a few more dollars.<br />
<br />
However, not all uses of this principle need to be used to gain more sales dollars. I first came upon this principle when I was watching Linda Rising facilitate a retrospective for the planning team of <a href="http://agilevancouver.ca/">Much Ado About Agile</a> in 2010. She started the retrospective by reciting <a href="http://www.retrospectives.com/pages/retroPrimeDirective.html">North Kerth’s Prime Directive</a> and then asked each team member one by one if they would verbally agree to uphold this statement during the meeting. Later, she told me that this simple verbal agreement is an influencing strategy that helps set the right tone for the retrospective. As Cialdini notes, if people commit to an idea verbally, they are more likely to follow through on that commitment.<br />
<br />
So, whether you are trying to increase sales, or just set a positive tone for your next meeting, give the commitment principle a try.<br />
<br />
<i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i> Steve Rogalskyhttp://www.blogger.com/profile/06799015247942648718noreply@blogger.com0tag:blogger.com,1999:blog-7903227215035313444.post-70055360917051184452015-03-26T09:49:00.000-05:002015-03-26T10:25:00.220-05:00Acknowledgment as MotivationRecently at <a href="http://www.prairiedevcon.com/">Prairie Dev Con</a> I gave a talk on <a href="https://twitter.com/hashtag/noestimates">#NoEstimates</a> and part of the discussion centered on the practice of using estimates as motivation. Using estimates as motivation *may* be effective in the short term, but in the long term I believe it is dangerous and more likely to negatively affect motivation. As an alternative, in the talk I briefly reviewed <a href="https://www.youtube.com/watch?v=u6XAPnuFjJc">Dan Pink's</a> work on motivation that centers on Autonomy, Mastery, and Purpose. Have a quick look at that video if you haven’t already. Today I watched a Ted talk called '<a href="http://www.ted.com/talks/dan_ariely_what_makes_us_feel_good_about_our_work?language=en#t-1193035">What Makes Us Feel Good About Our Work?</a>' by Dan Ariely that provides another angle on motivating through acknowledgment.<br />
<br />
In the middle of the talk, he describes an experiment they ran to try and understand the role of acknowledgment in making us feel good about our work. The task in the experiment was fairly straightforward. Participants were given a piece of paper filled with random letters and were asked to find the pairs of letters on that page. For example, in "aswwhggjks", you would find the pairs "ww" and "gg". Participants were paid a certain amount to complete the first page, and then for every subsequent page they would complete, they were paid slightly less.<br />
<br />
In the first version of the experiment, when participants handed in their work the experimenter reviewed it from top to bottom and acknowledged the effort with a simple "uh huh" before putting the paper on a pile. In the second version of the experiment, the experimenter did not review their work and simply put the paper on a pile. In the third version of the experiment, the completed work was put straight into a shredder without any acknowledgment at all.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjcLfYOiflC1g4lWTiEdL3LBt-V1Mo-21ugXU4rIjbIV2rJ3z0V9EJuAn3zhtDyqv_MowwFC8Ud23G0NvFVxfSrFaMlQJmMFrJRKJTfCuvnz6ch5S1BM8vfhphrpOYprvfXVciVsjDx0rGv/s1600/DanArielyMotivation.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjcLfYOiflC1g4lWTiEdL3LBt-V1Mo-21ugXU4rIjbIV2rJ3z0V9EJuAn3zhtDyqv_MowwFC8Ud23G0NvFVxfSrFaMlQJmMFrJRKJTfCuvnz6ch5S1BM8vfhphrpOYprvfXVciVsjDx0rGv/s1600/DanArielyMotivation.png" height="269" width="320" /></a></div>
The results of the experiment are displayed in the image - people were willing to work for much less in the first version of the experiment than in the second and third versions. In addition, people stopped working at about the same level if their work was being ignored or shredded. As Dan summarized, <b>"ignoring their performance is almost as bad as shredding it."</b> There is good news and bad news here. The bad news is that if you aren't acknowledging the efforts of your team or employees on a regular basis, it is likely having a negative effect on their motivation. The good news is that there are some simple experiments you can try:<br />
<ul>
<li>Add regular checkpoints with your team members to thank them for some specific contribution.</li>
<li>In your regular team retrospectives, start by celebrating the great work you have done together.</li>
<li>Schedule time in your calendar to give positive feedback to your team on a regular basis.</li>
<li>Schedule in regular demos so that your team can show off how they are delivering value to actual customers</li>
<li>Pass on good feedback from your customers to the team.</li>
<li>Start using <a href="http://management30.com/product/kudo-cards/">KUDO cards</a> to acknowledge good work.</li>
<li>Buy a $2 box of brownie mix, add an egg, some vegetable oil, and bring some fresh brownies to your team as a thank you.</li>
</ul>
<br />
Thanks for reading - I appreciate it.<br />
<br />
<i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i>Steve Rogalskyhttp://www.blogger.com/profile/06799015247942648718noreply@blogger.com0tag:blogger.com,1999:blog-7903227215035313444.post-64247051210950963312014-11-12T12:52:00.001-06:002015-03-26T10:17:45.957-05:00Story Maps - A Testing Tool After All<div style="background-color: #eeeeee; color: #20124d;">
</div>
<div style="background-color: #eeeeee; color: #20124d;">
<i>The following was recently published as a sidebar in Lisa Crispin and Janet Gregory's new book <a href="http://www.amazon.com/More-Agile-Testing-Addison-Wesley-Signature/dp/0321967054/ref=sr_1_1?ie=UTF8&qid=1415818036&sr=8-1&keywords=more+agile+testing">More Agile Testing</a>. The book is full of great advice from the authors as well as other contributors. I encourage you to take a look.</i></div>
<div style="color: #20124d;">
</div>
<br />
So you’re an agile tester and wonder why you should care about story maps. You may already be convinced that modelling your backlog in two dimensions is useful for helping the whole team visualize the big picture. However, story maps are also a valuable testing tool, providing two additional testing avenues. In the first case, the map itself offers the ability to test the validity of a solution. In the second, a story map improves a team’s ability to identify story slices and then test them.<br />
<br />
<div class="separator" style="clear: both; text-align: left;">
<span style="align: left; background-color: #eeeeee; clear: right; float: right; margin-bottom: 1em; margin-left: 1em; padding: 10px;">
<b>User Story Mapping Series</b>
<br /><br />
* <a href="http://winnipegagilist.blogspot.ca/2012/03/how-to-create-user-story-map.html">How to Create a User Story Map</a><br />
* <a href="http://winnipegagilist.blogspot.com/2013/02/how-to-prioritize-user-story-map.html">How to Prioritize a User Story Map</a><br />
* <a href="http://winnipegagilist.blogspot.com/2012/12/tips-for-facilitating-user-story.html">Tips for Facilitating a User Story Mapping Session</a><br />
* <a href="http://winnipegagilist.blogspot.ca/2013/06/dont-etch-your-user-story-map-in-stone.html">Don't Etch your User Story Map in Stone</a><br />
* <a href="http://winnipegagilist.blogspot.ca/2014/09/user-story-mapping-tool-review.html">User Story Mapping Tool Review – SmartViewApp</a><br />
* Story Maps - A Testing Tool After All
</span></div>
<b>Testing What to Build</b><br />
<br />
User story maps are a representation: they provide a means to visualize a system that might be built and are useful for testing the validity of that system before investing significant time and money. A story shared at a recent Agile Winnipeg event demonstrated this principle well. The company involved used story mapping to test an idea before building any software. The team had a project idea that they thought would serve their client well. After quickly building a story map around that idea, they presented the map to their client at the next customer conference. Although it soon became clear that the idea missed the mark, the customer was able to collaborate with the team on the spot, to adjust the map until it represented what they actually wanted built. The map itself was the tool that allowed for the idea to be tested (and then adjusted) and moved the project forward.<br />
<br />
<b>Testing Application Slices</b><br />
<br />
As Crispin and Gregory demonstrated in their first book <a href="http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468/ref=sr_1_1?ie=UTF8&qid=1415816983&sr=8-1&keywords=Agile+Testing">Agile Testing</a>, identifying thin slices and small chunks is important for testing agile projects. Story maps help identify those slices but, perhaps more importantly, they help us understand how those thinly sliced stories might fit together to form a thin slice of the whole application. When undertaking an agile project, testers are required to make a vital shift in thinking; only test small pieces at a time. Despite this fundamental change, it is also important to ensure that the first few pieces fit together, enabling end to end testing as early as possible. The story map helps to identify and prioritize that first application slice. It may be based on a user scenario or just a string of stories that represent the smallest stories that allow left to right movement on the map.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj3tUrPNWRuve2bBR5fpqk6tsSjb_jYGxv-vWhpYEoGhIOAyNXtSlPaaXoF_nQlovprcm_BqUQHNRaz-sKqxxOLB4H753uqmoqbPMqStgvEGFuj7YXw9ud5-2pU3vuHAGPItYmIQ_ZQThCr/s1600/StoryMapSlice.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="288" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj3tUrPNWRuve2bBR5fpqk6tsSjb_jYGxv-vWhpYEoGhIOAyNXtSlPaaXoF_nQlovprcm_BqUQHNRaz-sKqxxOLB4H753uqmoqbPMqStgvEGFuj7YXw9ud5-2pU3vuHAGPItYmIQ_ZQThCr/s400/StoryMapSlice.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Visualizing testing slices in your map</td></tr>
</tbody></table>
<br />
As that the team identifies that first slice, utilizing excellent testing skills is crucial. By looking at the map, you can identify areas that will be difficult to test, areas where the test variations are still relatively unknown, or areas that represent higher risk. This activity can help identify stories that should be included in the first application slice.<br />
<br />
When coding and testing begins, personas and user scenarios that were created can be revisited, helping to flesh out the map and application slices. Testing with a persona in mind helps ensure that the targeted customer will be satisfied with the solution. It may not be possible or wise to test if the application works well for everyone but testing should evaluate whether the targeted personas can use the application easily, and that the new functionality fits into, or adds to their current processes without getting in the way. <br />
<br />
<b>Story Maps—A Testing Tool After All</b><br />
<br />
At first glance, the story map doesn’t appear to be an obvious asset for testing, but upon closer inspection, it proves its value in any testing toolbox. The map itself is a reliable way to test that the right system is being built before any code is written. The map also provides a visual aid for testing in horizontal application slices, allowing for early confirmation that a project is on the right track.<br />
<br />
<i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i> Steve Rogalskyhttp://www.blogger.com/profile/06799015247942648718noreply@blogger.com0tag:blogger.com,1999:blog-7903227215035313444.post-64668445702309152402014-09-20T10:02:00.001-05:002014-11-12T12:56:30.972-06:00User Story Mapping Tool Review – SmartViewApp<div class="separator" style="clear: both; text-align: left;">
<span style="align: left; background-color: #eeeeee; clear: right; float: right; margin-bottom: 1em; margin-left: 1em; padding: 10px;">
<b>User Story Mapping Series</b>
<br /><br />
* <a href="http://winnipegagilist.blogspot.ca/2012/03/how-to-create-user-story-map.html">How to Create a User Story Map</a><br />
* <a href="http://winnipegagilist.blogspot.com/2013/02/how-to-prioritize-user-story-map.html">How to Prioritize a User Story Map</a><br />
* <a href="http://winnipegagilist.blogspot.ca/2012/12/tips-for-facilitating-user-story.html">Tips for Facilitating a User Story Mapping Session</a><br />
* <a href="http://winnipegagilist.blogspot.ca/2013/06/dont-etch-your-user-story-map-in-stone.html">Don't Etch your User Story Map in Stone</a><br />
* User Story Mapping Tool Review - SmartViewApp<br />
* <a href="http://winnipegagilist.blogspot.ca/2014/11/story-maps-testing-tool-after-all.html">Story Maps - A Testing Tool After All</a>
</span></div>
I’ve tried to give consistent advice when people ask me what
tools I would recommend for agile teams. In my opinion, the best tools to start
with are sharpies, post-its, and retrospectives. With these basic tools, you
can <a href="http://winnipegagilist.blogspot.ca/2012/03/how-to-create-user-story-map.html">create story maps</a>, track your improvements and progress with a
kanban board, and build just about any report you need in Excel. For beginner
teams and co-located teams, this is often more than enough. However, as you grow,
start working with remote team members, or just want more advanced and
automated reporting, you might start exploring the tool market.<br />
<br />
As a big fan of user story maps, I’ve been on the lookout
for ALM tools that include them and occasionally talk to tool vendors to see
what their long term plans are regarding story maps. As you can read in the
comments in the link above, the options are slowly increasing. In this post I’d
like to highlight a new entry into the ALM market that combines both story
mapping and kanban in a simple yet effective package.<br />
<br />
In order to give this application a good test of its
capabilities, I decided to try and create a story map that mimicked the example I created <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcgFeXWYSm3AkbKvqHJwjXG7SCxoBBmE-43HKvgdHRCo3AL1Gfr-dSxaJlFIBNxCvaize-B7e-29iB1TJpc1nxEY7jIMOhXtMF8BPGoXUyfaVsUW3iT0DqEukyjM267vu0HQ2G3znHHCtG/s1600/UserStoryMap.png">here</a>. <span style="mso-spacerun: yes;"> </span>I was able to
easily create the map, prioritize the features into releases, set the status of
the features using the kanban board, and generate a few metrics. Here are a few
screenshots: <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHFLtR23i3Avd_3oFNuXa7P3AtdP4_XIbKyE7c6M5aFRKEDccfo_1SfPwOliMswNW9UHE-uOo5uK6IcL25xNZhC2p0WWwG18MqTPWPurOFlpyb8YMSLAwJuzuWGoGxwSq8z0psCSazB1OO/s1600/SmartViewStoryMap.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHFLtR23i3Avd_3oFNuXa7P3AtdP4_XIbKyE7c6M5aFRKEDccfo_1SfPwOliMswNW9UHE-uOo5uK6IcL25xNZhC2p0WWwG18MqTPWPurOFlpyb8YMSLAwJuzuWGoGxwSq8z0psCSazB1OO/s1600/SmartViewStoryMap.png" height="199" width="320" /></a></div>
This is a picture of the user story map. At the top of the
page you can see the four user activities displayed as envelopes. In this view,
the Manage Calendar activity is open. Similar to my original story map that I
created in PowerPoint (yes, really…), the map allows you to display the
releases (I’ve used colour coding), and the status of each feature (green check
mark = done, etc.). Dragging features up or down or between user tasks is
simple.<br />
<br />
The kanban board mimics functionality you can find in most
tools. It allows you to set your own columns, set wip limits, etc, and it gives
you some metrics and reports like Cumulative Flow Diagrams. One nice bonus of
this tool is that it is already available as an iPad app so that you can carry
your kanban board and map with you anywhere.
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgzbHi9zynZtSUlJBm2Y3VrHwZiWKXTShoImf1CvhWmxGevKIH4y3RX_PMeouewVf_huK3AH1XpNSlZc1q1WF0H5YgfzCJBAkkZcEIEeN2P6eg_ZINRPBEWggUoJI0cqjPggRSuRHxFcSPY/s1600/SmartViewKanbanIPad.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgzbHi9zynZtSUlJBm2Y3VrHwZiWKXTShoImf1CvhWmxGevKIH4y3RX_PMeouewVf_huK3AH1XpNSlZc1q1WF0H5YgfzCJBAkkZcEIEeN2P6eg_ZINRPBEWggUoJI0cqjPggRSuRHxFcSPY/s1600/SmartViewKanbanIPad.png" height="239" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">IPad Version</td></tr>
</tbody></table>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh3t7ssu3-h6Mzt8xVy_aZsFgg7u9mltQfwooFQ2pWPzfuznNXEMKQtAUttVgT2MgHzt7ubjF31qXFkUk5Us2t-XAD1wz9XAnWsDMKbAk6PfctRQKYdWFau1gGQ-zCwmJi3qjE6Yalq0iXP/s1600/SmartViewKanbanWeb.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh3t7ssu3-h6Mzt8xVy_aZsFgg7u9mltQfwooFQ2pWPzfuznNXEMKQtAUttVgT2MgHzt7ubjF31qXFkUk5Us2t-XAD1wz9XAnWsDMKbAk6PfctRQKYdWFau1gGQ-zCwmJi3qjE6Yalq0iXP/s1600/SmartViewKanbanWeb.png" height="174" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Web Version</td></tr>
</tbody></table>
I was able to set this project up as a public project, so if
you want to take a look for yourself, click <a href="https://app.smartviewapp.com/projects/226?public_access_token=917e9cd09f9d23bc126050432388051f">here</a>.
Note – this application is currently only available in ‘modern’ browsers, so
you may need to download Chrome or FireFox.<br />
<br />
Not only does this tool support two of my favourite agile
practices, it is also simple and easy to use. That means you can continue to
focus on the important things - “individuals and interactions over processes
and tools”. Since the tool is currently in Beta, it also means that it is ready
for your input. In fact, some of the changes I’ve suggested have already made
it into the product. So, if you think your team is ready to add an ALM tool, check
it out <a href="http://www.smartviewapp.com/">here</a>.<br />
<br />
P.S. Need another reason to try this out? It calls us
“people”, not “resources”. Thanks SmartView!
Steve Rogalskyhttp://www.blogger.com/profile/06799015247942648718noreply@blogger.com4tag:blogger.com,1999:blog-7903227215035313444.post-68469028977291896042014-03-26T19:51:00.000-05:002014-03-26T19:51:54.083-05:00Personal Kanban, velocity, and replenishing the ready queueI was asked this question recently about personal kanban:<br />
<blockquote class="tr_bq">
"For our project board, we pull stories into (iteration) WIP based on our planned velocity for an iteration, That is, if we plan to deliver 30 points we don’t go crazy and pull 100 points worth of stories into WIP. Of course, if we complete the 30 points we can pull more, but that is not relevant to this question."<br />
<br />
"I’m wondering whether velocity is considered when managing a personal Kanban. That is, how can I limit what I pull into WIP, given points are not assigned to personal tasks and there are no planned iterations?"<br />
<br />
"Any thoughts on this would be appreciated."</blockquote>
Great question. There seem to be two questions here. The first is "how many cards can I do in time period <x>", and the second "how many cards do I pull into WIP?"<br />
<br />
<b>1. How many cards can I do in time period <x>?</b><br />
<br />
One of the benefits of doing personal kanban on a regular basis is that you start to find out that what you thought you might be able to complete in time period <x> usually tends to be unrealistic. Between disruptions and things taking longer than expected, you usually find out pretty quickly that you are completing less than you had hoped. That is also one of the advantages though - finding out how much you can realistically accomplish in a given day.<br />
<br />
However, unlike 'traditional' agile, I’m not aware of a lot of people using points or velocity on their personal kanban board. In fact, even agile teams are starting to move away from points - especially those using kanban. There is no concept of points in kanban, but rather things like cycle time (how long a card takes to go from ‘ready’ to ‘done’) and throughput (how many cards you can complete in time period <x>). Kanban assumes you are breaking things down into small-ish cards, and then based on the laws of averages (and the laws of bad estimating) that the number of cards you complete in a given time period (throughput) will even out over time so you don't need to estimate the number of points, but rather count the number of cards.<br />
<br />
If you use personal kanban for a while, you can start to track how many cards you can do in a day and use that for your planning. Personally, I don't accurately know my personal daily throughput because I'm too lazy to track it myself. But with trial and error, I've been getting better at understanding how many cards I can do in a day. I'm also using a 'Reflect' column (thanks <a href="http://blog.jabebloom.com/">Jabe Bloom</a> for the tip) that gets filled daily with everything that I complete on that day. At the end of the day I take a look at everything I've done, the type of work, the value of the work, etc, and then move it to Done.<br />
<br />
<b>2. How many cards do I pull into WIP?</b><br />
<br />
On my personal kanban board, I try to have only one card in my WIP. Less than 5% of the time I have to break that rule because I'm waiting on something and I don’t have the ability to unblock it. About 0.5% of the time I'll have 3 cards in my WIP because I'm waiting for 2 things. But generally, I only have one card in my WIP.<br />
<br />
On a related note, I generally have 5-10 cards in my 'ready' queue and I spend time at the beginning of each day replenishing that column. If something comes up during the day I'll definitely add it in at that moment, but I find it helpful to organize and prioritize when I arrive at work, and before I dive in to the day. It helps give me some cognitive ease which allows me to focus more effectively when I start to go through my cards.<br />
<br />
Hope this helps. If not, ask away!<br />
<br />
<i>P.S. For more on personal kanban, you can find the experts here:<a href="http://www.personalkanban.com/"> www.personalkanban.com</a> or read Matt Heusser’s recent article <a href="http://itknowledgeexchange.techtarget.com/uncharted-waters/yesterdays-weather/?utm_campaign=itke_smteam&utm_medium=social&utm_source=twitter&utm_content=1395331922">“Yesterday’s weather”</a></i><br />
<br />
<i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i> Steve Rogalskyhttp://www.blogger.com/profile/06799015247942648718noreply@blogger.com0tag:blogger.com,1999:blog-7903227215035313444.post-83944309544512779622013-09-30T22:44:00.000-05:002015-03-26T10:17:45.999-05:00Running a Positive Retrospective (and avoiding a gripe session)A few times recently I've been asked about retrospectives - specifically how to keep them from becoming a gripe session. Here are a few things that I've found effective:<br />
<br />
<b>1. Start with the positive </b><br />
<br />
While we certainly want to talk about and address any issues, I like to talk about the positive things that have occurred during the last period before we delve into things we might want to change. I haven't yet been involved in a retrospective where the list of positive things wasn't long. This helps set the tone for the rest of the retrospective.<br />
<br />
<b>2. Wording matters </b><br />
<br />
I still have strong memories of watching <a href="http://winnipegagilist.blogspot.ca/2010/11/agile-retrospectives-rising-patton.html">Linda Rising run a retrospective</a> for the Agile Vancouver organizing team in 2010. The words she chose as facilitator were powerful in keeping the retrospective positive yet useful. Instead of writing down "what went well", participants were asked to complete the phrase "<b>it was great because...</b>" (see the full quote and story at the <a href="http://winnipegagilist.blogspot.ca/2010/11/agile-retrospectives-rising-patton.html">link </a>above). Instead of writing down "what didn't go well", they were reminded that no process is perfect and to write down "<b>what they would do differently the next time</b>". This simple re-wording of the phrases is powerful.<br />
<br />
<b>3. Every voice is heard </b><br />
<br />
If you've met me in person or even just through this blog, you probably know my passion for <a href="http://winnipegagilist.blogspot.ca/2012/01/silent-brainstorming.html">silent brainstorming</a>. <a href="http://www.slideshare.net/SteveRogalsky/the-silence-of-agile">Generating in silence and discussing out loud</a> isn't just a great way to get more ideas on the table, it is also a fantastic way to make sure every voice is heard. We've all been at retrospectives where one or more people with loud voices carry the conversation and the ideas. That isn't fun and doesn't encourage a positive atmosphere.<br />
<br />
<b>4. Build up Trust </b><br />
<br />
Using the 3 things above have shown themselves to be important in building up trust but sometimes you need to go a little farther. With new teams I've found that walking through <a href="http://www.retrospectives.com/pages/retroPrimeDirective.html">Norm Kerth's prime directive</a> can be a helpful way to eliminate blame from the discssion. They don't even have to believe the prime directive is true, they just have to act as if it is true for the period of the retrospective. I have found this pattern to be important to building up trust over time.<br />
<br />
<b>5. Do the (small) change</b><br />
<br />
Finally, the point of all of this is to find ways to improve. If your team is having positive discussions about change and then doesn't follow through, the retrospectives become a waste of time. One simple way to make sure the change happens is to put the action items into your backlog and then start off the next retrospective by reviewing them to see if they were done and if they were helpful. <br />
<br />
All the best in making your retrospectives more powerful by making them a positive experience. Feel free to add your tips in the comments.<br />
<br />
<i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i> Steve Rogalskyhttp://www.blogger.com/profile/06799015247942648718noreply@blogger.com3tag:blogger.com,1999:blog-7903227215035313444.post-44356166295497126482013-06-02T17:10:00.001-05:002015-03-26T10:17:45.930-05:00Don't Etch your User Story Map in Stone<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoNMbT-BCGprbGT1L9fm51gkrnofk31rifsaYxoJNVNLk46vltWrK9RefV21NtxEJfXGktp_-pnord1O_PPVyMHG2p5dU8YFgmErYqso4j323Jm8zn74AoA1jOcWv6MjlcsT2w6YW95Sjr/s1600/KentBeck.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoNMbT-BCGprbGT1L9fm51gkrnofk31rifsaYxoJNVNLk46vltWrK9RefV21NtxEJfXGktp_-pnord1O_PPVyMHG2p5dU8YFgmErYqso4j323Jm8zn74AoA1jOcWv6MjlcsT2w6YW95Sjr/s200/KentBeck.png" height="128" width="200" /></a>I was having a chat with <a href="http://contextdrivenagility.com/">Adam Yuret</a> last week about user story maps. A concern that he expressed and others have voiced is that by putting your ideas into a user story map it might discourage you from changing the map as you start delivering the stories and learn more information. He's right - it might and it probably does. Kent Beck recently expressed a similar concern about product roadmaps on twitter.<br />
<br />
<div class="separator" style="clear: both; text-align: left;">
<span style="align: left; background-color: #eeeeee; clear: right; float: right; margin-bottom: 1em; margin-left: 1em; padding: 10px;">
<b>User Story Mapping Series</b>
<br /><br />
* <a href="http://winnipegagilist.blogspot.ca/2012/03/how-to-create-user-story-map.html">How to Create a User Story Map</a><br />
* <a href="http://winnipegagilist.blogspot.com/2013/02/how-to-prioritize-user-story-map.html">How to Prioritize a User Story Map</a><br />
* <a href="http://winnipegagilist.blogspot.com/2012/12/tips-for-facilitating-user-story.html">Tips for Facilitating a User Story Mapping Session</a><br />
* Don't Etch your User Story Map in Stone<br />
* <a href="http://winnipegagilist.blogspot.ca/2014/09/user-story-mapping-tool-review.html">User Story Mapping Tool Review – SmartViewApp</a><br />
* <a href="http://winnipegagilist.blogspot.ca/2014/11/story-maps-testing-tool-after-all.html">Story Maps - A Testing Tool After All</a></span></div>
So, here is your reminder that your map isn't just a list of features, but is really a list of unvalidated ideas. Whether you are working on a startup or an enterprise project, you begin with a list of questions or assumptions. Here are some examples: <br />
<ul>
<li>Will anyone use it?</li>
<li>Will anyone pay?</li>
<li>Does anyone care?</li>
<li>How will we make $?</li>
<li>Can we build it?</li>
<li>Do we understand the problem?</li>
<li>Will this solve the problem?</li>
<li>Will it perform adequately?</li>
<li>Will it integrate with other applications successfully?</li>
<li>Can we build this with the budget & schedule we have?</li>
<li>What is the best architecture for this project?</li>
</ul>
<br />
When you build and prioritize your map, you should be doing so with these questions in mind. As you resolve each of those questions, your map should change. It is one of the great reasons to put your map on the wall using post-it notes instead of putting the map into a tool - post-it notes are easy (and fun) to move. <i>(Aside: Yes, there are sometimes excellent reasons to put things into a tool.)</i><br />
<br />
Two quick stories to illustrate:<br />
<br />
<div>
At a recent <a href="http://agilewinnipegiteration21.eventbrite.com/">Agile Winnipeg</a> event a local company (<a href="http://www.unionware.com/">UnionWare</a>) told a story of how they are using story maps. They had an idea for a project and quickly built a story map around that idea. At their customer conference they reviewed their ideas and realized they had missed the mark. They quickly (and easily) adjusted their map to confirm with their customers the new priorities and direction before they had even started building anything. The map itself was enough to help them walk through some of the questions above. As they told this story, their CEO recounted how he thought to himself: "This visualization stuff, it's going to be good."<br />
<br /></div>
<div>
</div>
<div>
For a project that I worked on this year we built a large map outlining all of the stories. We spent time going through the map with our customers slicing, scoping, prioritizing, identifying risks and assumptions, etc. We were pretty proud of the result and eagerly started delivering. As we started working on the first small release, we quickly realized that the answer to one of the main questions "Can we build this with the budget & schedule we have?" was "no". At this point, we had conversations with our users and sliced, scoped, and prioritized even more so that we could deliver something that would still meet the goals of our upcoming deadline.</div>
<div>
</div>
<div>
</div>
<div>
<br />
In summary, "You cannot plan the future. Only presumptuous fools plan. The wise man steers." - Terry Pratchet. Don't etch your user story map in stone - build it with paper and expect to change it as you learn. <br />
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://imgur.com/RoGSIPX" style="margin-left: 1em; margin-right: 1em;"><img src="http://i.imgur.com/RoGSIPX.jpg?1" height="188" title="Hosted by imgur.com" width="320" /></a></div>
<div>
<br /></div>
<div style="text-align: right;">
<i><i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i></i></div>
<div>
<div style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: Tahoma; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;">
</div>
<br />
<div style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: Tahoma; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;">
</div>
</div>
Steve Rogalskyhttp://www.blogger.com/profile/06799015247942648718noreply@blogger.com0tag:blogger.com,1999:blog-7903227215035313444.post-5154648144616682152013-05-12T10:54:00.000-05:002013-05-15T23:17:10.805-05:00Visualizing Retrospective Priorities<div>
We tried a new retrospective prioritization/voting technique this week that worked really well. After we had <a href="http://winnipegagilist.blogspot.com/2010/11/agile-retrospectives-rising-patton.html">generated and discussed all of our ideas</a> for improvement, it was clear to me that there were several excellent ideas and it would be hard to use our regular voting technique to single out one or two. In fact, it seemed clear that there were several ideas that should all be done and were somewhat related. I decided to try a technique in order to visualize the priorities, grouping, and weighting of the ideas.</div>
<div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkLNxBF6tsn_IAzbcmiAVZyXYzD-fiMaPy7hnURtjLGSaqa7NtJqBmbnaSvZBxblVjVhrt-nJjOlzxjCiZm6UcvV_ofoThb-u4ZsbjddR5kJyeShF-CMJql58cS7thRbIA0bdGR5Yi29R4/s1600/RetrospectivePrioritizeLine.Skitch..jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="239" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkLNxBF6tsn_IAzbcmiAVZyXYzD-fiMaPy7hnURtjLGSaqa7NtJqBmbnaSvZBxblVjVhrt-nJjOlzxjCiZm6UcvV_ofoThb-u4ZsbjddR5kJyeShF-CMJql58cS7thRbIA0bdGR5Yi29R4/s320/RetrospectivePrioritizeLine.Skitch..jpg" width="320" /></a></div>
I drew a line on the whiteboard from the bottom right to the top left and put all the ideas we had generated in the middle of the board. I then asked the team to approach the board and move the items they believed would have the most impact to the top left and the least impact to the bottom right. Yes, I was a little worried about the <a href="http://winnipegagilist.blogspot.com/2013/05/q-why-silence-priming.html">priming effect</a> of having everyone voting together but I decided to ignore my own advice this time.</div>
<div>
<br clear="none" /></div>
<div>
After the post-it notes on the board 'settled into position', we held another brief discussion to confirm the position of the ideas. It was clear that there were several high impact ideas on the board that needed to be implemented right away and some interesting clusters formed at the top left. The position of the post-it notes also visibly identified the ideas that the team thought would have a lower impact and could be dealt with another time.<br />
</div>
<div>
</div>
<div>
The final confirmation that this visualization of priorities was effective came later that day - the team met and started implementing their ideas.</div>
<div>
<br clear="none" /></div>
<div>
<i>P.S. Yet again the 'take it to the team' approach resulted in a better solution than the ones I had envisioned prior to the retrospective. #TeamGenius</i></div>
<br />
<br />
<div style="text-align: right;">
<i><i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i></i></div>
Steve Rogalskyhttp://www.blogger.com/profile/06799015247942648718noreply@blogger.com0tag:blogger.com,1999:blog-7903227215035313444.post-45386921221721489582013-05-04T11:30:00.001-05:002015-03-26T09:55:56.154-05:00Q: Why Silence? A: Priming.I'm a big fan of using silent brainstorming in order to generate ideas as individuals before processing those ideas as a group. "Priming" is yet another reason why using silence is important.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjeaUjdONSxdebPFWHuJEhStu-ZLFaXy-sPNFNQ5shMsfW8f19m72ZqvGAaM5cFz_QWd-GzXM7YpUQiUFaiOpUlxR0ovkV5AH9wK0bhtLcRsMtqar02CtdxciZ5a4C6fplj2xswBqJAjtrh/s1600/ThingOneThingTwo.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjeaUjdONSxdebPFWHuJEhStu-ZLFaXy-sPNFNQ5shMsfW8f19m72ZqvGAaM5cFz_QWd-GzXM7YpUQiUFaiOpUlxR0ovkV5AH9wK0bhtLcRsMtqar02CtdxciZ5a4C6fplj2xswBqJAjtrh/s320/ThingOneThingTwo.jpg" height="211" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">System 1 & System 2.<br />
(Not to be confused with Thing 1 and Thing 2)</td></tr>
</tbody></table>
I'm currently reading Daniel Kahneman's book "<a href="http://www.amazon.ca/Thinking-Fast-Slow-Daniel-Kahneman/dp/0385676514">Thinking, Fast and Slow</a>" - a behavioural psychology and economics book that describes his research on how our mind thinks. In the book, Kahneman describes the two systems that make up how we think. System one is the unconscious, fast, intuitive, relational thinker. System two is the conscious, slower, lazier, and more logical thinker. For example, when I ask you what 2+2 is, system one jumps in and gives you the answer of 4. When I ask you what 453 * 23 is, system two jumps in to help you calculate the answer.<br />
<br />
One of the experiments that Kahneman describes demonstrates how you can 'prime' system one and influence its answers. The experiment asked people to look at one word and then fill in the blank in a subsequent incomplete word. The first word they were shown was either "Eat" or "Wash" and the second incomplete word was "So_p". When shown "Eat", system one's relational thinking kicked in and people more often said "Soup" for the second word. On the other hand, when shown "Wash", system one more often produced the related word "Soap". Showing the first word to the participants 'primed' system one and influenced it to think of a second word that was related to the first.<br />
<br />
So, if you start a brainstorming meeting with "What can we do better? My idea is [X].", you have now primed people to think about [X]. However, if you let people generate ideas on their own first you will start with a larger base of ideas to work with. Once people have written down their own ideas [X,Y,Z], saying those ideas out loud will allow system one to find relational words on the whole set rather than just one idea.<br />
<br />
Generate ideas in silence, process the ideas out loud.<br />
<br />
<b>References:</b><br />
- Daniel Kahneman's Book: <a href="http://www.amazon.ca/Thinking-Fast-Slow-Daniel-Kahneman/dp/0385676514">Thinking, Fast and Slow</a><br />
- <a href="http://www.slideshare.net/SteveRogalsky/the-silence-of-agile">Slides </a>and <a href="http://www.infoq.com/presentations/Silent-Brainstorming">video</a> from my related talk: The Silence of Agile<br />
<br />
<div style="text-align: right;">
<i><i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i></i></div>
Anonymoushttp://www.blogger.com/profile/13339165557417141875noreply@blogger.com0tag:blogger.com,1999:blog-7903227215035313444.post-56121898802953715612013-04-21T18:12:00.001-05:002015-03-26T09:56:44.025-05:00Facilitating a retrospective with 50 people in an hourAs one of the volunteers at <a href="http://agile2012.agilealliance.org/">Agile 2012</a> I was honoured to be asked to facilitate the volunteer retrospective. <br />
<br />
There were a few constraints that made this retrospective challenging. First, due to our volunteer responsibilities we had just under an hour to eat lunch and complete the retrospective. Second, there are about 50 volunteers - allowing everyone to have a voice in such a short time frame would be a challenge. Third, it was important to all of us to celebrate the things that went well and also give a clear, prioritized list of ideas to future volunteer teams.<br />
<br />
After discussing the constraints and various facilitation options with some of you, here is what we did:<br />
<br />
1. Instead of building a timeline of our experiences we held the retrospective in our volunteer room. Throughout the week we had plastered the walls with our schedules (including happy/sad faces), guidelines, issues, ideas for improvement, etc which then served as visual provocations for the retrospective.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbolZDYLGjHCO-o4n3PH0YHgjSHxw7HL3xak5eVTyF7q235-ls9KlSTmzzWIrprYjAAfn7XUtovLSEi81R88Rvf80fP2BmUbEiRpAIi4yguGin0wjAq8Lrh4D8fvmdnrHVDNl-vtJUV8Uf/s1600/AgVolRetrospective.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbolZDYLGjHCO-o4n3PH0YHgjSHxw7HL3xak5eVTyF7q235-ls9KlSTmzzWIrprYjAAfn7XUtovLSEi81R88Rvf80fP2BmUbEiRpAIi4yguGin0wjAq8Lrh4D8fvmdnrHVDNl-vtJUV8Uf/s400/AgVolRetrospective.jpg" height="300" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Picture courtesy of Adam Yuret</td></tr>
</tbody></table>
2. We used silent brainstorming liberally in order to speed up the retrospective while still including every voice. In general we followed the <a href="http://winnipegagilist.blogspot.ca/2010/11/agile-retrospectives-rising-patton.html">Rising Patton Fusion</a> retrospective model that combines silent brainstorming, silent grouping, and silent voting. <br />
<br />
3. We split into 5 groups of 10. Each group would perform a retrospective step together before sharing their results with the larger group.<br />
<br />
4. The two major prompts we used in the retrospective were:<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjv3K1-hfwci7G9g2n4AFv1jIhFfR6UgA4eXwMjS1pZ-knQ4GoAYmwi7gmNvH1pc71GzOshQ0w7u9ZG0cqr7KFXlk77AjtVoQEdirWSEgebwqNq9lvinUOGHRwkCtz3fpBd6Lv_Ph3op-8y/s1600/ItWasGreatBecause.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjv3K1-hfwci7G9g2n4AFv1jIhFfR6UgA4eXwMjS1pZ-knQ4GoAYmwi7gmNvH1pc71GzOshQ0w7u9ZG0cqr7KFXlk77AjtVoQEdirWSEgebwqNq9lvinUOGHRwkCtz3fpBd6Lv_Ph3op-8y/s320/ItWasGreatBecause.jpg" height="320" width="239" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The combined 'greats'</td><td class="tr-caption" style="text-align: center;"><br /></td></tr>
</tbody></table>
- <b>"It was great because..."</b>. Each table wrote these in silence, read them out loud to each other, grouped them in silence and then named the groups. The named groups were then shared with the rest of the tables and consolidated into one larger list.<br />
- <b>"Do differently"</b>. Once again, each table wrote these in silence, read them out loud to each other, and then voted in silence. The top 3 items from each table were again shared with the rest of the tables and consolidated into one larger list.<br />
<br />
5. Finally, we posted pictures of all the results (yes, every single post-it note) on the Agile Conference Volunteers Facebook page for later reference and comments.<br />
<br />
It was a lot of fun and seemed to work well given the constraints. We achieved our goal of giving everyone a voice in a short time period, celebrating what went well, and also producing a nice list of actionable ideas for next year. Anything you would do differently?<br />
<br />
<div style="text-align: right;">
<i><i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i></i></div>
Anonymoushttp://www.blogger.com/profile/13339165557417141875noreply@blogger.com0tag:blogger.com,1999:blog-7903227215035313444.post-35748303167523739492013-04-06T15:58:00.002-05:002013-04-06T18:05:58.930-05:00In pursuit of better, not bestI realize that many of you already scowl when you hear anyone talk about 'best practices'. Instead of adding to that discussion, I'd like to share a short story with you about someone who influenced me to keep looking for better and to never assume that I've reached 'best.'<br />
<br />
I can still picture Mr. Loewen leaning on the desk at the front of my grade 9 class and settling in for a speech. The tone of his voice and even his posture indicated that what he was going to say was important. I think I expected a lecture on the importance of the subject, paying attention in class, working hard at the assignments, or being respectful to the teacher. Or maybe he was going to give his 'outstanding student' joke - students who crossed the line would end up 'out standing in the hallway'. Instead, he confessed to us. He confessed that he didn't know it all. Of course I can't remember the exact words, but it went something like this:<br />
<blockquote class="tr_bq">
"In this course I'm going to teach you what I know to the best of my ability. I'm going to tell you truths as I understand them today. But, someday you will encounter ideas and truths that might make more sense than what I have taught you in this course. You will discover that some of what I have taught you is wrong. When you encounter those ideas, embrace them. And even as you embrace those new truths, remember that you, also, might be wrong again."</blockquote>
Those words sat with me for a long time before I saw the wisdom in them and embraced them. They have served me well and taken me through some challenging times. Thanks Mr. Loewen.<br />
<br />
<div style="text-align: right;">
<i><i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i></i></div>
Anonymoushttp://www.blogger.com/profile/13339165557417141875noreply@blogger.com0tag:blogger.com,1999:blog-7903227215035313444.post-67402439210074093172013-03-24T16:42:00.001-05:002015-03-26T10:17:30.987-05:00Thoughts on Beyond Deadlines by Jabe Bloom<b>Background</b> <br />
<br />
In late 2012 when <a href="http://www.geekswithblogs.net/optikal">Dylan Smith</a> suggested a <a href="http://winnipegagilist.blogspot.ca/2012/11/blog-challenge.html">blog challenge</a> in order to encourage each of us to write more often, I quickly agreed. I don't find it easy to write but I love the thought process that goes into it and I was hopeful that some extrinsic motivation ($ and deadlines) would help me write more often. I'm still in the competition as long as I finish this post by midnight tonight so it looks like extrinsic motivation is "working" in this case.<br />
<br />
And yet, as a proponent of flow in personal and work habits I find that deadlines sometimes seem to be the wrong focus. If we can prioritize and visualize our work effectively then we should always be working on the most important items - regardless of deadlines. Even if some of our items have legitimate deadlines we should be able to add that to our prioritization criteria. If you have ever played the <a href="http://getkanban.com/">getKanban </a>game, their inclusion of Fixed Delivery Date cards for auditing deadlines illustrates one way to do this.<br />
<br />
<b>Beyond Deadlines by Jabe Bloom</b><br />
<br />
I met <a href="http://blog.jabebloom.com/">Jabe </a>and some of his co-workers at <a href="http://www.tlclabs.co/">TLCLabs </a>last year at various conferences. What makes them unique in my mind is that they courageously try out agile and lean ideas within their company. So when <a href="http://contextdrivenagility.com/">Adam Yuret</a> sent along a link to Jabe's presentation "<a href="http://vimeo.com/52255565">Beyond Deadlines</a>" with the text "TLC spent a year telling employees not to set deadlines. We wanted to know, can you run a business without Deadlines?" - I was eager to watch.<br />
<br />
Here are the notes I took from the video:<br />
<br />
<i>1. Deadlines as [temporary] extrinsic motivation</i><br />
Deadlines have their roots in motivating workers who were thought to need extrinsic motivation in order to avoid slacking off. Jabe contrasts this view with Deming's view that extrinsic motivation (deadlines, fear, money, etc) can actually rob us of our intrinsic motivation. I did a quick search on Psychology Today and found agreement on this point - <a href="http://www.psychologytoday.com/blog/making-change/201003/how-deadlines-can-be-murder-motivation">"External motivation, while sometimes helpful, can also undermine intrinsic motivation."</a><br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0EG6w6GZTc7c35E-XwGi0RHd5zVXnpEh21bVqVutWpc2YgisBquOZPGqm9_FyMuz83JjKZhgfHlH0VuclZipIg6RMZbIZZs9Z6UT_h5iUibT3gJ1noCW77jMp_E9NOq7eF3Yo65lOcOeE/s1600/DeadlinesAndCrap.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="286" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0EG6w6GZTc7c35E-XwGi0RHd5zVXnpEh21bVqVutWpc2YgisBquOZPGqm9_FyMuz83JjKZhgfHlH0VuclZipIg6RMZbIZZs9Z6UT_h5iUibT3gJ1noCW77jMp_E9NOq7eF3Yo65lOcOeE/s320/DeadlinesAndCrap.png" width="320" /></a>
<i>2. Deadlines as influencers of 'crap'</i><br />
Jabe credits <a href="http://www.personalkanban.com/pk/jim-benson/">Jim Benson</a> for the diagram at the right. Simply put - as your deadline approaches your options are reduced and you choose options to fit the deadline rather than satisfy your customer. As I've been watching March Madness this weekend the 35 second shot clock is a good reminder of this - as the shot clock approaches zero the players end up rushing their shots and miss at a higher frequency.<br />
<br />
<i>3. Deadlines are a lesser goal</i><br />
"We are kept from our
goal not by obstacles but by a clear path to a lesser goal" - Robert
Brault. Deadlines are clear goals - this may nudge you to make choices based on the deadline instead of customer need.<br />
<br />
<i>4. Deadlines are a measurement of our estimating accuracy</i><br />
Deadlines measure your estimating accuracy, not your project success. As the Buhler study from 1995 demonstrated, even with experience we are still inadequate estimators. If this is true then when we use deadlines we are increasing our rate of failure based on something that is potentially arbitrary.<br />
<br />
<i>5. Use the 5 Whys on your estimates</i><br />
Some deadlines are legitimate and Jabe talks about creating an ad for the Super Bowl game as one example. He recommends doing a <a href="http://en.wikipedia.org/wiki/5_Whys">5 Why</a> assessment on your deadlines to find the real reason. If the deadline is only there as a motivational tactic, then perhaps you have other better options.<br />
<br />
<i>6. Flow as an alternative to deadlines</i><br />
One of the advantages of kanban over iterations is that you don't run out of options for a particular item as it passes through your board. With time boxed iterations, as you approach the end of your iteration and haven't yet met your commitment, you start making choices that cause 'crap'. Flow enables multiple decision points which increases the options available to you and the satisfaction of your customer.<br />
<br />
<i>7. Their story</i><br />
Yes, they actively worked towards abolishing deadlines for a full year and made it. The video only goes into part of their story and I wish he had said a little more about this. However, from my conversations with them I understand it was a pretty big hit with both their employees and their customers. One of their employees stated: "For us, switching to kanban was great emotionally, because we don't have to fail every two weeks." From a customer stand point they changed their release cycle from 6 months (with a list of promised features) to 6 weeks (delivering whatever was ready). Their customers appreciated receiving updates more frequently and the opportunity to provide feedback on features more often. As a company, moving towards flow also enabled them to introduce 20% slack time ("do what you think you should do - you are the expert") which they believe increased their overall productivity. A side effect of abolishing deadlines is that it helped them to find their real (and few) deadlines.<br />
<br />
<b>In Closing</b><br />
<br />
Many of us use deadlines to motivate ourselves or our teams - they are easy to use and often seemingly effective. Given both the dangers and the alternatives as described by Jabe, I'm going to try to keep this tool in the bottom of my tool box. Please be patient with me if I give you a funny look when you ask me: "When can you have that done by?"<br />
<br />
To end this post I'd like to take you back to the blog challenge with our bi-weekly deadlines.One of the members of the challenge dropped out earlier this year. His reason? He felt the bi-weekly deadlines were influencing his content choices and quality. The deadlines were influencing him towards 'crap'.<br />
<br />
<b>Further Reading</b><br />
<ul>
<li><a href="http://vimeo.com/52255565">Beyond Deadlines</a> - Jabe Bloom</li>
<li><a href="http://www.psychologytoday.com/blog/making-change/201003/how-deadlines-can-be-murder-motivation">How Deadlines can be Murder on Motivation</a> - Psychology Today</li>
<li><a href="http://www.youtube.com/watch?v=u6XAPnuFjJc">The Surprising Truth about what Motivates us</a> - Dan Pink</li>
<li><a href="http://www.psychologytoday.com/blog/hollywood-the-couch/201203/deadline-dread">Deadline Dread</a> - Psychology Today</li>
</ul>
<div style="text-align: right;">
<i><i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i></i> </div>
<br />Anonymoushttp://www.blogger.com/profile/13339165557417141875noreply@blogger.com3tag:blogger.com,1999:blog-7903227215035313444.post-92028940086162629642013-03-10T09:00:00.000-05:002013-03-10T15:19:50.018-05:00It’s the system, not (and?) the people.I live and work with two phrases in my head that are important to me: <br />
<blockquote class="tr_bq">
“It’s the system, not the people” – Deming</blockquote>
And, paradoxically:<br />
<blockquote class="tr_bq">
“It’s all about the people” – a statement heard often at Protegra that we try to use to guide how we work together.</blockquote>
An event this weekend helped me to understand these seemingly contradictory ideas. My brother (as coach) and nephew (as player) are participating in the junior varsity (gr. 9/10) provincial basketball championships. Last night I was able to watch them play in the semi-finals and could see both of the quotes above at work.<br />
<br />
<b>“It’s the system, not the people”</b><br />
<br />
After an exciting victory by my nephew’s team, I overheard a conversation between two neutral parties as they did a postmortem on the game. In their assessment they agreed that both teams were skilled, gave it everything that they had, and played with passion. The main difference between the two teams was that the winning team had a better defensive system – not better players, but a better system. While the opposing coach did his best to exhort his players to play smarter, take better shots, make better passes, <a href="http://www.youtube.com/watch?v=L_2EFTQy_v0&list=PL8C5E14650A30D000&index=1">avoid the red beads</a>, and play harder defense, ultimately they were defeated by a better system. They didn’t lose this game because of “resources” (coaches, players and refs), they lost to a better system.<br />
<br />
<b>“It’s all about the people”</b><br />
<br />
Let’s look at the game from another angle. It was my brother the coach (a person) who researched, introduced, and taught the system to the team. It was the players (people) who bought into and committed to playing within the system. Both the offensive and defensive systems used by the team are well chosen and effective because they depend on teamwork and collaboration. Their systems require all of them to act together – if one person steps outside of the system it breaks down. The systems do not rely on one or two heroes but on the team as a whole. The systems require people to learn together, improve together, and be engaged together. The systems are all about the people. A pretty neat life lesson for a group of gr. 10 boys.<br />
<br />
So, yes “It’s the system, not the people”, and yes, “It’s all about the people.”<br />
<blockquote class="tr_bq">
“We believe it’s all about <b>people</b>. We believe by <b>systematically </b>focusing on <b>people</b>, treating them as the heart of organizational <b>systems</b>, that success will follow for all.” – <a href="http://www.protegra.com/">Protegra</a>.</blockquote>
<div style="text-align: right;">
<i><i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i></i> </div>
Anonymoushttp://www.blogger.com/profile/13339165557417141875noreply@blogger.com1tag:blogger.com,1999:blog-7903227215035313444.post-12896302746434917902013-02-24T16:25:00.002-06:002013-02-24T18:17:23.402-06:00San Jose Budget Games 2013<div>
<div style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: Tahoma; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;">
"Whatever is the problem, community is the answer" - <a href="http://www.margaretwheatley.com/">Margaret J. Weatley</a>.<br />
<br />
I've been reading some of Margaret's writings this week and her words have been ringing in my ears as I remember participating as a volunteer facilitator in the 3rd annual San Jose Budget Games on January 26. Somewhere close to 200 community leaders, politicians, city staff, and volunteer facilitators gathered to have conversations about the city budget priorities. This wasn't a typical town hall meeting where the city presents the budget priorities and community members gather at a microphone to voice their displeasure. Instead, 20 tables of 8-10 people gathered to play a version of <a href="http://innovationgames.com/buy-a-feature/">Buy a Feature</a> by Innovation Games. Through the game, each table was asked to wrestle with and agree on both where to spend the budget (more police? more library hours?) and whether or not to increase city revenues (increase sales tax? create a parcel tax?) to fund more initiatives. San Jose elected officials, police chief, fire chief, city clerks and others were available to answer any questions.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYSSc2F8_oEfrfH4-tM0lpV4z1D4QMOS-aeTsUT6Oah5gf5dVxLU00yg73bf1R_nUji7dRdpXpBKRt3ApKwmlZd2Wxc-pUiesoW3uaz6D1xN3GpGS4ujpi_6ClsblTL5ScnxXlMoLMTJgw/s1600/FullRoom.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYSSc2F8_oEfrfH4-tM0lpV4z1D4QMOS-aeTsUT6Oah5gf5dVxLU00yg73bf1R_nUji7dRdpXpBKRt3ApKwmlZd2Wxc-pUiesoW3uaz6D1xN3GpGS4ujpi_6ClsblTL5ScnxXlMoLMTJgw/s400/FullRoom.JPG" width="400" /></a></div>
<br />
As a facilitator it was interesting to watch a diverse group of people talk to each other about priorities for their city. Here are a few observations that I found interesting:<br />
<ul>
<li>Though they didn't always agree, the game produced some great discussions.</li>
<li>Disagreements at our table ended with increased understanding.</li>
<li>The discussions were neighbour to neighbour vs. citizen to politician.</li>
<li>I heard citizens talking positively about their city politicians ("I don't always agree with them, but I like their approach - they are serious about engaging us in helping making the city better").</li>
<li>Many citizens were playing the game a second or third time - asking a community for help and then acting on their responses creates engagement and joint commitment.</li>
<li>Relationships were built rather than fractured ... at a budget meeting!</li>
<li>This approach to solving problems can create a better community, neighourhood, team, company, city, etc. </li>
</ul>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbQSU7OP4IR5lq9DrMY4uJ9Jyhf4BBbbAreW_N4FGwiBsRvfoll4qGZH6jiOPZeYeUtp4L8cKk2KdPrviTzg7kRcOzG48WJaqBMtApUQegldU8dOfSKi7ZV2K9ZHIwzm-eQqA1rIK1AFZr/s1600/OurTable.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbQSU7OP4IR5lq9DrMY4uJ9Jyhf4BBbbAreW_N4FGwiBsRvfoll4qGZH6jiOPZeYeUtp4L8cKk2KdPrviTzg7kRcOzG48WJaqBMtApUQegldU8dOfSKi7ZV2K9ZHIwzm-eQqA1rIK1AFZr/s400/OurTable.JPG" width="400" /></a></div>
<br /></div>
<div style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: Tahoma; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;">
San Jose isn't the only group to start embracing a community approach to problem solving. I'm sure if you reflect on your own experiences you'll recall examples of community approaches producing excellent results. Wheatley describes several similar examples in her article "<a href="http://www.hesselbeininstitute.org/knowledgecenter/journal.aspx?ArticleID=887">It's Time for the Heroes to Go Home</a>" and in the agile community we've embraced this approach through self organizing teams and frequent retrospectives.<br />
<br />
I don't know if I'll be able to participate in a future budget game, but I'll always be grateful to the city of San Jose and the <a href="http://everyvoiceengaged.org/">Every Voice Engaged</a> foundation (the non-profit arm of Innovation Games) for the opportunity to be involved this year. If we ever do this in Winnipeg, count me in.<br />
<br />
Finally, along with this reminder to 'take it to the team', here are a few practical methods you can use to do so:<br />
<ul>
<li><a href="http://innovationgames.com/">Innovation Games</a></li>
<li><a href="http://www.theworldcafe.com/method.html">World Cafe</a></li>
<li><a href="http://winnipegagilist.blogspot.ca/2010/11/agile-retrospectives-rising-patton.html">Retrospectives</a></li>
<li><a href="http://leancoffee.org/">Lean Coffee</a></li>
</ul>
<br />
<i> </i>(You can read more about the budget games in the <a href="http://igsummit.weebly.com/budget-games.html">Financial Times</a> and <a href="http://www.businessweek.com/articles/2012-08-30/making-sense-of-the-games-politicians-play">Bloomsberg Business Week</a>)</div>
<div style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: Tahoma; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;">
<br />
<div style="text-align: right;">
<i><i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i> </i></div>
</div>
<div style="-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; color: black; font-family: Tahoma; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;">
</div>
</div>
Anonymoushttp://www.blogger.com/profile/13339165557417141875noreply@blogger.com0tag:blogger.com,1999:blog-7903227215035313444.post-69458402651309482322013-02-08T16:46:00.001-06:002015-03-26T10:19:50.836-05:00How to Prioritize a User Story MapAt the Agile 2012 conference, Serena Software surveyed attendees about their <a href="http://www.serena.com/docs/repository/alm-benchmark/Serena-Agile-2012-Survey-Infographic.pdf">biggest agile challenge</a>. Here was the top answer:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.serena.com/docs/repository/alm-benchmark/Serena-Agile-2012-Survey-Infographic.pdf" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi84f57R0DuayEo8NscZaSS6Q-CaRz6aUHbfo1COYJsrRoN2I0X-XFpWTfHUp8qLm5XJfpP0m-T8MZx-Wtdd2u_SMHi_6LEK_0GQ5tqONDgZqukka6nqs8nGHY4bPU_edHVNq7MrwIfPnkJ/s400/SerenaPriorities.png" height="70" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="align: left; background-color: #eeeeee; clear: right; float: right; margin-bottom: 1em; margin-left: 1em; padding: 10px;">
<b>User Story Mapping Series</b>
<br /><br />
* <a href="http://winnipegagilist.blogspot.ca/2012/03/how-to-create-user-story-map.html">How to Create a User Story Map</a><br />
* How to Prioritize a User Story Map<br />
* <a href="http://winnipegagilist.blogspot.ca/2012/12/tips-for-facilitating-user-story.html">Tips for Facilitating a User Story Mapping Session</a><br />
* <a href="http://winnipegagilist.blogspot.ca/2013/06/dont-etch-your-user-story-map-in-stone.html">Don't Etch your User Story Map in Stone</a><br />
* <a href="http://winnipegagilist.blogspot.ca/2014/09/user-story-mapping-tool-review.html">User Story Mapping Tool Review – SmartViewApp</a><br />
* <a href="http://winnipegagilist.blogspot.ca/2014/11/story-maps-testing-tool-after-all.html">Story Maps - A Testing Tool After All</a>
</span></div>
I don't know how accurate their results are but prioritizing customer demand was certainly a challenge for me on my first "agile" project. We created a backlog with some pretty large user stories including "Search for items", "Maintain item attributes", "Set costs for items and groups", "Calculate prices", "Run pricing engine", etc. We then proceeded to tackle each story in order (that's what you do right?). After our first five week iteration (!!) we had created the most beautiful search screens you could possibly imagine. Our users could search by any and all combination of attributes and display the results in multiple different ways - there was even a brilliantly developed screen splitter so you could see all the extra details of one horizontal row in a vertical list at the right of the search results. We were so good that we finished our iteration commitment early and started to add in some of the nice-to-have search functionality. In truth, we were quite thrilled with our results. It was only in later iterations that the pit in our stomachs started to grow. While "Search for items" fit nicely into an iteration, "Maintain item attributes" had a tougher time and by the end we had lost all hope for "Run pricing engine". We had incredible search functionality (low priority) and sub par costing and pricing (high priority). Oops.<br />
<br />
<b>Thin slicing to the rescue!</b><br />
<br />
It is no wonder that when Jeff Patton showed me <a href="http://winnipegagilist.blogspot.ca/2012/03/how-to-create-user-story-map.html">how to create a user story map</a> and use it to create thin application slices to prioritize agile projects effectively that I was hooked. It should also come as no surprise to you that in subsequent projects when "search" comes up as a feature request I am the first one to slice that story ruthlessly! "Search for items" is immediately sliced thinly to "Search by item number" and put in the first release. The rest of the search functionality is sliced into similarly sized user stories ("Search by description", "Search by customer item number", "Search by vendor", etc) and initially moved to the bottom of the story map.<br />
<br />
Then we continue to slice each column in our user story map so that we can build a thin horizontal slice of our app in a short period of time (days or weeks). "Enter member, spouse, and dependent information" is sliced into "Enter member name" (first release), followed by "Enter member address", "Enter spouse information" and "Enter dependent information" in later releases of the application.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhirx1ifIJNtxlMrYIrS-P9t8bABtOC5suLFnSCnfJl9N5VFX6E7pm1BNjRaehJsP1FcvXgi_7T5DSLOAfyuzFVsZePdsdbPYyuxe7rqM5CEw-Jl4lYWnOoWAHNw1HKQZ1swKk_yYt_dbj6/s1600/UserStoryMapPriorities.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhirx1ifIJNtxlMrYIrS-P9t8bABtOC5suLFnSCnfJl9N5VFX6E7pm1BNjRaehJsP1FcvXgi_7T5DSLOAfyuzFVsZePdsdbPYyuxe7rqM5CEw-Jl4lYWnOoWAHNw1HKQZ1swKk_yYt_dbj6/s400/UserStoryMapPriorities.png" height="291" width="400" /></a></div>
<br />
<br />
<b>Prioritizing by risk and assumptions</b><br />
<br />
Once you get the hang of ruthlessly slicing your stories and prioritizing them effectively in your map, you may notice a lot of 'easy' stories initially rise to the top of your priority list. In the case of "Search for items" this is a good thing. However, it can be dangerous to do all the easy stories first. When we've drafted our map and are ready to start prioritizing I like to ask - "Where are the risky stories? Where are our biggest assumptions?".<br />
<br />
In the project example above, "Run Pricing Engine" was our riskiest story. It had some really aggressive performance requirements and if we couldn't meet those requirements then there was no point in building the application. In this case, choosing the 'easiest' slice of that feature would be a mistake - we should look for a slice that helps us validate our assumption that we can meet the performance requirements. Additionally, subsequent releases should continue to focus on that assumption before we work on stories like "Search by vendor".<br />
<br />
<b>Applying Cynefin to prioritization</b><br />
<br />
This week I read an excellent article by <a href="http://lunivore.com/">Liz Keogh</a> called "<a href="http://lizkeogh.com/2012/03/11/cynefin-for-devs/">Cynefin for Developers</a>". The article is well written and can help us understand how to apply Cynefin to project prioritization. One of the domains in the Cynefin model is "Complex" which Liz describes as:<br />
<blockquote class="tr_bq">
"When you start writing tests, or having discussions, and the
requirements begin changing underneath you because of what you discover
as a result, that’s complex. You can look back at what you end up with
and understand that it’s much better, but you can’t come up with it to
start with, nor can you define what “better” will look like and try to
reach it. It emerges as you work."<br />
<br />
"... This is the land of high-feedback, risk and innovation: generally stuff
you’ve never done before, anything that the business are unsure about,
new technologies, etc."</blockquote>
As you are prioritizing your map, pay special attention to any stories that may fit into the Complex domain. Since these stories may change the direction of your project, I'd recommend that you tackle them earlier rather than later.<br />
<br />
<b>Re-prioritize often</b><br />
<br />
Remember that priorities can and should change throughout your project as you learn more information. On a recent project we had a few stories that were identified as 'mandatory' but the team agreed to prioritize them towards the end of the project. Near the mid point of the project we brought in some of our external customers for a small focus group. We did a quick demo of our progress to date and also asked them to help us prioritize the remaining stories. We quickly learned that some of the previously 'mandatory' stories were no longer important and removed them from our backlog. Without that feedback and the willingness to change priorities at any point of the project we would have contributed to the famous Standish Report phrase: "64% of features are rarely or never used".<br />
<br />
On a related note, if re-prioritization is going to happen frequently, then there isn't much point in prioritizing your whole map initially. A good rule of thumb is to prioritize the next one or two releases only. Even though prioritizing a story map can be a simple and fast exercise, it may be wasteful to slice and prioritize everything at the beginning.<br />
<br />
<b>In Summary</b><br />
<br />
My secret recipe for prioritizing agile projects is simply this: Roll out your user story map; add some thinly sliced stories; stir in some prioritization by risk, assumption, and complexity; rinse and repeat.<br />
<br />
<div style="text-align: right;">
<i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i> </div>
Anonymoushttp://www.blogger.com/profile/13339165557417141875noreply@blogger.com6tag:blogger.com,1999:blog-7903227215035313444.post-82758730240670312882013-01-27T00:23:00.001-06:002013-02-24T16:34:06.676-06:00Golden Nuggets from the Innovation Games SummitMy friend <a href="http://www.chadholdorf.com/">Chad Holdorf</a> describes golden nuggets as those practical things you learned from a conference that you can use on Monday at work. After attending the <a href="http://igsummit.weebly.com/">Innovation Games Summit</a> this week in Santa Clara here are six golden nuggets I'd like to share with you:<br />
<br />
1. Many of the attendees at my <a href="http://www.infoq.com/presentations/Silent-Brainstorming">Silence of Agile</a> talk were trained and experienced facilitators and during our discussions offered two specific tips that I plan on trying at one of our team's next retrospectives.<br />
<ul>
<li>The first tip was to change the voting so that people vote not only for their top 3 ideas but also their bottom 3. When tallying the results use the net votes (top minus bottom) as your top items to work on for that period. </li>
<li>The second tip involves changing the silent writing portion of the retrospective. Instead of writing each individual idea on one post-it, ask each team member to write all their ideas on one paper in a list format. Once everyone has written their list, pass it to the person on your left. Each person then reads their neighbour's list and adds to it. Keep passing the lists to the left until everyone has read and contributed to all the lists. Finally, put the individual items on your board and prioritize them as usual.</li>
</ul>
2. <a href="http://innovationgames.com/">Innovation Games</a> help you have better conversations and make better decisions. I had already experienced this myself when using these games for retrospectives. However it became even more explicit as we facilitated and observed the <a href="http://everyvoiceengaged.org/solutions/budget-games/">San Jose 2013 Budget Games</a>. We had a diverse group of community members at our table who had honest conversations and made tough decisions about topics that are important for San Jose. I can imagine that a great facilitator could also have achieved the same results, but the game did this without much need for facilitation. I'll be looking for more places to try out these games.<br />
<br />
3. As a facilitator, it is important to trust the Innovation Game and let the group create their own process and flow within the context of the game. <a href="http://www.gerrykirk.net/">Gerry Kirk</a> was my facilitation partner for the Budget Games and I watched (sometimes in trepidation) as he deftly used good questions to nudge the group along rather than directing the flow. Their process was sometimes a little scary as they tried to work within the game to come to decisions. However, in the end it was their process and their results. The game did its job to provide structure and Gerry's gentle questioning prodded them to a good result much more effectively than a directive approach would have.<br />
<br />
4. A new podcast source! Look for <a href="http://ecorner.stanford.edu/author/jack_dorsey">Jack Dorsey</a> and others on <a href="http://ecorner.stanford.edu/podcasts.html">Standford University's Entrepreneurship Corner</a>.<br />
<br />
5. A new book that was highly recommended by Mr. Holdorf: <a href="http://www.amazon.com/Radical-Leap-Re-Energized-Service-People/dp/161466014X">The Radical Leap Re-Energized</a> by Steve Farber.<br />
<br />
6. Two 'S's. These aren't agile tips, but useful nonetheless<br />
<ul>
<li>Have sinus trouble when flying? A client of mine recommended <a href="http://www.boironusa.com/products/sinusalia/">Sinusalia </a>by Boiron. Take two pills before you get on the plane and then every two hours during your flight - they are magical. </li>
<li>Need music for your training sessions, workout sessions, relaxing at home, etc? Try the <a href="http://songza.com/">Songza </a>app.
It has lots of curated music based on themes and also comes with a
pretty neat UX experience that suggests musical themes based on the time
of day.</li>
</ul>
<div style="text-align: right;">
<i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i> </div>
<ul>
</ul>
Anonymoushttp://www.blogger.com/profile/13339165557417141875noreply@blogger.com0tag:blogger.com,1999:blog-7903227215035313444.post-85566008113193580462013-01-12T10:40:00.000-06:002013-02-24T16:34:23.660-06:00Kanban At HomeAs Jen mentioned in the <a href="http://winnipegagilist.blogspot.ca/2013/01/living-with-agilist.html">previous post</a>, kanban has crept into our home. Here is a quick post to tell you how we build our board, how we use it, and the results.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzdzMRABqbBY1HJEBJHLeKE6DmcA61hskQQWHl7gy5DcfFIfUPcOOwW7xuH6qQepwoQ_vIMaDWp2EEbYTJrJVDuo4LujrAtifH8B0klpCeWs0Tj8BKHLorSmWvWEFPE5yppM6gGwFtj-Oa/s1600/DoingWIP.JPG" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="149" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzdzMRABqbBY1HJEBJHLeKE6DmcA61hskQQWHl7gy5DcfFIfUPcOOwW7xuH6qQepwoQ_vIMaDWp2EEbYTJrJVDuo4LujrAtifH8B0klpCeWs0Tj8BKHLorSmWvWEFPE5yppM6gGwFtj-Oa/s200/DoingWIP.JPG" width="200" /></a>While some families create a permanent board, we've found that temporary boards serve us well. If you stop by some Saturday morning you'll probably find us in the act of putting post-its on the mirror in our front entrance. It is true that occasionally our board is created in the kitchen or even sometimes the hallway, but the front entrance is currently our favourite location. We have three columns across the top - "Ready", "Doing / Work in Progress", and "Done". You can probably simplify the middle column name to "Doing" or "WIP" but our kids have decreed that we should use both terms.<br />
<br />
We populate the "Ready" column with everything we'd like to accomplish that weekend. We're careful to make sure the tasks are clear and not too big. For example, instead of "Clean the House", we create post-its for "Clean the Kitchen", "Vacuum the living room", etc. Our board will have a mix of post-its that are specific to one person ("C practice piano", "A practice drums", "M clean room", "Daddy pay master card") and cards with no names that anyone can grab ("Shovel the snow", "Organize the front closet"). More recently we've also started to add post-its for doing fun things together ("LEGO!", "Family Movie"). <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgvdLiEpGNQwHHBgrs4MrEjw3iFTelWk6WUYBIms_H79u0WkKGNu4TR4fu_RlboeL7wgDJgc2P-fm93TTvxd0QwjDlGevsAXpcfAejvoWOcPYR3jRzAm2tD0TtP8LJcdQstkQaz0RH6Ears/s1600/KanbanAtHome.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="297" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgvdLiEpGNQwHHBgrs4MrEjw3iFTelWk6WUYBIms_H79u0WkKGNu4TR4fu_RlboeL7wgDJgc2P-fm93TTvxd0QwjDlGevsAXpcfAejvoWOcPYR3jRzAm2tD0TtP8LJcdQstkQaz0RH6Ears/s400/KanbanAtHome.JPG" width="400" /></a></div>
Once the board is populated the process is quite simple. Everyone selects a post-it, moves it to the "Doing / Work in Progress" column and goes to work. Once they are done that task, they move it to "Done" and select another. By the end of the weekend, the post-its have made a large shift towards "Done" as seen above.<br />
<br />
For our family this board works because it is simple, transparent, and requires little to no 'management' (i.e. nagging). Once the board is populated each person has a clear view of their expectations and can make their own decisions about when to do chores and when to play. On most Saturdays our kids (ages 7, 9, 11) do their chores earlier in the day so that they can spend the rest of the day relaxing without worrying that more chores will be added to their list.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5RZy280O7W6973CcruTBttCYpDmAxT8Pwg5Mkn1WJWehoyOq2ikpt9i33QcpaMCuzQzYfAbWuLM2w7iuzCw4PSavzSkHhMq9beHxNPxe_s9_Pwq9qvpkXa6kO1SUo4qVdlYNHdFSIbFZo/s1600/CarHenge.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="149" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5RZy280O7W6973CcruTBttCYpDmAxT8Pwg5Mkn1WJWehoyOq2ikpt9i33QcpaMCuzQzYfAbWuLM2w7iuzCw4PSavzSkHhMq9beHxNPxe_s9_Pwq9qvpkXa6kO1SUo4qVdlYNHdFSIbFZo/s200/CarHenge.jpg" width="200" /></a></div>
A board we created this holiday season is a particularly great example of the peace that a board can bring in our household. We had just returned from a road trip through Nebraska (<a href="https://twitter.com/srogalsky/status/288495462477094912/photo/1">Car Henge!</a>), South Dakota (<a href="http://www.nps.gov/moru/index.htm">Rushmore</a> and <a href="http://www.nps.gov/jeca/index.htm">Jewel Cave</a>), Wyoming and North Dakota. The level of grumpiness as we unloaded all of our luggage from the van into the house was historic - we were all tired and the mood was tense. As we stood around the pile of luggage now clogging our front entrance we reluctantly decided to create our board. Among the post-its for "Laundry" and "Unpack Luggage" were reward post-its like "Sleep" and "Spend my $10 Claire's gift card". After agreeing to take care of all the chores before starting any of the reward post-its, we moved our post-its to the "Done" column in record time with zero nagging. In parallel, the spirit of our household moved from grumpy to peaceful with the same efficiency.<br />
<br />
Well, it's Saturday morning. I'm being beckoned...<br />
<br />
<div style="text-align: right;">
<i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i> </div>
Anonymoushttp://www.blogger.com/profile/13339165557417141875noreply@blogger.com2tag:blogger.com,1999:blog-7903227215035313444.post-48407000395442529532013-01-07T20:16:00.000-06:002015-03-26T10:17:45.935-05:00Living With an Agilist<div style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><span style="font-size: small;"><span style="color: black;"><i>(Editor's note: The following is a guest post by Jen Rogalsky)</i></span></span></span><br />
<span style="font-family: Calibri;"><span style="font-size: small;"><span style="color: black;"></span></span></span><br />
<span style="font-family: Calibri;"><span style="font-size: small;"><span style="color: black;">A couple of years ago Steve came home from work and announced, “Podcasts have changed my life.” My natural response was: “What? Podcasts? Not me, not our children, but podcasts?” He persisted with his original assertion. “Yes, podcasts. They’ve changed my life.”</span></span></span><br />
<span style="font-family: Calibri;"><span style="font-size: small;"><span style="color: black;"></span></span></span><br />
<span style="font-family: Calibri;"><span style="font-size: small;"><span style="color: black;">This was my first introduction to the fact that Steve, through podcasts, had begun to learn about something called agile, and his declaration of devotion seemed to leave me with a clear choice: learn a little about this new interest or be left behind by this obviously life changing discovery. We were not immediately friends, agile and I, and yet along with the post-it notes and sharpies that have overtaken my house, some agile practices and principles have slowly become part of my life. I don’t pretend to be an expert in their application in a business context, but as I stumble through trying to explain to someone who asks me “What does your husband do?” I often come out with some kind of statement explaining that agile is applicable in some way to almost everything and everyone. Quite a lofty statement, and obviously somewhat hyperbolic, yet my personal adoption of some agile ideas is a testament to a sliver of truth.</span></span></span></div>
<span style="font-size: small;"><span style="color: black;"><span style="font-family: Calibri;">So here are just a couple of examples of how agile practices have seeped through the cracks.</span></span></span><br />
<span style="color: black; font-family: Times New Roman; font-size: small;"></span><br />
<div style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><span style="font-size: small;"><span style="color: black;">I like to picture myself as quite a broad thinker, capable of pondering and producing on multiple platforms simultaneously, unhindered by the shackles of linear constraints. Okay, so, that may look somewhat unsystematic to the outside viewer. And, okay, that may occasionally result in many simultaneously started, yet unfinished (albeit very creative and useful) projects. As I’ve learned more about agile, however, I’ve become more convinced, although reluctantly, about the value of shorter loops. Just as risky as it may be in a professional setting to invest money and energy in a long arc with feedback and product only at its end, shorter loops have proven their value for me, as well. I churn less often, (although sometimes churn on purpose just to be rebellious, now that I actually understand it for what it is), actively seek frequent feedback from those involved or implicated by my task rather than wait until the end to ‘test’, and force myself to be more systematic at finishing one task before beginning another, fueled by the motivating sense of reward that can provide.</span></span></span></div>
<span style="font-family: Calibri;"><span style="font-size: small;"><span style="color: black;">My evolving relationship with kanban has been no less reluctant, and yet equally as relentless in slowly changing my practices. Steve introduced kanban into our household quietly, first making his own boards for house and renovation projects, then producing boards on the kitchen cupboards for when he was in charge of doing chores with the kids. I didn’t object as long as I wasn’t required to participate. “Let’s just do it already, instead of sitting around writing stuff out first!” was my usual response when invited to join the process. Steve’s gentle suggestion that he wasn’t born with the ability to help accomplish our common goals by subconsciously divining the detailed task list in my head wasn’t enough to convince me of kanban’s value. Once again, however, like the persistent drip of water on rock, my resistance has been futile. It began with observing the relative lack of nagging involved when he did chores with the kids. What a wonder to behold when they would eagerly race back to the board to move their sticky from “WIP” to “done.” Or to overhear them debating their preferences in referring to the middle column as “Work in Progress” vs “Doing.” Or to watch their ownership of the whole task process increase as they were given the opportunity to participate in the creation of the list and then freed to choose their own route through to getting all the stickies transferred over to “done.” And now, after a long, slippery slope, most of our Saturday mornings begin with the creation of a family kanban board on the mirror in the front hallway. We are careful to also include the fun and relaxing activities in the “ready” column, and we all share in the sense of satisfaction when, come Monday morning, the board is balanced quite differently toward “done.” kanban’s conquest to take over our house is almost complete, since I recently found a spare bulletin board that seems to be calling to me to be made into a personal kanban board. Oh, how the mighty have fallen.</span></span></span><br />
<span style="color: black; font-family: Times New Roman; font-size: small;"></span><br />
<div style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><span style="font-size: small;"><span style="color: black;"> Finally, Steve’s passion for all things agile has found its way to the very core of our most significant common project, by influencing the ways in which we parent our three girls. I often find myself thinking, “But isn’t this just common sense? Perhaps we are making these decisions because we’re so incredibly intuitive and such remarkable parents…” and yet I know that our thinking has been shaped by what we have learned about an agile approach to treating people in the workplace and applying these ideas to the little people we live with. A couple of deliberate parenting strategies have emerged. We deliberately try to assume our kids’ competence rather than treat them as inherently incompetent and in need of our micro-managing. We try to make expectations clear up front, but then encourage them to find their own route toward completion within the established boundaries. We’ve learned that feedback is most easily heard and adopted when offered immediately and within a conversation in which the kids are participants. And perhaps most significantly, we are trying to do whatever we can to help them develop what <a href="http://www.lindarising.org/">Linda Rising</a> calls an “<a href="http://www.agilealliance.org/resources/learning-center/keynote-the-power-of-an-agile-mindset/">Agile mindset</a>” rather than a “Fixed mindset.” I almost thought I heard angels singing when my daughter recently told me that she wished her friend would realize that “Life isn’t supposed to be easy! Challenges don’t mean you’re supposed to sit down and complain, just work harder and figure out how to get past them.” </span></span></span></div>
<span style="font-size: small;"><span style="color: black;"><span style="font-family: Calibri;">All right, then, if agile ideas can eventually help my kid say something like that, even once, then I guess podcasts have changed my life too.</span></span></span><br />
<br />
<div style="text-align: right;">
<span style="font-size: small;"><span style="color: black;"><span style="font-family: Calibri;"><i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i> </span></span></span></div>
Jenhttp://www.blogger.com/profile/15039573148175381771noreply@blogger.com3tag:blogger.com,1999:blog-7903227215035313444.post-50446118406366959642012-12-26T21:59:00.001-06:002015-03-26T10:17:45.944-05:00Tips for Facilitating a User Story Mapping Session<div class="separator" style="clear: both; text-align: left;">
<span style="align: left; background-color: #eeeeee; clear: right; float: right; margin-bottom: 1em; margin-left: 1em; padding: 10px;">
<b>User Story Mapping Series</b>
<br /><br />
* <a href="http://winnipegagilist.blogspot.ca/2012/03/how-to-create-user-story-map.html">How to Create a User Story Map</a><br />
* <a href="http://winnipegagilist.blogspot.com/2013/02/how-to-prioritize-user-story-map.html">How to Prioritize a User Story Map</a><br />
* Tips for Facilitating a User Story Mapping Session<br />
* <a href="http://winnipegagilist.blogspot.ca/2013/06/dont-etch-your-user-story-map-in-stone.html">Don't Etch your User Story Map in Stone</a><br />
* <a href="http://winnipegagilist.blogspot.ca/2014/09/user-story-mapping-tool-review.html">User Story Mapping Tool Review – SmartViewApp</a><br />
* <a href="http://winnipegagilist.blogspot.ca/2014/11/story-maps-testing-tool-after-all.html">Story Maps - A Testing Tool After All</a>
</span></div>
In an earlier post I described <a href="http://winnipegagilist.blogspot.ca/2012/03/how-to-create-user-story-map.html">how to create a user story map</a>. Here are a few additional tips that you might find helpful. <br />
<br />
<b>Tip #1. Silent Brainstorming isn't mandatory. </b><br />
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.<br />
<br />
<b>Tip #2. For your first map, reference the email map.</b> <br />
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:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEijFOK-D1-XR0gGaG3w64x6mPuvE_XjTqVZWLHIO3l8KAYkiQlORyY3h2xYl3sroaE1NcxCQzojEwsucUVc-pusjKid12lHIzWDXy6Q6gpmB142kg9wIodY3vXVAGlyeA4HaFbKSseTNX7q/s1600/USMFirstTwoRows.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEijFOK-D1-XR0gGaG3w64x6mPuvE_XjTqVZWLHIO3l8KAYkiQlORyY3h2xYl3sroaE1NcxCQzojEwsucUVc-pusjKid12lHIzWDXy6Q6gpmB142kg9wIodY3vXVAGlyeA4HaFbKSseTNX7q/s320/USMFirstTwoRows.png" height="92" width="320" /></a></div>
<br />
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").<br />
<br />
<b>Tip #3. Tear horizontally, not vertically</b><br />
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.<br />
<br />
<b>Tip #4. Big Post-its</b> <br />
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 <a href="http://www.post-it.com/wps/portal/3M/en_US/Post_It/Global/Products/Product-Catalog/~/Post-it-Easel-Pad-25-inch-x-30-inch-White-30-Sheets-Pad-6-Pads-Case?N=6405394&rt=rud">3M Easel pads</a> so that it can be transferred back to the team room.<br />
<br />
<b>Tip #5. Use name brand post-its </b><br />
Post-its made by 3M seem to stick longer than other brands.<i> </i><br />
<br />
<div style="text-align: right;">
<i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i></div>
Anonymoushttp://www.blogger.com/profile/13339165557417141875noreply@blogger.com4tag:blogger.com,1999:blog-7903227215035313444.post-40978541668151175042012-12-15T22:56:00.002-06:002015-03-26T10:10:19.507-05:00A Systems Thinking Alternative to Performance ReviewsI 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.<br />
<br />
<b>The concerns:</b><br />
<b> </b>
<br />
<a href="http://en.wikipedia.org/wiki/W._Edwards_Deming">W. Edwards Deming</a> 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.<br />
<br />
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?<br />
<br />
<b>The experiment:</b>
<br />
<br />
Note: At <a href="http://www.protegra.com/">Protegra </a>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:<br />
<br />
a) What are you proud of? <i>(Pull)</i><br />
b) What do you want to learn or improve this year? <i>(Pull)</i><br />
c) What part of our team's system is preventing you from doing your job better? What should we improve or change? <i>(Systems Thinking)</i><br />
d) How is the company enabling or inhibiting you from achieving your best? <i>(Systems Thinking)</i><br />
e) What do you need from me? How can I help? <i>(Pull)</i><br />
<br />
<b>The results:</b><br />
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
<b>Some final thoughts:</b><br />
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 <a href="http://tlclabs.co/index.php/2012/08/no-really-we-dont-do-forced-ranking-and-performance-reviews/">blog</a> 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.<br />
<br />
<b>System Thinking References</b><br />
- <a href="https://www.google.ca/#hl=en&sugexp=les%3B&gs_nf=3&gs_rn=1&gs_ri=hp&tok=OJg2g2ocwe3ed8axJ5Ry-w&cp=9&gs_id=y&xhr=t&q=deming%27s+85-15+rule&pf=p&tbo=d&output=search&sclient=psy-ab&oq=demings+8&gs_l=&pbx=1&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.&bvm=bv.1355325884,d.aWc&fp=1aea1f8e46c1f0ad&bpcl=39967673&biw=1440&bih=776">Demings 85/15 rule</a><br />
- <a href="http://www.youtube.com/watch?v=OqEeIG8aPPk">If Ackoff had given a Ted Talk</a> <br />
- <a href="http://quantumshifting.wordpress.com/2012/11/25/its-not-a-behavioural-problem-its-the-system/">It's not a behavioural problem its the system</a><br />
<br />
<b>Performance Review References </b><br />
- <a href="http://www.psychologytoday.com/blog/wired-success/201211/why-performance-reviews-dont-improve-performance">Why performance reviews don't improve performance</a><a href="http://www.psychologytoday.com/blog/wired-success/201211/why-performance-reviews-dont-improve-performance"></a><br />
- <a href="http://tlclabs.co/index.php/2012/08/no-really-we-dont-do-forced-ranking-and-performance-reviews/">Why we don't do forced ranking and performance reviews</a> - TLCLabs<br />
- <a href="http://www.youtube.com/watch?v=MSYlqx1Yvqk">The Elephant in the Room: Appraisals and Compensation</a> - Mary Poppendieck<br />
- <a href="http://online.wsj.com/article/SB122426318874844933.html">Get Rid of the Performance Review!</a> (and some info on Performance Previews) <br />
<br />
<i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i>Anonymoushttp://www.blogger.com/profile/13339165557417141875noreply@blogger.com6tag:blogger.com,1999:blog-7903227215035313444.post-2287274345164385022012-11-27T19:29:00.000-06:002015-03-26T10:01:59.066-05:00Blog Challenge!
Hello readers,<br />
<br />
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:<br />
<br />
Dylan Smith: <a href="http://www.geekswithblogs.net/optikal">http://www.geekswithblogs.net/optikal</a><br />
Tyler Doerkson: <a href="http://blog.tylerdoerksen.com/">http://blog.tylerdoerksen.com</a>
<br />
David Alpert: <a href="http://www.spinthemoose.com/">http://www.spinthemoose.com</a><br />
Dave White: <a href="http://www.agileramblings.com/">http://www.agileramblings.com</a><br />
Aaron Kowall: <a href="http://geekswithblogs.net/caffeinatedgeek/Default.aspx">http://geekswithblogs.net/caffeinatedgeek/Default.aspx</a> <br />
<br />
(P.S. No - this post doesn't count in the challenge)Anonymoushttp://www.blogger.com/profile/13339165557417141875noreply@blogger.com0tag:blogger.com,1999:blog-7903227215035313444.post-28881494766069828272012-11-27T19:20:00.000-06:002015-03-26T10:08:01.164-05:00Celebrate Failure? [Part 2]Earlier this year I wrote about <a href="http://winnipegagilist.blogspot.ca/2012/02/agiles-perspective-on-failure.html">Agile's perspective on failure</a>.
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 <a href="http://winnipegagilist.blogspot.ca/2012/11/celebrate-failure-part-1.html">first part of this series</a> 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.<br />
<br />
<b>Your attitude towards failure (and your organization's attitude) does matter.</b><br />
<br />
A group of researchers led by <a href="http://books.google.ca/books/about/Failure_construction_in_organizations.html?id=3JEeAQAAMAAJ&redir_esc=y">Joel Albert Kahn</a> 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?<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Interesting - Carol's research on individuals matches that of Kahn's research on organizations and teams.<br />
<br />
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!<br />
<br />
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:<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://cakewrecks.squarespace.com/home/2008/11/12/maximum-irony-has-now-been-achieved.html" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPSleqcxnhO4_ASLpdif0hfKVpkf76aKPoHSWhH_oNZDUwI6Dp87B0zgpiTkzBWi7QfQF4yR5YylUwj6fPkiNbrMxgoI_PyxgLgGsR5XTUVz-EtcXPL3KK01L3kBjkWkL3Rx9p_9WhirCO/s320/Fial.JPG" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Credit: <a href="http://cakewrecks.squarespace.com/home/2008/11/12/maximum-irony-has-now-been-achieved.html">www.cakewrecks.com</a></td></tr>
</tbody></table>
<b>Further Reading:</b><br />
- Linda's <a href="http://www.slideshare.net/agiledays/linda-rising-the-power-of-an-agile-mindset">presentation </a>on this topic<br />
- Linda's <a href="http://www.youtube.com/watch?v=W47rcJowx7k&list=PL1AC4FFCAEAC422FA&index=7&feature=plpp_video">keynote </a>from Much Ado About Agile<br />
- Carol's website: <a href="http://mindsetonline.com/">http://mindsetonline.com/</a><br />
- A short <a href="http://www.youtube.com/watch?v=TTXrV0_3UjY">video </a>of Carol describing the effects of praise on children<br />
<br />
<i><a href="http://feedburner.google.com/fb/a/mailverify?uri=WinnipegAgilist&amp;loc=en_US">Subscribe to Winnipeg Agilist by Email</a></i> <br />
<br />
<div style="background-color: #e0e0e0; color: #20124d;">
<i>You can get the full research from your neighbourhood PhD student but here are a few more details on the studies mentioned above:</i><br />
<br />
<b><a href="http://books.google.ca/books/about/Failure_construction_in_organizations.html?id=3JEeAQAAMAAJ&redir_esc=y">"Failure construction in organizations: Exploring the effects of failure norms - Kahn, Joel Albert, 1995, University of Michigan. School of Business Administration.</a> </b><br />
<br />
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."<br />
<br />
"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."</div>
Anonymoushttp://www.blogger.com/profile/13339165557417141875noreply@blogger.com0