Mike Cohn’s Blog - Succeeding With Agile®

I want to address a question I was emailed yesterday but that I receive frequently. What should we do in the case when the team really likes having a physical task board, but when one team member is remote?

My first answer is always: Try to get the one person to move to where the rest of the team is. I don’t expect to see any moving trucks roll out when I ask this, but I have to ask. I figured if I keep asking, some team somewhere will eventually have the person move. Having one remote is a cost that must be borne by the full team. For the right person, it’s easily worth it. But sometimes, the person who is remote has not special skills, knowledge or experience to justify the added hassle.

So, assuming that we’ve tried the “move here” solution and it didn’t work, what can a team do that likes the physical task board but that has one remote member?

My recommendation is to continue to use the physical task board–it is simply too beneficial to the collocated team members to give it up in favor of a product backlog tool, especially if team members are already used to it and like it. How the team conveys information on the task board to the remote team member depends on what that person does.

Sometimes the remote person works remotely because they have a very specialized skill that couldn’t be filled in the office where the rest of the team is. This would be the case, for example, if our remote person is an expert in Windows internals and is writing boot-time code in C++. It would also be the case if our remote person has twenty years of experience in the domain and with some of our really old code. In these cases, the remote person usually (not always) works for a day or two relatively alone. The remote person in this case could identify during the daily Scrum what he or she will work on and not need further interaction with the task board until selecting the next task. Here, the remote person doesn’t really interact with the task board at all and interacts only with the team. Not ideal as I’d like the person to see the tasks, but this can work in some situations.

What is more common is for the ScrumMaster to take on the responsibility of updating an electronic version that mirrors the physical task board. A shared spreadsheet is normally sufficient for this, but some teams opt for a more specialized tool, which is fine. Many tools offer 5-10 user free licenses and since the tool is only needed by the ScrumMaster and one remote employees, the free license is adequate.

Normally the ScrumMaster updates the electronic task board once a day, usually right after the daily scrum meeting. Of course, reading the physical task board and updating the electronic one can be quite time-consuming because the ScrumMaster has to look at each task in both places to see if that item needs to be updated.

One good way of minimizing the time the ScrumMaster spends doing this is to mark the cards on the physical task board. The mark indicates “I’ve updated this task. Please update it in the online task board.” I like to use Post-It flags for this. As team members do their daily scrum, they stick one of these flags (of any color) on the card. If the estimate changes, if the task is done, if a new task is added, those cards are tagged with a flag. When the meeting is over, the ScrumMaster can very easily see which items need to be updated. The ScrumMaster removes the flags once the online task board is updated. This approach also works in situations where the ScrumMaster updates the board more than once a day. Any time someone changes the board, flag the task.

Other teams do something similar using color-coded dots. Anything touched on Monday is blue, Tuesday is red, and so on. Two problems occur though: First, the dot packs usually come with four colors to a pack so you have to buy a fifth color. Second, it’s a hassle to make sure we have the right color on hand.

Prolific and popular blogger Jurgen Appelo is conducting a survey about agile practices. The survey focuses on which practices are in use and even which you don’t consider to be agile practices.

There are six parts to the survey but you can take all or part. Please help everyone out by helping us all understand which practices are in use and to what extent.

The survey is available on his blog.

As you may know, I am editing a series of books for Addison-Wesley, my long-time publisher. Authors in the series are all going to be sharing early drafts of chapters and soliciting feedback. Two authors are far enough along that they have made initial chapters available.

Roman Pichler is writing about the product owner role in his book, Agile Product Management: Turning Ideas into Winning Products with Scrum. Two of his chapters are available now.

Clinton Keith is writing Agile Game Development with Scrum, which builds on his experience as a game studio CTO and fifteen years in the industry. He has one draft chapter available.

Already available is Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and Janet Gregory.

I strongly encourage checking out each of these books.

I live in Colorado, which boasts some of the world’s best hiking trails and North America’s greatest concentration of mountain peaks over 14,000 feet (nearly 4,300 meters). There are so many mountains over 14,000 feet high here that they are referred to simply as “fourteeners.” Most of Colorado’s fourteeners are non-technical routes; no special equipment is needed and anyone in good shape can make it to the summit.

This means there are a couple of different ways to climb a fourteener. One approach is to drive to the base of the mountain and start walking toward the highest thing you see. This will almost certainly be a false peak—once you’re reached it, you’ll see a higher point that had been obscured by the false peak. So walk again toward the highest point you see. It, too, will probably be a false peak. But, keep this up long enough and you’ll eventually find the true summit. In doing so, though, you will probably have to descend into a few valleys only to climb higher on the other sides. The approach will feel highly inefficient.

