How does managing requirements differ in an Agile environment versus a mixed-methodology environment?
The term "Agile environment" means different things to different teams, but for most teams, it means that the development team has adopted Agile practices, even though the rest of the business is working "the same way it always has." In a mixed environment, this is also true -- except that only some of the development teams have started using Agile processes for delivering software -- while other teams continue to use Waterfall practices. This is a common scenario when a team or two are piloting Agile for the rest of the organization, or when a company has grown through acquisition or when a particular team just "goes Agile" of its own accord.
In terms of managing requirements, doing it well should happen in effectively the same way when working with teams using either delivery cadence. At a high level, the process of managing requirements looks like a series of steps:
- Do market research - collecting data about your market.
- Analyze that data - generating insights about the customers in that market.
- Synthesize that data - forming hypotheses about the relative importance of solving the problems that exist in your market, and the feasibility of solving them, and creating a product roadmap that articulates which problems you will solve, for whom and in what order.
- Analyze that product roadmap - refining and creating a more detailed view of the problems that will be solved next, while waiting until "the last responsible moment" to work out the details of the problems that will be solved "next."
Those are the same steps to use, regardless of what your development team's cycle time of delivering may be.
When working with a team that uses an Agile process, they will be delivering their results every couple of weeks (anywhere from days to months, but one to four weeks is the most common) and asking for more requirements every couple of weeks. A Waterfall team may ask every three, six, twelve or more months -- but they effectively do the same thing.
While either development team is building software, a product manager should continue to be performing the "four steps," and be continually getting "smarter" about what is important to deliver. A product manager will likely re-order the list of "what's next" problems to solve -- and typically add and remove some items as well. This part is exactly the same. Sometimes, something that the team already has in-process needs to be changed.
With an Agile team, barring "emergencies," allow them finish whatever needed to be changed, and then "what's next" is the requirement to change it. The premise is that the small loss of efficiency in having to rework something like this is smaller than the cost of disrupting the team mid-cycle to "stop everything" and fix things the instant the product manager knows it is wrong. With a Waterfall team, the same consideration is made, but the reverse conclusion is usually reached -- that "fixing it later" would cause unanticipated and expensive delays, and that it is "less costly" to disrupt the team and fix it now.
My experience is that the cost of disrupting teams -- and in heavily bureaucratic organizations, the cost of getting approvals, "horse-trading" for scope, etc., -- is high. The cost of "throwing away work" is very small, in comparison to the cost of ignoring what you've learned. These experiences bias me towards working in smaller increments, avoiding the "big bang" delivery cycles, and "getting smarter" collectively (in terms of what we're doing) as quickly as possible after "getting smarter" individually (in terms of knowing what to do).
Dig Deeper on Topics Archive
Related Q&A from Scott Sehlhorst
Application performance monitoring fixes a system before it breaks. IT strategist Scott Sehlhorst offers insight into preventive performance testing. Continue Reading
'Continuous development' is still a relatively new and confusing term. Find out what it means beyond the hype. Continue Reading
Scott Sehlhorst offers strategic guidance on how to approach application portfolio management with a focused vision. Continue Reading