Iterative Development and User Story Slicing

You may have seen Jeff Patton's slides showing iterative vs. incremental development using the Mona Lisa as an example (slides are here, page 80, 81). Iterative development suggests that you build each feature from the ground up increasing the subjective quality of each feature with each user story that you implement. This method is important for allowing you and your team to narrow in on the final solution rather than designing and understanding it all up front. It also allows you to deliver a full featured application earlier and to use methods like trim the tail to optimize your available budget vs the value that the project is delivering.

Here is a quick discussion on Iterative vs Incremental development:

The diagram to the left shows how a project could be completed using Iterative or Incremental development. In both cases, iterations were used to develop the list of features, but in iterative development we build each feature up a slice at a time rather than a feature at a time. Some of the advantages of iterative development are that it:

• Allows you to validate your architecture and solution early
• Allows users to see and test the whole application early
• Minimizes the affects of change to a feature
• Ensures important stories are built first
• Elicits improved feedback on the whole application early
• Allows you to deliver your application early
• Discourages "gold plating"
• It partners nicely with user story mapping (turn the diagram upside down and you have your story map)

Some of the disadvantages are:

• Your code and design has to be change tolerant
• You have to be proficient at slicing your user stories
• You won't know the final solution at the beginning of the project

User story slicing is an important technique in iterative development, but what does this look like in practice? Using Jeff's Mona Lisa pictures as a pattern, I've created a few images that show how a feature like "Send Email" could be completed iteratively.

The first story slice is simply a form with little or no validation with text boxes To, Subject and Body with Send and Cancel buttons. When the user fills in the text boxes and clicks Send an e-mail is sent provided the e-mail addresses entered are correct. But, this e-mail has no extra features like support for HTML formats, RTF, attachments, e-mail priorities, etc. Once this story is implemented, the team will implement similar slices of each feature for Read Email, Create Appointment, View Calendar, Create Task, Edit Task, Create Contact, Edit Contact, etc in order to create a minimalist working model of the whole application.

The next slices of this particular feature would be to implement stories such as implementing Carbon Copy (CC) and taking e-mail addresses from your contact list. You can also see that the form has changed slightly - the Cancel button has been removed and the Send button has been moved to the top.

As we continue to iterate through this feature by adding story slices, the form takes additional shape, adding tool bars and tool bar items. At this point, the application may be finished enough to release to production and start earning revenue for the organization while we continue to add new features and use that revenue to help fund the remainder of the project.

A further release with more story slices implemented:

The final release:

Iterative development is an important tool in your agile toolbox to help your teams deliver early and adapt to change while keeping the project's end goals in mind. User story slicing is one of the important techniques you can use to help make this happen.

Want to receive future blog posts in your inbox? Enter your email address here.

For lunch - an agile story

The speaker list for PrairieDevCon 2011 was published today and I'm really looking forward to it. Some great speakers and talks are lined up and D'Arcy Lussier as always will arrange for some great food. But... let me tell you a story of what might have been at PrairieDevCon 2010.

In the spring of 2010, D'Arcy Lussier (the conference organizer) and I were talking about the conference and he confessed to me that he was trying to cut costs. We brainstormed some ideas and prioritized them using a risk assessment matrix. Just before D'Arcy brought out his MS Project gantt chart, I suggested a new idea - Why don't we make the food ourselves! Knowing my reputation as an accomplished food critic and noted chef, D'Arcy quickly agreed and called the hotel to cancel his lunch orders.

I took on the responsibility of planning the meal in advance; purchasing and delivering the ingredients from the finest markets in Regina. The morning of the first day of the conference, D'Arcy and I met in one of the unused conference rooms to prepare the meal. We knew that our gourmet Ham & Cheese sandwhiches would be a huge hit.

Here was our work break down structure (straight out of MS Project)

Task Name	Start	Finish
Setup 8 preparation tables	8:15am	8:30am
Open 100 loaves of bread	8:30am	8:40am
Layout individual bread slices on the tables	8:40am	9:10am
Spread gourmet mayonaise on the even slices of bread	9:10am	9:30am
Spread garlic butter on the odd slices of bread	9:30am	9:50am
Put smoked ham on top of the even slices of bread	9:50am	10:10am
Put Trappist Monk Cheese on top of the even slices of bread	10:10am	10:30am
Put 3 slices of pre-smoked bacon on top of the even slices of bread	10:30am	10:50am
Put Emerald Frizz lettuce on top of the even slices of bread	10:50am	11:10am
Put the odd slices of bread on top of the even slices of bread to create each sandwhich	11:10am	11:30am
Put a toothpick topped with an olive through the middle of each sandwhich	11:30am	11:50am
Test the sandwhiches	11:50am	12:00pm
Serve!	12:00pm	1:00pm

