Ask anyone that’s worked on an agile team, and they know that when it comes to shipping software being developed on common platforms and derived from well-defined user stories, the process is relatively predictable. Yet, many times your team may have found user stories with as many questions as answers and development solutions that have been previously untested. For moments like these, teams look to utilize “spikes” or “dual-track agile.” Let’s explore both.
As a precursor, it’s useful to identify things that don’t always fit well within traditional Scrum. There are moments when the development team knows the intended results (e.g. we must integrate with an existing eCommerce platform) but doesn’t know exactly which solution to use. This lack of knowledge makes story-pointing difficult and can impact predicted release dates.
Related but different are the tasks that are important to consider but not necessarily green-lit as ready for investment of time or resources. As a very crude example, imagine a team that’s considering whether or not to put a paywall into place on an app. While the development team might quickly focus on how this would be accomplished, other stakeholders would be more concerned whether it should be attempted at all. This exploration and decision-making take time; time that somehow must be accounted for if agile is to yield predictive business value. Simply putting up a paywall could waste critical development time without providing commensurate value.
Thus, these types of activities have two qualities unique from most items in a typical sprint: 1. They do not provide immediate direct value to the work output. 2. They are notoriously difficult to estimate.
Teams that find themselves in this scenario occasionally will handle this challenge via a spike.
Driving a Spike Into Your Sprint
In agile terminology, a spike is research conducted to make the development team smarter about what it will take to implement a user story. Referring to our previous example, the research required to determine which eCommerce platform to utilize would be a typical use case for a spike.
Spikes can be applied to research and investigation or even prototyping. They serve the purpose of reducing technical risk prior to development being undertaken.
If a development team is struggling to determine the subtasks for a story, this is often a sign that a spike is required, creating the necessary time within the schedule for the research to be completed.
Ideally, such spikes are handled within the same sprint as the rest of the story, though if the unknowns are substantial, splitting the user story into multiple sprints and handling the spike first can also be acceptable, particularly if the insights learned from the spike could dramatically impact the overall points of the story.
Too Many Spikes? Consider Dual-Track Agile
Though many organizations find the spike to be an acceptable approach to unknowns, others may find they struggle to implement agile well because of so many elements that are difficult to quantify. Companies that find this to be a common occurrence often consider dual-track agile.
Originally documented in 2005, dual-track agile acknowledges that there are two types of work a cross-functional team is tasked with; completing a product and determining if a product should be brought to market and what makes up its elements.
A very common example would be in scenarios where the UX team wishes to test a wide variety of solutions. Proper UX requires user interviews, conceptual wireframing, AB testing, etc.; precisely the type of work that is both difficult to estimate and to abandon if results aren’t obvious. In this example, there are too many unknowns for the work to be simply story-pointed and placed into the typical sprint.
Organizations that adopt agile for other departments often find similar challenges. At Ascendle, our marketing team frequently considers new initiatives to generate interest and engagement. In many cases (producing this blog post, for instance), such work fits neatly within our sprints. But in cases where we are evaluating new channels for promotion, the work is less easy to define and estimate. Moreover, such research uncovers as many opportunities that will be abandoned as will be pursued.
Companies with this dilemma frequently explore dual-track agile. In dual-track agile, tasks are divided up according to their intended purpose.
Most agile work fits perfectly within the delivery track; items with predictable effort and value that will be completed within the sprint. The second track is reserved for discovery tasks, and the goal is for these items to be made ready so that they can be implemented or abandoned, possibly within the same sprint, but as commonly, not.
Here are some key considerations for those considering dual-track agile.
One Team – Two Tracks
Though there’s no denying that some team members will be drawn to one of the two tracks, it’s important not to lose sight of the power that arises from agile cross-functional teams. If the delivery track is all about uncovering how to complete a task, the discovery track exists to understand why the task should (or shouldn’t) be attempted in the first place, and this insight will provide value to all team members.
Two-Tracks Running Simultaneously
Though there are certainly times when sprints could consist of all delivery or discovery tasks, teams that report the best velocity often operate both tracks simultaneously. This maintains team cadence and momentum and consistently pushes value down the line. Remember: though discovery tasks provide massive long-term value to the business, delivery tasks are the type that delivers incremental value every day. With rare exceptions, organizations that run dual-track agile tend to have both tracks running at all times.
The Discovery Track Runs on Time-Boxing
Fewer sayings are more true in business than, “Creative work is never done. It’s just due.” Discovery tasks are all about accelerated learning; learning as much as possible as quickly as possible. Yet, learning is not a finite activity. Rather, we attain the level of knowledge we think is required to prove or disprove a hypothesis and move on.
This makes acceptance criteria for discovery track items very difficult to ascertain. For this reason, many items within discovery tracks should be time-boxed, according to the parameters of both the task and the sprint as a whole.
Knowledge Not Just for the Sake Of Knowledge
Some organizations, particularly those that value education, are often tempted to include tasks within the discovery channel that aren’t anchored to a user story. This, too, should be avoided. While discovery tasks are difficult to estimate and – in the end – may be abandoned if enough value can’t be estimated, inherently, they have been put into the sprint because there are expectations that user value will emanate from them, eventually. If it’s difficult to determine how value would ever generate from a given task, it likely shouldn’t be placed within the confines of the sprint.
There Are Moments It Will Feel a Little Waterfall-Like, and That’s OK
In the most fully-integrated agile organizations, the yin and yang of discovery and delivery will work together like dance partners, nearly impossible to delineate one from the other. But for the rest of us, it won’t often feel that way.
Many agile organizations with robust UX teams will run a dual-track agile process with the explicit goal of having UX stay just a half-step ahead of software development. Though this is not to suggest that organizations do all UX and then toss the wireframes over the cubicle walls to development, it does acknowledge that a significant amount of UX prototyping ends up on the cutting room floor. If mock-ups were passed to the development team too soon, the amount of waste would significantly impact sprint velocity.
Conclusion: Spikes or Dual-Track Agile
Companies attempting to implement agile can struggle for a number of reasons. Failures of discipline or culture have side-tracked many teams seeking maximum velocity. But once your team has mastered Scrum, it’s more likely that the nature of the work itself will inhibit ability. Organizations that find themselves struggling to fit tasks within an agile framework could be well served by considering either spikes or dual-track agile.