A second way to climb a fourteener is to purchase a topographic map, identify a route up the mountain, and then proceed that way. Looking first at a topographic map allows you to plot a course to the summit that avoids much of the inefficiency of the first approach. Of course, we must be careful not to value our route plan too highly—a stream we plan to cross may be too deep when we get there or a rock slide may have made a trail impassable, and we’ll need to alter the route when we encounter these problems.

An agile team does release planning to avoid the same type of problems we avoid with a topographic map when hiking a fourteener. A release plan helps a team avoid finishing a series of sprints and feeling that, while they always worked on the highest priority items, the collection of work completed does not add up to a satisfying whole.

As you may now, I am working on a new book, which will be called Succeeding with Agile. I recently finished writing a chapter for it on the impact of the human resources and facilities groups on an organization that is transitioning to agile. While writing that chapter, I put together a list of all the things that I think should be visible within the ideal agile workspace:

• Big Visible Charts. Alistair Cockburn coined the term “Big Visible Charts” to describe the charts that agile teams like to hang on their walls. One of the most common of these is the sprint burndown chart, showing the number of hours remaining as of each day of the current sprint. Charts like these provide a strong visual reminder of the current state of the project. What is shown on these charts will get the attention of team members so display charts showing the most important information for that sprint. Ron Jeffries suggests considering big visible charts showing the number of passing customer acceptance tests, the pass/fail status of tests by day, sprint and release burndown charts, number of new stories introduced to the product backlog per sprint, and more.
• Additional feedback devices. In addition to big, visible charts, it is common for an agile team to use additional visual feedback devices in their workspace. One of the most common is a lava lamp that is turned on whenever the automated build is broken. I’ve also worked with teams that use flashing red traffic lights to indicate exceptional conditions such as an issue on a production server. Also popular are ambient orbs and Nabaztag rabbits, which are wireless programmable devices that can also be configured to change colors, speak messages, or wiggle their ears as a team desires. Devices like these make a workspace more dynamic, unobtrusively bringing into it information the team may find helpful.
• Everyone on your team. Each person on the team should ideally be able to see each other person on the team. This absolutely includes the ScrumMaster and ideally includes the product owner. I do understand, however, that product owners often have responsibilities to other groups outside the development team and so may sit near them instead. Still, in an ideal world the product owner would be visible to everyone in the team workspace.
• The sprint backlog. One of the best ways to ensure that everything necessary is completed in the sprint is to make the sprint backlog visible. The best way to do that is by displaying the sprint backlog on a wall, ideally in the form of a task board A task board is usually oriented in rows and columns with each row containing a particular user story and one index card or sticky note for each task involved in that story. Task cards are organized in columns, minimally including “To Do” “In Process,” and “Done.” In this way, team members are able to see work progressing across the task board during the sprint and all work to be done is visible at all times.
• The product backlog. One problem with running an endless series of sprints is that each can feel disconnected or isolated from the whole of a planned released or related set of new capabilities. A good way to reduce the impact of this problem is by displaying the product backlog somewhere clearly visible. This can be as simple as keeping the shoebox full of user stories written on index cards on a table in the middle of the team’s space. Even better, tack the index cards with those upcoming user stories on a wall where all can see them. This allows team members to see how the user stories they are working on in the current sprint relate to others that are coming soon.
• At least one big white board. Every team needs at least one big whiteboard. Locating this in the team’s common workspace encourages spontaneous meetings. One developer may start using the board to think through a problem; others may notice and offer to help.
• Someplace quiet and private. As important as open communication is, there are times when someone needs some peace and quiet. Sometimes this is for something as simple as a private phone call. Other times it can be to think through a particularly challenging problem without being interrupted.
• Food and drink. It’s always a good idea to have food and drink available. These don’t need to be fancy, and they don’t even need to be provided by the organization. I’ve worked with plenty of teams that buy a small under-desk refrigerator and share the expense of buying water bottles or soda for it. Other teams buy a coffee machine, depending on team preferences. Some teams rotate bringing in snacks, both healthful and not.
• A window. Windows are often a scarce commodity and are doled out to an organization’s favored employees. One of the nice things about an open workspace is that windows are shared. Even if the view is only of our parking lot and can only be seen across three messy desks, at least I can see the window and some natural light.

It’s unlikely that every one of these will be visible from your workspace, but the more of them visible, the better. Let me know what else you think should be visible from within the ideal agile workspace.

I haven’t heard the term “release backlog” in many months, but it’s come up in three conversations over the past week. So, I want to share my thoughts on whether a team should have a Release Backlog in addition to the conventional Product and Sprint (or Iteration) Backlogs.

