Using a specific example of a traditional Waterfall process, Demand Management, we will demonstrate how your defined processes (with some tweaks) can actually fit directly into the Agile framework.
Before we go too far in discussing how Demand Management is adapted for Agile, we should remember how it works in a Waterfall environment. Demand Management is traditionally comprised of four core capability areas:
Work Intake: A common approach for engaging an organization’s resources (a request).
Estimation: A consistent method of quantifying the resource needs for a request.
Resource and Financial Capacity Management: An organization’s ability to deliver against the demand for its services (requests).
Scheduling: The optimal alignment or allocation of available resources to meet the demand for service.
As we begin to look at Demand Management in an Agile environment, it is critical to understand that the focus shifts from funding and prioritizing individual projects to investing in the full scope of products and value the organization wants to deliver to its customers.
To successfully make the transition, the organization must adapt both its mindset and approach to critical Demand Management activities from the enterprise to the team level.
Making the Transition
So, when teams want to throw frameworks out the window for Agile, how do leaders hang onto their Waterfall processes like Demand Management?
First, it is critical to understand that Agile is not the Wild West. It, too, is a framework in and of itself, with defined processes and methodologies. While most people are familiar with some of the key differences between Agile and Waterfall, including basic nomenclature (e.g., requirements versus user stories), it is important to remember that the approach to delivery, and parties responsible for completing key activities are also changing. This means simply changing the vernacular does not make Demand Management “fit” into an Agile environment. To successfully make the transition, the organization must adapt both its mindset and approach to critical Demand Management activities from the enterprise to the team level.
Let’s walk through those shifts in mindset and how to best implement them in your organization.
Enterprise
At the enterprise level, instead of traditional annual planning, IT and business leaders will come together to define the organization’s strategic initiatives for the next six quarters. These initiatives should be sufficiently high-level to apply across several business units, but specific enough to be measured for success.
At the same time, executives should shift from planning and funding specific, requested projects. Instead, they must focus on defining the value and products they want to continue to deliver to and improve for customers (i.e., value streams).
Now comes the fun part. With funding now viewed as investment potential, executives can focus on answering one question: “Based on the money we have, what products do we want to invest in to provide increased value to our customers?”
The answer depends on aligning strategic initiatives with the value streams to determine how much capital the organization wants to devote to each of those products (aka value streams). While on the surface this may sound straightforward and similar to how organizations distribute funding today, doing it correctly will feel very different than normal annual planning. For example, these planning sessions should now involve both business and IT together and should extend beyond the Executive teams and include individuals from the delivery teams.
With the firm’s priorities and its focus defined for the next six quarters, the individual IT delivery (scrum) teams within those value streams are now responsible for collaborating with the business to define the work they can commit to completing (epics) based on available team resources and their average velocity (throughput).
However, as the business reviews and revalidates priorities and strategic initiatives every few quarters, it has newfound flexibility to reallocate investments and stay ahead in a competitive environment.
These two concepts—funding initiatives over projects and including delivery teams in strategic planning—may seem unorthodox. But bringing those responsible for completing the work to the table earlier in the process improves engagement level, sets expectations, and builds trust between IT and the business.
This decentralized approach to Demand Management is a key component to an Agile environment, as it offers individuals completing the work the opportunity to influence it.
Team
In addition to a new seat at the enterprise table, individual teams that have migrated to an Agile delivery model carry an approach to Demand Management through to their own processes. As mentioned previously, Demand Management has four key components: work intake, estimation, capacity management, and scheduling.
In an Agile world, during every sprint, the individual scrum teams go through their own set of ceremonies that align very closely to those key Demand Management components.
- Work intake becomes backlog grooming.
As the work is defined during strategic planning sessions into larger epics, the team works with their product owner to break those larger bodies of work into features and even more discrete user stories. With an increased understanding of the business initiatives, the product owner then prioritizes the next set of stories the team will tackle (that is, he or she “grooms the backlog”).
- Estimation becomes story point estimation.
Once the team has agreed on the next set of priorities, they will use their own estimation technique (T-shirt sizing, poker, etc.) to assign a certain number of story points to each of the user stories.
- Capacity management (purely resource based) becomes previous velocity scores, plus story-point poker, plus the team calendar.
Once the team has assigned the requisite points to all the queued user stories, the scrum master reviews the proposed stories and their points against the team’s velocity—the average number of points a team completes within a sprint.
This number effectively represents the team’s velocity and serves as the baseline against which all sprints are planned and commitments are made. The scrum master can modify the velocity if he or she knows an individual will be out of the office for a week. This helps identify how many stories the team can safely commit to and further helps set priorities and manage dependencies.
- Scheduling equals continuous integration.
Teams should focus on continuous integration. This technique regularly combines all the work each scrum team within the delivery stream has completed to deliver a full piece of functionality to the business. As the teams and the organization mature, the firm may introduce continuous deployment.
Tying the Two Together
First, understand that moving toward Agile may not be as scary as you originally thought, but will still take time and the right mindset and buy-in across the organization. Many of the activities completed under a Waterfall approach continue to occur; while frequency, terminology, and ownership may change.
Next, begin to hold conversations with the appropriate parties in your organization to determine “how much” Agile is right for you. Agile is not an all or nothing framework and can be adapted to fit your organization, but everyone needs to be aligned on what that means. The business and IT must have strong communication, alignment, and participation to gain the true value of this framework.
Once your organization agrees on what Agile means, begin to transform the way planning occurs at the enterprise level. Move away from funding based on requests or ideas. Transition toward investments based on expected value.
Finally, begin to consider what this transition means for your people. How do titles or role expectations change? What resources does the organization need—or no longer need? These conversations will clarify how Agile looks in your organization.
