Thursday, April 2, 2015

Commitment as a Facilitation Weapon?

I recently finished reading “Influence: The Psychology of Persuasion” by Cialdini. The six ‘weapons of influence’ 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.

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.

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.

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 Much Ado About Agile in 2010. She started the retrospective by reciting North Kerth’s Prime Directive 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.

So, whether you are trying to increase sales, or just set a positive tone for your next meeting, give the commitment principle a try.

Subscribe to Winnipeg Agilist by Email

Thursday, March 26, 2015

Acknowledgment as Motivation

Recently at Prairie Dev Con I gave a talk on #NoEstimates 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 Dan Pink's 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 'What Makes Us Feel Good About Our Work?' by Dan Ariely that provides another angle on motivating through acknowledgment.

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.

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.

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, "ignoring their performance is almost as bad as shredding it." 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:
  • Add regular checkpoints with your team members to thank them for some specific contribution.
  • In your regular team retrospectives, start by celebrating the great work you have done together.
  • Schedule time in your calendar to give positive feedback to your team on a regular basis.
  • Schedule in regular demos so that your team can show off how they are delivering value to actual customers
  • Pass on good feedback from your customers to the team.
  • Start using KUDO cards to acknowledge good work.
  • 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.

Thanks for reading - I appreciate it.

Subscribe to Winnipeg Agilist by Email

Wednesday, November 12, 2014

Story Maps - A Testing Tool After All

The following was recently published as a sidebar in Lisa Crispin and Janet Gregory's new book More Agile Testing. The book is full of great advice from the authors as well as other contributors. I encourage you to take a look.

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.

Testing What to Build

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.

Testing Application Slices

As Crispin and Gregory demonstrated in their first book Agile Testing, 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.

Visualizing testing slices in your map

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.

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.

Story Maps—A Testing Tool After All

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.

Subscribe to Winnipeg Agilist by Email

Saturday, September 20, 2014

User Story Mapping Tool Review – SmartViewApp

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 create story maps, 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.

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.

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 here.  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: 

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.

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.
IPad Version
Web Version
I was able to set this project up as a public project, so if you want to take a look for yourself, click here.  Note – this application is currently only available in ‘modern’ browsers, so you may need to download Chrome or FireFox.

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 here.

P.S. Need another reason to try this out? It calls us “people”, not “resources”. Thanks SmartView!

Wednesday, March 26, 2014

Personal Kanban, velocity, and replenishing the ready queue

I was asked this question recently about personal kanban:
"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."

"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?"

"Any thoughts on this would be appreciated."
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?"

1. How many cards can I do in time period <x>?

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.

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.

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 Jabe Bloom 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.

2. How many cards do I pull into WIP?

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.

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.

Hope this helps. If not, ask away!

P.S. For more on personal kanban, you can find the experts here: or read Matt Heusser’s recent article “Yesterday’s weather”

Subscribe to Winnipeg Agilist by Email