Analysis Debt, Redux

Mary Gorman and I wrote an article on analysis debt Better Software. In it, we said that, like technical debt, teams can incur analysis debt by either ignoring analysis (a potential pitfall of agile teams) or overinvesting in analysis (a potential pitfall of traditional teams).

In a private exchange, one article reader took me to task. Referencing our table of Analysis Debt Causes, he wrote, “I see poor requirements work that would result in an inadequate solution, no matter how well [the product] built.” Furthermore, he said, “all the Remedies [in your article] are really requirements best practices.”

I was glad to hear his perspective because it prompted me to think further on this topic.

Context Counts

First, I don’t believe in “best” practices—only good practices applied appropriately for a particular project, culture, skills, and product. In other words, particular practices are optimum in a particular context.

Be Intentional

Beyond that quibble, I want to comment on our intent in pointing out the importance of understanding analysis debt.

Yes, good requirements work is essential on any project, including agile projects. Our point in the article is that analysis debt can be a valid thing to incur on agile projects, but if you do incur it, be intentional about it.

If you’re like me, you too have experienced analysis paralysis and scope creep on traditional projects: months and months spent in requirements analysis with only an outdated document to show for it; the ever-growing expansion of the requirements. Both are common problems on many projects.

In part, avoiding analysis paralysis and scope creep is a point of using agile. Agile practices – such as timeboxing, defining cohesive sets of small requirements, identifying unambiguous conditions of satisfaction, maintaining close customer collaboration, and so on – are effective countermeasures.

Still, by using agile practices you may pay a price when it comes to analysis.

When the agile team is not being intentional about skipping, skimming, or ignoring requirements analysis, bad things can happen. Let’s look at two examples of the “smells” of analysis debt.

The Team Revises it Theme (Be Green)

One the team I coached had assumed they shouldn’t explore the bigger picture for delivering requirements before starting iteration planning. Their theory: “You’re not supposed to worry about that in agile.” This was a smart team that was delivering tested bits of requirements monthly.

But then the market changed. Some new releases from competitors, along with the global drive for going “green,” meant their product focus needed to shift. They found this out when I lead then release planning. They finally paused to revise the theme for the entire four-month release before jumping into iteration planning.

Uh-oh – time to rewind.

Luckily, it wasn’t too late. We did some lightweight release planning in half a day, and the team reset the goals for the upcoming iteration to good effect.

The lesson: requirements don’t exist in a vacuum. Context counts.

The Team Makes Ready

Here’s another example. I coached an agile team that, prior to my engagement with them,  believed in the magic of stories: as long as they had their requirements in the canonical form (“as a … I need to … so that …”), they believed they were ready for iteration planning and making commitments they could keep.

After all, they had taken scrum training and some user story training.

They believed that as long as they had stories selected for the upcoming iteration, they were ready to plan and deliver. Once the clock started to tick and the iteration began, the team began their analysis in earnest.

But after their iteration planning session, development slowed to a crawl. They discovered that their stories were far more complex than they seemed. Team members were not able to complete most of the stories. They started offloading stories to the backlog. They spent most of their demos discussing how to split out stories. The same story began traveling from iteration to iteration.

What to do?

As coach, I showed them about “making ready” doing work-ahead analysis by exploring options for stories prior to iteration planning. The techniques may vary for doing this. In this case, we built lightweight (“organic”) data, context, and state models to supplement the stories (on flip chart paper) and wrote business rule “families” on posts. We thereby sliced their “chunky” stories down to smaller ones and then identified acceptance criteria (a.k.a. conditions of satisfaction or “doneness” for user stories.

When did all this take place? Before the iteration planning workshop. These few hours enabled the team came into iteration planning with a sharper understanding of the requirements.

Thanks in part to this requirements work-ahead analysis (readying stories for planning), the team began meeting its commitments. The members also began to spot story interdependencies before development began, so inside the iteration they built stories in order of development dependencies.

The lesson: you need to conduct some analysis – just in time or, in this case, just-before.

The bottom line? On agile projects, there is a balancing act between the “now-view” and the “big-view”.

At times, the imperatives of time to market and regulatory timelines trump the big-view. Getting a new agile team “in flow” for regularly delivering small chunks of requirements is more important than starting with longer-horizon release and product roadmapping.

Analysis Debt on Agile Teams

Remember, too, that all this analysis is the responsibility of the entire team (including the customer/Product Owner). It is important and complex work. Success requires that you interweave agile requirements analysis, hard-nosed customer (value) prioritization, honest estimates, understanding of requirements interdependencies, and assessments of technical and team risk.

Yes, getting into analysis debt can be necessary at times. Just be intentional about when and how much analysis you undertake. Agile analysis aligns with the agile value of transparency, helps you build the right product at the right time, and promotes a healthy team and product.

Resources:

• Mary and my article, “Managing Analysis Debt”
• Hear and see Ward Cunningham, father of “technical debt,” explain the origins of his metaphor.
• Jeff Sutherland reported on the business value of “making ready” (see Jeff’s slides 49 through 52)
• In “No Best Practices” James Back debates “best practices”, preferring good practices (in context)