Fourth day at Agile2011 – Part 2

Fourth day at Agile2011 – Part 2

On Thursday I went to the following sessions

  • Stages of Practice : the Agile tech tree by Arlo Belshee and James Shore
  • The Agile Scaling Model (ASM) : Be Agile as you need to be by Scott Ambler
  • Telling better stories with User Story Mapping by Jeff Patton
  • Slackers and Debtors : Meet commitments, reduce debt and improve performance by James Shore

My Thursday afternoon started with my first and unique session at the Little America Hotel, with Jeff Patton. Jeff told us a story, or better said, he taught us how to build a story map. Most of people who are experienced in Agile know about user stories.

As an Agile practionner
I want to write user stories
So that my requirements are clear, short, focused, well understood, shared, easy to maintain, etc.

When Jeff asked who was using user stories for requirements, nearly all arms raised in the audience. The real problem is not about writing stories. There are a lot of books and podcats and resources about it already available.The real problem is how to write good and short stories, and how to organize and prioritize them. Well, this is done easily with User Story Mapping.

Jeff Patton first let the audience have a first approach of User Story Mapping by having us write down on stickies the different things we did, last time we went to the see a movie. Once we were done writing down, he had us regroup by table all stickies that represented more or less the same action. Of course, he let us self organize. This was our story map.

User Story Mapping

What does a story map bring that a prioritized backlog don’t have ?

  • make visible the workflow or value chain
  • show the relationships of larger stories to their child stories
  • help confirm completeness of your backlog
  • provide useful context for prioritization
  • plan releases in complete and valuable slices of functionality

Simply put, “the story map helps you tell the whole story of your products”.

  • Verbs are becoming “User tasks”
  • Latitude (horizontal) represents the user workflow
  • Longitude (vertical) represents dependencies, sub tasks, variations, detailed tasks
  • A set of related stories are grouped into a “User activity”, which has a general goal
  • The set of all activities constitutes the backbone of your product.

The concept is simple : “By arranging task-centric story cards spatially, we can tell bigger stories”.

Jeff Patton

The most important thing about stories it still what Ron Jeffries explained 10 years ago. The 3 Cs

  • Card : start by writing a summary of the story, use the As a… I want to… So that… pattern if you want
  • Conversation : you need to have a conversation to clarify the requirements. The card itself is not enough.
  • Confirmation : the acceptance tests that make your story done

With time, I find out that the third C is probably the most difficult to obtain. Maybe reading Gojko Adzic‘s last book will help.

Anyway, when you take a look at a story map, and you just attended to 3 sessions on scaling Agile, you cannot help thinking that user story mapping is definitely a tool you want to know more about. Nothing revolutionary about it. A Jeff Patton says himself, most of this stuff has been around for a while already. Still, it’s important that people like Jeff continue to talk about it in conferences, so a lot more people know it exists.

This session was definitely fun and Jeff is a very talented presenter. It was a difficult exercise for him because the room was crowded and the time was a little bit shorter than he is used to having, but I think he did good.

My last session of the conference (on Friday there were only two key notes) was about a game invented by Diana Larsen and James Shore. I have read The Art of Agile Development quite a while ago now, and I loved it. It’s stays one of the best books I have read on Agile. In this book, James Shore already writes about slack time and technical debt. So I was interested to hear what he had to say about it. But I must admit I didn’t really expect what happened.

First thing, when entering the room, everyone was explained that they were expecting a different kind of room, one with tables, but it was a room with chairs facing a screen. The presenters and his 4 co-hosts and 2 stage volunteers had reorganized the room to create some kind of pods on each side of the main aisle. On pod on each side, 2 chairs in the middle, 4 chairs around. No one realized at that point what it was for.

The game is called “Slackers and Debtors”. It’s pretty simple. A team is 8 people. Each team is given a number of poker chips that are placed on the chairs on one side of the aisle. The goal of the game it to move the chips from on side of the aisle to the other. Pretty simple, no ?

Well, first problem “How many chips do you think your team is able move in 2 minutes if one person can only have one chip at a time in the hands ?” In other words, what is your estimated velocity. We estimated 30 and did something like 60+.

Second part of the game, add some difficulty by introducing “technical debt”. Roll a 6 sided dice. The number of the dice gives you the number of red cards you need to pick from the deck of “technical debt cards”. One QA person for 2 cards needs to be designated in the team. This means if you have 5 cards, you have 3 QAs, 2 with 2 cards, 1 with 1 card. Now what’s on the cards ? Well, on the cards you find rules such as

  • “At the end of the iteration, all stacks have to have at least 20 chips”
  • “Colors must be alternating”
  • “Only one person at a time can touch a chip”
  • “Stacks must be perfectly aligned”

And so forth. The QAs have to play the game, and if something is wrong, they take the faulty stacks and bring them back to their origin. Well guess what ? 3 iterations, 3 times 0 velocity. Ouch, this technical dept is really a drag.

Now let’s change the rules again. You can chose in the team 1 or 2 “developers” that will not work. They will be considered as working to reduce technical debt. First iteration, you roll a 20 sided dice. If you choose to sacrifice 2 developers, next time you will roll a 10 sided dice. If you chose to sacrifice only 1, you will roll a 16 sided dice. If you sacrifice none, you will continue to roll the 20 sided dice.

Let me tell you that we directly got the point and chose to sacrifice 2 developers. Let me also tell you that this iteration was not that successful. I think we had 8 cards, which means 4 QAs that could not develop, added to the 2 developers that were sacrificed, only 2 developers could work. The resulf was bad.

Next iteration, 10 sided dice, sacrificed 2 developers again, this means that next iteration we will roll a 4 sided dice. This time things got better. Our velocity went from 0 to 40+ I think.

Next iteration, 4 sided dice, sacrificing  2 again, we no more technical debt for next iteration. Velocity increased from 40 to 60+. We actually finished the stack before the end of the iteration. Unfortunately this was the last iteration and we could not enjoy the fact that we had completely erased our technical debt.

So, what’s the outcome of this game. Well, first it was a lot of fun. Everyone got into it pretty quickly. Second thing, well if you don’t know it yet (which was not my case but…) you realize how important it is to give developers slack time to reduce technical debt. Technical debt is a slow paralyzing poison. It goes deeper into the veins of your project and starts its vicious doing, until your team is completely paralyzed with a project that can’t be maintained anymore. Each change takes so much effort and is so risky that you can’t afford to do it anymore.

We finished the session by a small retrospective within our team. As a developer, I stressed out the fact that it is really important for developers to take some time, not only to refactor and reduce technical debt, but also to improve, to look around, to read, to blog, etc.

This is what continuous learning is all about. Everyone agrees on that, no ? Well, if you agree, then you should start to undercommit during your sprint planning, to give developers some slack time. This will increase the performance of your team and the quality of your product.

Cédric Pontet

Cédric Pontet is a seasoned Lean and Agile practitioner, with more than 13 years of experience in software development. He really started focusing on Agile project management when he joined Agile Partner. Since 2005. Cédric has been involved in sizable projects, for several customers in sectors as various as "notaries" public sector, intellectual property management, banking & insurance, or post & telecom. He has been working on these projects first as a developer, and then as an architect and a team leader, gaining more and more experience and agility, while always keeping an eye on technology evolutions. Lately, Cédric has been spending more time coaching teams to start their agile transformation, evangelizing Lean and Agile values, in Luxembourg and its neighboring countries, not only for software development but beyond.

No Comments

Post a Comment