Rabu Schedule Now Available for Download

03 Aug, 2011

A few months ago, I announced Rabu, a project focused on creating wonderful relationships between Agile teams and their customers. Today I'm proud to announce that our first tool, Rabu Schedule, is now available.

Rabu Schedule helps you delight your customers by telling them what will be done and when. It's interactive, so they can try out "what-if" scenarios and explore the schedule consequences of including or excluding various features. And as a command-line tool configured with a text file, it's easy to fit into your existing build automation.

I'm pretty excited about what we've achieved with Rabu Schedule, and this is only the beginning. Check it out and let me know what you think.

Rabu Schedule Visualizations: Taking the Edge Off Hard Facts

26 Apr, 2011

Our customers want--need--to know what we're going to get done and when. As I described in my last Rabu essay, Agile teams have the ability to make those projections.

But they aren't always well-received. Most Agile teams I've met don't have the full trust of their key stakeholders, and schedule projections often aren't as rosy as those stakeholders would like. The stakeholders react by shooting the messenger.

We need to find a way to redirect stakeholders' frustration to a constructive discussion of the facts rather than an exercise in blaming the team. That's where Rabu visualizations come in. They attempt to present projection data in a way that focuses conversation on facts and options rather than blame.

Stakeholders' most common complaint is one we've all heard before: "Why will it take so long?" It's easy to interpret that question as an attack on the team's ability, especially when it's said in an angry tone of voice, but we can also create a more positive discussion by focusing on two underlying questions:

  1. What are you going to work on during that time?
  2. Is this estimate realistic?

What are you going to work on?

If you have an estimated story backlog, you can answer the question of what you're going to work on very easily: you're going to work on what's in your backlog.

You shouldn't just shove a list of stories at your stakeholders, however. That's a lot to absorb at once, and that risks making your stakeholders feel foolish, which will only increase tension. Instead, roll up the list of stories into three to seven major items. Perhaps they're minimum marketable features (MMFs); perhaps they're just groups of stories. Either way, the goal is to distill your backlog down to its essence.

For example, for the upcoming Rabu 0.2 release (going out to early adopters in early May), we have ten stories in our backlog. They're things like "Spike Raphael graphing library" and "Gracefully handle fall-back when there's insufficient historical data." In conversations with stakeholders, however, we roll that list up into three bullet points, like this:

  • Rabu 0.2: Add risk-adjusted burn-up chart
    • Visualization essay
    • Javascript charting research
    • RABU chart implementation

Given a simplified list of features, you can help focus the conversation further by providing a visualization of the work involved for each one. The diagram below shows two options we're considering for Rabu. Option #1 shows the relative size of each feature; Option #2 shows miniature timelines.

Two charts showing options for visualizing the time required by features. The first shows percentage bars representing the amount of time required; the second shows miniature timelines representing when each feature will be complete.

From the outside, programming work always looks easier than it really is. Providing detail about what you're working on and how long it takes will help stakeholders understand why there's so much work involved.

Is this estimate realistic?

Even when your stakeholders understand what you're working on, they're likely to think that your projections are overblown. We need to help stakeholders trust our estimates, and a technique I've found valuable is to show a consistent history of realistic projections by using a risk-adjusted burn-up chart.

A chart showing changes over time for three pieces of information: the team's finished work, the amount of work yet to complete, and the projected completion dates.

On the left, the chart shows the cumulative work required to complete each feature. Time passes as you move from left to right and the total work completed grows. By March 22nd ("today" in this example), there's no work remaining for Feature A.

On the right, the visualization shows your historical projections as miniature timelines. They roughly correspond with the height of the "completed" line, so the highest projection is the most current. You can see that the projections are consistent and narrowing in on a mid-April delivery date.

This is a complicated chart, but I've had success with it. The "completed" line helps stakeholders see that you're making steady progress; the stacked "features" areas show when delays are the result of scope creep; and the historical projections show that your projections are reliable and becoming more precise over time.

Perhaps most importantly, this chart demonstrates to your stakeholders that you're not just pulling your schedule projections out of mid-air. Even if they don't understand the chart, they'll appreciate the sophistication of your projection techniques, especially as they see the chart evolve over time.

No Silver Bullets

When stakeholders shoot the messenger, the root cause is lack of trust, and no visualization is going to magically solve that problem. The goal here is to redirect stakeholders' frustration into a discussion of data. In some cases, the rift between a team and their stakeholders may be too large to overcome. For most teams, though, frequent positive communication and a history of making and meeting commitments will do wonders.

I'd like to hear from you. What have you done to get your customers to love you? How do you share scheduling information with your customers? Share your experiences in the comments.

How Rabu's Schedule Projections Work

13 Apr, 2011

Team Rabu's first target is product scheduling. It's important to customers and it's easy for Agile teams to do well. A lovely combination.

The hard part is doing it in a way that customers love. That will take some trial and error, and we'll need your help conducting those experiments. The easy part is making schedule projections. That's what I'm going to talk about today.

Basic Projections

If you're using a typical Agile process based on Scrum or XP, you have everything you need to make schedule projections:

With these in place, a basic (but naïve) projection is easy. Your velocity represents how much you can get done each iteration, your estimated backlog tells you how much you need to do, and your iteration length tells you how much calendar time it will take. Like this:

Days Left = (Estimates ÷ Velocity) × Iteration Length

(This formula assumes you're performing the calculation at the beginning of an iteration.)

For example, if you have 100 points of stories in your backlog, your velocity is 10, and your iteration length is seven days, then you will be done in (100 ÷ 10) × 7 = 70 days.

It's Not That Simple

If you've ever tried the naïve approach, you know it doesn't work. Plans change; things go wrong.

The naïve projection is the best-case scenario projection. It assumes you will accomplish exactly the same amount of work every week, and that you will do exactly what's in your backlog.

Of course, that's not going to happen. In reality, there's a very good chance your team will discover new stories as you go. You will also have work disruptions such as illness and turnover. According to the data I've seen, projects will only meet their naïve projection 10% of the time. Most will take considerably longer.

A chart comparing the number of projects completed to the ratio of actual time to estimated time.

The above chart is typical. Of the projects described in this graph, only 10% were done before their naïve projection (the "estimated time"). The rest took longer than estimated, and half the projects took more than twice as long.

What's Your Risk?

Schedule projections are a forecast. Like a weather forecast, you have a range of possible outcomes. Some are more likely than others. A good projection is like the above graph--rather than showing a simple date, it shows a range of dates, each with an attached certainty.

Time RemainingCertainty
≤ 70 days10%
≤ 140 days50%
≤ 280 days90%

You can calculate these values by applying a risk multiplier to your projection, as follows:

Projectionrisk = (Estimates ÷ Velocity) × Iteration Length × Multiplierrisk

For best results, use multipliers based on your own historical results. In the absence of that data, I use Todd Little's data (for risky projects) and values calculated with DeMarco and Lister's Riskology simulator (for rigorous projects).

CertaintyRigorous ProcessRisky Process

A team that has a stable velocity, few defects, and meets its commitments every iteration gets to use the "rigorous" column. Everyone else should use the "risky" column.

The Hard Part

As I said in the introduction, making the projections is the easy part. A bit of arithmetic, that's all. The hard part is constructively sharing this information with customers. In my experience, raw projections tend to irritate more than help.

One approach I've seen work uses risk-adjusted burn-up charts. They're the kind of "powerful visual" I described in our vision. Here's an example. I'll describe it fully in another essay:

A risk-adjusted burn-up chart showing the team's progress alongside changes to features over time.

The raw projections combine with solid visualizations and the Rabu workflow to form the basis of Rabu's approach to schedule projections. We'll need to experiment to see what proposal formats work best for stakeholders, and Team Rabu is going to provide tools to make creating proposals more convenient, but you can start using these ideas today. All you need is a calculator and a willingness to experiment.

Rabu Workflow: How Do We Get Customers to Participate?

11 Apr, 2011

How do we get customers to participate in Agile development?

An Agile team is supposed to be able to move full speed ahead at all times, making critical product decisions when they're needed without waiting for approval or clarifications. To achieve this, Agile teams are supposed to include full-time business experts who have the authority to make key business decisions. An established Agile team needs two business experts for every 3-6 programmers in order to keep moving quickly.

Sufficient customer involvement is crucial to Agile success, but it almost never happens. For whatever reason, the people most qualified to be customers on an Agile team usually don't want to take that role. Instead, I typically see overworked product owners assigned part-time to multiple teams. They often have limited decision-making authority and relay questions to the real decision makers. Defects and delays result, and it's no fun for the product owners, either.

Defects and delay. For many established Agile teams, the constraint isn't lack of programmers; it's lack of customers.

The Rabu Workflow

What if we accepted this constraint as reality? Even on the very best Agile teams, you can't have all decision-makers on the team full-time. Yet we need to collaborate with stakeholders. We can't expect them all to join our team, but we need to continue making progress anyway.

Rabu is oriented around this constraint. The core idea is that customers are much happier providing feedback on a proposal than writing on a blank slate. Look at it from their perspective: as a stakeholder, would you rather be put on the spot with an open-ended question like "what do you want," or would you rather critique a proposal?

In the Rabu model, the Agile team makes all the decisions about their work. They have the most information and are most qualified to do so. When they need feedback, they create a proposal--that's where the Rabu tools can help--and ask for feedback in tightly-focused meetings. Sometimes different stakeholder groups will have conflicting reactions. The team's job is to collate those responses and make the decision that's in the best interests of the product.

Rabu Workflow: Dev team wants feedback; Create straw-man proposal that facilitates discussion; Hunt down stakeholder group(s) and discuss proposal; Collate notes and make decision; Act on decision; Repeat.

By putting decision-making responsibility back into the hands of the team, this workflow allows the team to keep making progress even when outside feedback is needed. Stakeholders are more willing to participate because their time is being used well. Most importantly, the Rabu workflow doesn't require any special dispensation from the organization. It's something that most teams can start doing today.