First, let’s clarify what people mean when they refer to a “release backlog.” A release backlog is a subset of the product backlog that is planned to be delivered in the coming release, typically a three- to six-month horizon. A release backlog would presumably contain the same type of items as on a product backlog. My preference for this, of course, would be user stories. So, at the start of some release planning horizon, a product owner with help from the team and other stakeholders would example the product backlog, select some amount of high priority work and move those items to the release backlog. Later, in sprint (iteration) planning, the team would examine the release product and select some amount of work to do. (Notice how this already goes against existing agile literature that says the team selects top priority items for the sprint from the product backlog?)

I am opposed to the use of a release backlog for a couple of reasons:

First, in all projects that are not being done as fixed-scope contracts (and, arguably, even then) we don’t know exactly what user stories or features will be delivered in a release. To say that there is a release backlog may not imply a guarantee that all features on it are delivered. However, it does create additional work as items are moved off back and forth between the product and release backlogs. This will happen as the team’s velocity changes (even by small amounts) from sprint to sprint. If the release backlog is to show what a team will deliver in a release, it should contain an amount of work equal to the number of story points (or ideal days) times the number of remaining sprints. If you have an average velocity of 20 and 6 sprints left, the release backlog should contain 120 points worth of work. Suppose the team finishes 24 points of work in a sprint. The backlog is now down to 96 points (120-24) but should contain 100 (5 sprints left x an average velocity of 20). Things get even more difficult if that good velocity of 24 increases the team’s average velocity to 21. In that case the release backlog should contain 5×21=105 points of work; we need to move 9 points of work from the product backlog to the sprint backlog. If there’s a release backlog, this moving of items back and forth from product backlog to release backlog will happen every sprint.

Second, introducing a release backlog creates additional confusion. We’ve already overloaded the word “backlog” with “product backlog” and “sprint backlog.” Why confuse things further with a third type of backlog unless there is an immensely compelling reason to do so?

Third, introducing the concept of a Release Backlog actually makes it harder for product owners to do one of the most important things they should be doing–looking at the features or user stories that just miss the cut of being in a release. When I look at a product backlog and count down the number of story points that I anticipate will be in the release, the most interesting thing to me is not necessarily the set of user stories that will make it into the release. I’m often just as interested in the next few user stories below that cut-off point. That is, I want to know what user stories won’t quite make it into the release. After all, we say that one of the benefits of agile (on some, not all, projects) is the ability to decide later if we should release a few sprints early (if a lot has been done), on the planned date, or perhaps a sprint or two late if we want to add more functionality before a release. This is made more difficult with a Release Backlog because a product owner now needs to examine both a Product Backlog and a Release Backlog to make these decisions.

So, what do I propose instead?

I advocate that all teams track their velocities. This leads to a graph like this:

This graph shows a team calculating three average velocities:

1. Long term average, defined as the mean of the last eight sprints
2. Worst case average, defined as the mean of the worst three chosen among the last eight sprints
3. Best case average, defined as the mean of the best three chosen among the last eight sprints

You can choose your own ways of calculating long-term, best-case, and worst-case average velocities. These are just the ones I like. We use these average velocities as shown in this figure:

In this figure, the product backlog is shown on the left as a stack of index cards. We use the three average velocities multiplied by the number of remaining sprints to draw arrows pointing into the product backlog. The range created by these arrows indicates the likely amount of work finished by the planned date. Our release plan is the work defined by the arrows. Rather than a Release Backlog as a new work product or artifact, my equivalent of a release backlog is the product backlog and these arrows pointing into it.

As you can imagine, predicting velocity as a range is much more likely to be accurate than using a single point estimate (”Our velocity is 31.”) as has been implied by everyone I’ve heard talk about a Release Backlog. Additionally, looking at figures like these should make it apparent that the amount of work expected to be delivered in a release will change from sprint to sprint. Pointing arrows into a product backlog is much easier and more helpful than creating a new work product, the Release Backlog.

I’m often asked about the relationship between story points and hours. People who ask are usually looking for me to say something like “one story point = 8.3 hours.” Well, that just isn’t the case (especially since I made up 8.3 hours). Let’s see what the real relationship is between a story point and hours…

Suppose for some reason you have tracked how long every one-story-point story took to develop for a given team. If you graphed that data you would have something that would look like this:

This shows that some stories took more time than others and some stories took less time, but overall the amount of time spent on your one-point stories takes on the shape of the familiar normal distribution.

Now suppose you had also tracked the amount of time spent on two-point user stories. Graphing that data as well, we would see something like this:

Number of hours to develop various one- and two-point stories

If the one-point stories are centered around a mean of x, ideally the two-point stories will be centered around a mean of 2x. This will never be exactly the case, of course, but a team that does a good job of estimating will be sufficiently close for reliable plans to be made from their estimates.