We proceeded and followed this plan to the tee (our project manager would have been proud!). As it turned out, our estimates were fantastic and we started the testing phase at exactly 11:50am. Both D'Arcy and I eagerly grabbed a sandwhich, took a few pictures to put on twitter and took a huge bite. It was... awful. It turns out that my mayonnaise supplier gave us some really rancid mayo. Each and every sandwhich was ruined.

Fortunately, when we sheepishly went to report this to the catering staff at the Delta, they kindly informed us that they were pretty sure we would fail and had prepared a wonderful lunch anyways. So, the attendees were spared, and D'Arcy and I graciously thanked the Delta for being such great hosts.

The lesson? If we wouldn't make lunch that way, why would we create software that way? Instead, shorten the distance between a possible problem and its resolution by frequently delivering working software and testing every day. First-Time-Right for the win.

Enjoy your lunch! Hope to see you at PrairieDevCon.

How to wrap a gift card (hint - it involves power tools)

Note: This post has nothing to do with agile, but hopefully it will add some excitement to your future gift card giving experiences.

This Christmas I was tasked with buying gifts for three of my nephews. I bought two gift cards from West 49 and another from Chapters. For some of you these may be fine gifts to give and you are happy to check off three more items on your list. However, my goal in giving any gift is to first give them what they want and second to try and surprise and delight them with something unexpected. A gift card is not surprising or particularly delightful.

So... what to do? For the first gift card, I took a typical approach and wrapped it in ever increasing sizes of boxes with lots of duct tape and topped it off with pretty ribbon and a bow. It was a very delightful looking gift. But, in the end I decided this was a little too typical and unwrapped it while I pondered other ideas.

It was while wandering through the garage that I received my inspiration - an old eight foot 2x6. Here are the steps that followed.

1. Using a circular saw, cut a slit about 3 inches deep and 6 inches long into the edge of the 2x6. After making the cut, make sure that the gift card will fit inside the slit.

2. Next, decide on a shape to create out of the wood (for this example I used a Christmas bell ornament) and cut the 2x6 into pieces accordingly and nail or screw the pieces together to form your masterpiece. Depending on the size of the gift card you may need to cut an additional slit in a second piece of the 2x6 so that the card will fit properly 'inside' your wooden ornament.

Before wrapping your ornament you may want to secure a ribbon to the top so that you can hang it up. At the top of the ornament, hammer in a nail half way. Now wrap a small piece of ribbon around the nail and then bend the nail over completely so that it holds the ribbon in place.

3. The finished and fully wrapped product!

4. Now repeat with other shapes as necessary until all your gift cards are wrapped. I created a Christmas bell, a Christmas tree, and a Christmas ball.

The reactions you get may vary, but my nephews used the words 'best' and 'ever' after opening their gift cards. Also, the look on their faces after they unwrapped their homemade 'ornaments' and before they realized there was more unwrapping to do was priceless.

Hopefully I can wrap more gift cards next year. My brother has already promised it will involve acetlyane torches.

Perfecting your process

“Eliminating delays between what you do gives you a better return than getting better at what you do.” - Alan Shalloway (Dec 2, 2010, twitter).

I was recently introduced to the ball point game as a way to introduce agile concepts. A colleague of mine had decided to try it out for a larger group so I volunteered one of our teams in order to ‘test drive’ the game and the facilitation of that game.

The game itself is pretty straightforward. If you want to read about it, check out Declan’s link above or one of the many other sites describing the game. One of the objectives of the game is to show how teams can dramatically improve their process just by stopping, reflecting, and re-planning.

This particular team improved from a velocity of 28 to 57 in four iterations (see the image). However, if you read about this game from other sources, this kind of improvement is ok, but not great. The team focused their iteration planning efforts on perfecting their style rather than changing their process. They did discuss some alternative processes but ultimately rejected them and decided together that their best course of action was to perfect their current method.

To make matters worse, as facilitators we were terrible project managers as we told them stories of great improvements by other teams (“I bet you can get to 150, I’ve seen other teams do it”) but all this did was make them frustrated as they continued to try and perfect their process with only small gains. Plus, even though they doubled their efficiency in a short period of time, they were frustrated that they couldn’t go faster and started to slow down at the end of iteration 4. They suggested that if an iteration 5 would have been held, they would only have gone slower as the realization sunk in that they would not be able to achieve 150.

The exercise up until this point did not achieve what we had hoped for. We had hoped that they would find huge jumps in productivity each iteration and that they would get more and more excited each iteration. Instead, they only achieved modest gains and got more frustrated each iteration. So, what did we learn from this?

1. As the quote above says, it confirmed that focusing on improving and perfecting your current process is only going to give you modest gains. Practice doesn’t make perfect if your process is flawed. Continually practicing a bad process isn’t going to result in the benefits you are looking for and will likely slow your teams down over time as apathy builds. We need to give teams the lean tools and techniques to help them find their delays. One of the ‘tricks’ to this game is to reduce or eliminate your delays instead of perfecting your throws.

