Starter Agile, Pt. 1

After sharing my thoughts on the insights Josh Kerievsky offers us through the lens of “Modern Agile,” I had a few readers request some insight into why I selected certain practices as “Starter Agile.” The comments walked the line between curiosity and concern, the latter being something I want to help alleviate.

Over the next three days, I’ll discuss nine practices and concepts that could be considered outdated as people continue to learn and experiment with Agile. I argue these topics have transitory value for brave folk learning Agile; a good place to get started… but others have discovered better ways exist.

Today’s first set of practices: timeboxes, story points, and velocity.

Starter Agile: Timeboxes

Perhaps the definitive practice that people most associate with Agile: working within timeboxes (i.e., sprints or iterations). There may be no practice or concept that most defines Agile as a total “replacement” to traditional, phased systems of work.

Connecting a two-week sprint, for example, to Agile principles is quite easy: reduce batch size to increase the delivery of value, cut complexity, encourage collaboration, and amplify feedback loops.  The concept of the timebox is not the sticky point.

Instead, it’s the ease in which a timebox is easily subverted by using familiar phased behaviors (mini-waterfalls), specialist thinking, and turning a blind eye to existing dysfunction(s). Further, if something is finished early in a sprint, it tends to wait until the end of the sprint for delivery.

Assuming teams are able to avoid the pitfalls above, timeboxes are “Starter Agile” because they’re unnecessary to capture the beneficial principles of Agile. In my experience, teams working in sprints grow to understand that they can plan for a single backlog item, finish it, and then pull in another based on remaining time. In learning to work according to a smooth “flow,” teams increase their forecast accuracy, highlight the importance of small tasks, and adjust perceptions about sprint goals (features tend to be added, rather than dropped from the plan). Long sprint planning sessions become a thing of the past.

“Modern Agile” teams prefer a continuous system of work: free from timeboxes, they work together to create a “smooth flow” of valuable work, pay heed to their work-in-process (WIP), and take time to plan at the last responsible moment. Without the pressure of an artificial (yet self-imposed) deadline, i.e., the end of a sprint, technical practices flourish and attention to delivery mechanisms becomes essential.

Starter Agile: Story Points

I see no reason to light the #NoEstimates fuse here, but there exists no shortage of folk lamenting the world of software estimation. Perhaps this is one of the drivers for “story points” to be prevalent in many Agile teams I’ve observed. In moving away from absolute estimates, which are easily converted to deadlines when misapplied, to relative estimation practices like “points”, teams begin to look at their work as a range of effort.

Truth: even in activities that are intuitive and familiar, it is still nearly impossible to exactly estimate even the most simple of tasks. Especially in software development, seemingly alike tasks are a distribution of time (almost certainly not normally distributed) to complete with non-uniform output. In other words, if programming tasks seem similar, the similarities end there. Using “points” allows us to easily assign a number that represents such a distribution (and even allow for overlap among points).

However, assuming a team is focused on real value, story points are “Starter Agile” because of their relationship to the pursuit of value: waste. Nothing about using points helps teams deliver value and, given the context of a team’s domain, there are many ways to plan without using estimates at all. “Modern Agile” teams have discovered that essential conversations about work do not require assigning points (e.g., playing “planning poker”). Instead, they focus on gaining clarity of work together, collectively shaping work into small, valuable feedback and learning loops – sans estimate. Given a “Modern Agile” team is fixated on the core value of “Deliver Value Continuously”, anything that doesn’t directly support the creation of value is scaled back.

A simple way to draw a comparison: A “Starter Agile” team asks, “How big is this?” to assign a relative estimate. A “Modern Agile” team asks, “Is this small enough?” to deliver and learn rapidly.

Starter Agile: Velocity

It’s easy to see where velocity was intended as a benevolent, data-driven method of forecasting work with minimal impact on a team’s time. Give them a lightweight means of estimating in ranges (e.g., “points”), allow work to reach a “done” state in timeboxes, and simply extend the average points completed over time to discover what sprint the work is most likely to be done. Not useful for short-term planning (where variance is far more disruptive), but one can see the potential for longer-term forecasting. It sure beats a “death march!”

Well, perhaps if we worked with machines, not humans. See, humans have this wonderful tendency to be… human. Unfortunately, velocity is genuine “Starter Agile” due to two basic aspects of being a human being: predictability and semantics.

First, our longing for predictability. By visually projecting the pace of work and forecast completion point, it’s both desirable and intuitive to feel a sense of control and order – however fragile the reality may be. For people who have traditionally worked according to deadlines and estimates, a “completion date” forecast with teams’ velocity may be irresistible to treat as a deadline… especially with the lure of being “data driven” (despite a lagging indicator).

Lastly, the semantics of the word “velocity” make it exceptionally well suited for exploitation in the name of performance. If you happen to see the workplace as a series of resources, inputs, and outputs, the appeal to “increase velocity” might be an irresistible carrot dangling in front of the proverbial machine. Further, despite being a simple concept representing a gauge or point in time, the emotions evoked by the word “velocity” could cause some to associate it with a success factor, instead. It’s this emotional response that makes velocity oft subjected to Goodhart’s Law and rarely used per its (debatable) utility.

I argue a “Modern Agile” team works in time horizons that make velocity useless, even if treated with care and attention. By incorporating behaviors like “bargain hunting” and Evolutionary Design, such teams rarely work according to a project container (take a set of features from 0% to 100% complete), where velocity might be a perceived need.

 

This exploration of “Starter Agile” continues in Part 2: burndown charts, product backlogs, and user stories!