What these two figures show us is that is the relationship between points and hours is a distribution. One point equals a distribution with a mean of x and some standard deviation. The same is true, of course, for two-point stories, and so on…

By the way, notice that I’ve drawn the distributions of one- and two-point stories as having overlapping tails. It should be totally realistic that the biggest story that a team put “one story point” on might turn out to take more time than the smallest story they put a two on. After all, no team can estimate with perfect insight, especially at the story point level. So, while the tails of the one- and two-point distributions will overlap, it would be extraordinarily unlikely that the tails of, say, the one- and thirteen-point distributions will overlap.

I have always done highly iterative development and have always worked in short iterations. Initially this was because the domains I worked in early in my career gave me no choice but to work that way. Later I discovered the philosophical reasons for working this way. I also soon learned that keeping the software close to bug free was best. This was all back in the 1980s and early 1990s. In 1992 I started Mountain Goat Software to do outsourced, contract development projects and needed a name for the new company. I found the name in Tom Gilb’s wonderful Principles of Software Engineering book. Every page or two has a gray sidebar highlight some key principle. On page 99 is the Mountain Goat Principle:

Take one step at a time up the slippery mountainside, and make absolutely sure that each hoof is on solid ground before you take the next step.

I’ve always considered Tom to have been the original agilist. In 1989, he wrote about short iterations (each should be no more than 2% of the total project schedule). This was long before the rest of us had it figured out.
Although I’d named the company after one of Tom’s principles, I had never met him in person. Well, last month I finally had the honor of meeting Tom and his son, Kai Gilb, who is a top-notch software consultant in his own right. (See Kai’s book on the Evo process.

At dinner, Tom and Kai posed a challenge to me that I haven’t been able to figure out yet. We talked about how adding a new feature to a product is not an issue of adding new capabilities as much as it is about changing how well something can be done. I other words, it is about changing the quality of the implementation.

For example, imagine a simple word processor back in 1982 without an integrated spell-checker. Spell checking was still possible. You could have looked up each word on the screen in a physical dictionary and determined which were misspelled. Adding the integrated spell-checker was more about improving the quality of an implementation than about adding a new capability.

The challenge that Tom and Kai posed me was to think of a function in MS Word (any word processor will do), that is a new function, and not just a change in the quality of those functions. To think about this, compare Word of today with the tools of a century ago—paper, pen or pencil, the post office, and so on.

Surely, they were nuts, I thought. So I tossed off a few answers:

“Undo.”

“No,” they replied. “That could have been done in the old days with an eraser.”

“Printing.”

“No,” they replied. “That could be done by monks in a monastery making copies by hand.”

I tried a few more but came up empty. So, how about it? Can you help me by coming up with a feature in a word processor, like Microsoft Word, that is new functionality and not just a change in how well something could have been done with pencil, paper, and similar tools.

As you probably know, Steve Jobs of Apple announced yesterday that he’s taking a six-month leave of absence. His health has gotten worse and hopefully he’s able to recover fully during this period.

As a Mac user, I’ve been paying a bit of extra attention today (and over the past few weeks) to what shakeups might be in store at Apple during Jobs’ absence. I read this today and want to share it as a great example of a ScrumMaster removing an impediment. It’s about Tim Cook, Apple’s current COO, who is likely to replace Jobs:

Tim Cook arrived at Apple (AAPL, Fortune 500) in 1998 from Compaq Computer. He was a 16-year computer-industry veteran - he’d worked for IBM (IBM, Fortune 500) for 12 of those years - with a mandate to clean up the atrocious state of Apple’s manufacturing, distribution, and supply apparatus. One day back then, he convened a meeting with his team, and the discussion turned to a particular problem in Asia.

“This is really bad,” Cook told the group. “Someone should be in China driving this.” Thirty minutes into that meeting Cook looked at Sabih Khan, a key operations executive, and abruptly asked, without a trace of emotion, “Why are you still here?”

Khan, who remains one of Cook’s top lieutenants to this day, immediately stood up, drove to San Francisco International Airport, and, without a change of clothes, booked a flight to China with no return date.

Khan sounds like a perfect ScrumMaster to me. He heard about the impediment and within thirty minutes was on a plane to resolve the problem.

Let’s hope, Steve Jobs’ doctors are able to remove all impediments in the way of his return to good health.

For the full article reference above, see http://money.cnn.com/2009/01/15/technology/cook_apple.fortune/index.htm

I was recently asked to answer “five easy questions” by Jurgen Appelo for his very interesting blog. You can read my answers on his site. Be sure to look around on the rest of Jurgen’s site as he has lots of interesting articles, especially if you’re interesting in complexity theory as related to agile software development.