2. We need to give teams enough time to not only re-plan the next iteration, but to ask them to reflect upon and challenge both their process and their assumed constraints.

3. Teams who are pushed to achieve incredible productivity gains by well meaning leaders under the guise of empowerment or encouragement may see short term gains, but in the long term those teams will likely be negatively affected - especially if the teams haven't been given the tools and techniques to achieve those gains.

The team we tried this with did not at first come away with tools that they could use to improve their current project. In fact, we may have scarred them forever ;) We are trying this game again in a few weeks with a different group and we’ve made some changes with the hope of enabling the teams to see the ‘ahah’ moment before the end of the game. I’ll keep you posted.

Agile Retrospectives - a Rising Patton Fusion

The last session of Agile Vancouver 2010 was a unique opportunity to watch Linda Rising conduct a conference retrospective with the Agile Vancouver organizers. It was interesting to watch how she facilitated and I wrote down some of her techniques so that I could try them out. The following day during the tutorials Jeff Patton led us through a mini retrospective with his own interesting twists based on his story mapping experience. What follows is the fusion of their ideas.

Note: This retrospective works nicely using index cards that can easily be sorted and grouped around a common table. If you are using walls and stickies, you can adapt where required.

Step 1 - Set the tone:
Recite Norm Kerth's Prime Directive (Linda was able to recite this by memory):

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

After reciting, ask each team member one by one if they agree to uphold this statement during the meeting and to avoid blame. A simple verbal "yes" indicates agreement. The verbal agreement is a simple influencing strategy or pattern that helps set the tone for the retrospective.

Step 2 - Framing the Retrospective:
The facilitator tells a story of a co-worker meeting you in the hallway of your company. The co-worker asks: "I know you were on project [X], how was that?". Each person responds with "It was great because...". Instead of speaking the answers out loud, give each person 3 index cards and have them write their answers down in silence. This allows input from each person regardless of personality type and keeps your team member's answers from influencing your own.

When each person has filled out their 3 cards, they read each one out loud and place them on the table. Once all cards are on the table, ask the group to silently group the answers together. Cards that are similar should be close to one another and cards that are different should be farther apart. According to Patton, the simple reason for doing this in silence is because it allows the work to happen quickly and without much discussion. In our exercise, we found this to be true.

Now that the good things are grouped together, take a different coloured index card and have the group summarize each grouping with a new card. For example, summarizing items like "team worked well together", "Bob collaborated to help me with my task", "Team rallied to complete the stories together" might be summarized with a card called "Great team work".

Step 3 - Do Differently:
Now that we have acknowledged the good things about the last period, remind the team that it is only a perfect project if they would do that project or iteration again in exactly the same way. In reality there is always something we would do differently. Ask the team to silently fill out 3 more index cards with what they would do differently. They may not write cards that associate blame, describe what wrong, or try to problem solve. In this part of the retrospective we are only identifying what we would do differently.

Once everyone has completed their cards, we again read them aloud as we place them on the table, group the cards in silence, and summarize with a different coloured index card. As the cards are read or summarized, the facilitator may need to remind the team to refrain from problem solving or directing blame.

Step 4 - Voting:
The next step is for the team to agree on which items on the "Do Differently" list are the most important. To keep the voting impartial and independent, have each team member write their top 3 items on an index card and hand the cards to the facilitator. The facilitator then tallies the votes and records the totals on the summarized cards. An alternative is to use dot voting, but I've found that dot voting can be 'gamed' too easily and that initial dots influence those who vote later (group think).

Step 5 - Experiments:
Using the top 1 or 2 voted items, ask the group to split into groups to discuss them - 1 group per item. Instruct the groups to discuss small experiments or tweaks that the team could try in the next iteration. If you practice frequent retrospectives, this discussion does not need to be about problem solving or even root cause analysis. The goal is to quickly agree on small experiments to try to resolve the issue you are discussing. For those dedicated to root cause analysis this may be a problem, but give it a try and do what works for your team while avoiding blame or delving deep into problem solving. This part should be time boxed to 10 or 15 minutes maximum.

After deciding on the experiments, have one person from each group present the idea to the group. This idea needs to be included in the backlog for the iteration and the team (not an individual) commits to completing the experiment during the iteration and examining the results.

Step 0 - Review Experiments:
At the beginning of the next retrospective, add a new step at the beginning to discuss your experiments to see how effective they were and use this information as input into future experiments.

Other notes:
If you are doing a retrospective for a larger period of time, then consider starting the retrospective by building a timeline of events. For more info, check out this blog: http://www.thekua.com/rant/2006/03/a-retrospective-timeline/

Thanks Linda and Jeff for sharing your methods and ideas.