Starter Agile, Pt. 2

An exploration of “Starter Agile” practices through the lens of Joshua Kerievsky’s “Modern Agile” continues with: burndown charts, product backlogs, and user stories.

Did you miss yesterday’s post? Part 1 explains why timeboxes, story points, and velocity are “Starter Agile.”

Starter Agile: Burndown Charts

Without question, the most recognized “big visible” artifact to emerge from the toolbox of Agile practices is the burndown chart. Only used by software teams working in iterations, the visible indication of progress against “sprint plan” is meant to provide transparency, a sense of commitment, and some practitioners even suggest the chart can diagnose behavior.

The burndown chart is also neatly equipped with easy-to-grasp handlebars for distrustful people who want to drive teams’ “progress”, plus a convenient safety net to catch those folks agonizing over their withdrawal symptoms from the loss of Gantt charts.

In addition to being an easy landing spot for existing mindsets and behaviors, the burndown chart is wonderful at giving a false perception of success. For example, a team may be “on track” late in the sprint but have nothing complete (100% of goals in progress, 0% complete). Further, team members may be tackling the most complexity early and discovering new work – pushing the “effort-to-plan” indicators in a negative direction. But is this an indicator of failure or risk? No matter; Captain Distrustful at the handlebar controls will be eager to crack the whip.

“Modern Agile” teams know that visualization of the work itself is a much more useful—and telling—visible tool. Where we must make assumptions and guesses as to behavior in a burndown chart, a simple visible workflow reveals all we need to know about the true state of flow. Perhaps unsurprisingly, “Modern Agile” teams reference Agile principles for guidance – with respect to a burndown chart, instead we might consider: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Starter Agile: Product Backlogs

To consider why product backlogs could be considered “Starter Agile,” I’ll begin with a true story:

Starting work with a new company, I sat down to meet a product owner and get a feel for her personality, perspective on her role, and learn more about her product goals. She was enthusiastic, highly engaged, and proudly shared her roadmap – complete with complex metrics, value propositions… and over 600 backlog items “in priority order.”

A bit later, she cheerily invited me to attend her backlog grooming session. I accepted her offer and observed an hour-long conversation where priorities of items in the range of 200-ish were considered. Beyond wondering how we might decide priority #199 over #200, I glanced at my notes describing the team’s current sprint goal of six items and did the math quickly in my head: “we’re talking about work in the realm of 30 sprints away.”

An extreme example, perhaps. Yet, as a true story, an illustration of how easy it is to treat a backlog as a large batch project. In the case of this story, the validation for such a lengthy backlog was twofold: a repository of ideas (“what if we forget?”) and documentation of conversation (“what do we need to know?”).

The concept of a product backlog is “starter Agile” because it paves the way for teams and product leaders to begin conversations of value. Further, the backlog serves as an important reminder that work can be sliced as necessary and “pulled” by the team. If shared understanding of work is not reached, it cannot start, and a product backlog is highly efficient at answering the question, “should we do X or Y next?” Yet, it’s common that product backlogs become a proxy for project plans hiding the intent to incrementally deliver a pre-planned solution.

“Modern Agile” teams retain a focus on value and priority by practicing Evolutionary Design, which additionally drives down risk and feedback delay. In doing so, such teams abandon big, groomed product backlogs (B.G.P.Ds?) and find better utility with short, concise “to-do” lists. In teams where alignment, communication, and collaboration are high, Josh suggests that we might even do away with lists entirely – “if you remember it, it’s important.” Supported by the practice of “chartering”—where the team continuously inspects the vision and desired outcomes—what’s important stays at the forefront of team members’ minds. In this environment, a conversation is rich and meant to inform… rather than serve as a means to document.

If this feels too radical, remember that people are discovering many ways to achieve great things… some better than others. If not this, what might help your team or organization become more lightweight?

Starter Agile: User Stories

As a case for “Starter Agile”, user stories are a mixed bag. I’ve experienced a few teams that used the story template quite effectively: driving conversations about who customer personas are, empathizing with the value proposition, and engaging in rich discussion to seek clarity.

On the other hand, I’ve seen enough “story for the sake of a story” examples to feel a brief tinge to vomit every time I hear someone use the term. Recalling one such example from a product backlog, the “user story”—complete with a story point estimate, BDD formatted acceptance criteria, and the overhead of admin in Jira—read:

As a developer on the team, I want to fix the bug with XML extract to fix the bug with XML extract.

This example is why “user stories” are well deserving of their “Starter Agile” status. The template has tremendous utility in helping people discover how ineffective (and risk-laden) the practice of formal “requirements analysis” is. Given that old habits die hard, however, the fact that everything prior had to be a requirement does not mean everything must also be a user story!

“Modern Agile” teams are not developing with agility because they leverage user stories, instead, they’re discovering the way forward because they establish shared understanding of real value (emphasis on “real”) and purpose. Josh likes to call this “bargain hunting”: collaborating together to identify what people need and the simplest means to deliver it. Such teams might describe work with user stories, use feature-driven development, job stories, or just simple, concise statements. The differentiating factors are the Agile principles that inform the way the team establishes work, not the fact that work is established with user stories.

I’ll conclude this foray into the realm of “Starter Agile” in tomorrow’s Part 3 post: standup meetings, task decomposition, and cadence-driven retrospective!