Gathering and managing software project requirements
A comprehensive collection of articles, videos and more, hand-picked by our editors
Dual-track development was a new term to me when I heard Agile coach Aaron Sanders use it in a recent conversation about his upcoming presentation, "Before You Test Your System, Test Your Assumptions," at the STARWEST 2014 conference.
Dual-track Agile development is both a concept and a set of practices designed to prevent the most fundamental software development problem of all: Delivering software that doesn't do what its intended audience wants it to do. Dual-track Agile development is a method of repeatedly testing to confirm you have the requirements right by releasing code and conducting mini focus groups, making adjustments along the way.
Aaron SandersAgile coach
"We are continuously learning while continuously building," Sanders told me.
This edition of Quality Time looks at some of Sanders' ideas about dual-track development and seeks to explain what he means when he says software professionals should test their assumptions before they test their code.
The "dual" in dual-track development
Sanders said dual-track Agile involves two parts -- discovery and delivery. Project managers can think of these two parts as phases, but sometimes they happen simultaneously.
Discovery is about questioning and testing every assumption you have about the project. Assumptions typically arise from a documented set of requirements and from conversations that take place between software developers and line-of-business professionals engaged in the project.
Delivery is about continually releasing pieces of code and refining them based on feedback. This could mean releasing each iteration of a feature to actual users and working their suggestions into upcoming versions.
At the outset of a dual-track development project, the project manager goes on a mission to determine what's really true. His or her job is to make sure the team is building the right application -- the one that's needed, not the one that somehow made its way into the project's official requirements.
Sanders offered an example. A client he worked with planned to develop a mobile application that would provide business travelers with weather information. The first assumption of said application is that business travelers want to know the weather forecast for their intended destination. The requirements document listed other assumptions about the mobile application for business travelers, including points of interest, turn-by-turn directions, alerts about bad weather and percent of users affected by bad weather.
Sounds like a perfectly reasonable set of requirements and a decent application, doesn't it? But when tested, each one of these assumptions turned out to be completely false. "Business travelers could care less about the weather," Sanders said. They cared about flight delays -- information they already had easy access to on other applications.
A better project, the team found, was a weather application for commuters who travel 10 or more miles to work each way. They wanted two things -- the weather along their route and radar animation depicting the movement of a rain storm, for example.
Discover the truth
To pinpoint false assumptions, project managers should implement a discovery process. Sanders' client engaged a marketing agency to do that. But even with a discovery budget of $0, a development team can find out who the target users are and what kind of problems they are trying to solve, he said. "You go out and talk to people at the mall, at Starbucks." And if the application in question is intended for employees, not customers, you can take the same approach within your company.
Sanders recommends pairing up for this discovery exercise; one partner talks while the other takes notes. In the course of an hour, a team of 20 software professionals can speak with 40 target users. Ideally, the development team amasses a group of target users they can turn to for feedback as they begin to release software, which addresses the delivery aspect of dual-track Agile.
It's important to involve the whole team in the process, Sanders said. "The goal is to develop a shared understanding of the most important features."
None of the steps in dual-track development are particularly difficult to implement. But undertaking this new approach is daunting because it requires software professionals to behave in unfamiliar and unexpected ways. Developers should question everything they think they know and hear about the application under development. Research what target users really want and sell the idea back to powers that be.
Is your team ready for dual-track Agile? Let us know what you think.
The Agile enterprise needs Agile requirements models
Agile software development tutorial: Agile requirements gathering