The Big Picture of Agile Requirements
- The Big Picture Explained
- Big Picture: Team Level
- Big Picture: Program Level
- Big-Picture Elements: Portfolio Level
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
- This would all be a lot easier to understand if you could just draw me a picture.
- —Anonymous senior executive
Effectively implementing a new set of lean and agile requirements principles and practices in a project team, program, or enterprise is no small feat. Even the language is different and seemingly odd (user stories, sprints, velocity, story points, epics, backlog?). In addition, further "leaning" the organization often requires eliminating or reducing requirements specifications, design specifications, stage-gated governance models (with incumbent requirements reviews), sign-offs (with incumbent delays...), implementing work-in-process limits (which may seem counterproductive to those who measure "utilization"), and so on. So, there will likely be many challenges.
Even for the fully committed, it can take six months to a year to introduce and implement the basic practices and even more time to achieve the multiples of productivity and quality results that pay the ultimate dividends in customer satisfaction, revenue, or market share. To achieve these benefits, we must change many things, including virtually all of our former requirements management practices. However, many of the existing required artifacts, milestones, and so on, serve as safeguards to "help" avoid the types of project problems that software has often experienced. So, we have a dilemma—how do we practice this new high-wire act without a safety net, when the safety net itself is a big part of the problem?
Fortunately, we are now at the point in time where a number of organizations have made the transition before us and some common patterns for lean and agile software process success have started to emerge. In our discussions with teams, managers, and executives during this transition, we often struggled to find a language for discussion, a set of abstractions, and an appropriate graphic that we could use to quickly describe "what your enterprise would look like and how it would work after such an agile transformation."
To do so, we need to be able to describe the new software development and delivery process mechanisms, the new teams and organizational units, and some of the roles key individuals play in the new agile paradigm. In addition, any such Big Picture should highlight the requirements practices of the model, because those artifacts are the proxy for the value stream.
Eventually, and with help from others, we arrived at something that worked reasonably well for its purpose.1 We call it the Agile Enterprise Big Picture, and it appears in Figure 2-1.
)
Figure 2-1 The Agile Enterprise Big Picture
The Big Picture Explained
In this chapter, we'll explain the Big Picture in a summary format intended to provide the reader with a quick gestalt of this new, agile, leaner, and yet fully scalable software requirements model.
In the remaining chapters of Part I of this book, we'll describe the basic big-picture requirements management practices for the individual Team, Program, and Portfolio levels. In Parts II, III, and IV, we'll further elaborate on the requirements management artifacts, roles, and activities at a level of detail suitable for implementation and action.
Big-Picture Highlights
Because this picture serves as both the organizational and process model for our agile requirements practices, we'll have time throughout this book to explore its many nuances. However, from an overview perspective, the following highlights emerge.
The Team Level
At the Team level, agile teams of 7±2 team members define, build, and test user stories in a series of iterations and releases. In the smallest enterprise, there may be only a few such teams. In larger enterprises, groups, or pods, of agile teams work together to support building up larger functionality into complete products, features, architectural components, subsystems, and so on. The responsibility for managing the backlog of user stories and other things the team needs to do belongs to the team's product owner.
The Program Level
At the Program level, the development of larger-scale systems functionality is accomplished via multiple teams in a synchronized Agile Release Train (ART). The ART is a standard cadence of timeboxed iterations and milestones that are date- and quality-fixed, but scope is variable (no iron triangle). The ART produces releases or potentially shippable increments (PSIs) at frequent, typically fixed, 60- to 120-day time boundaries. These evaluable increments can be released to the customer, or not, depending on the customer's capacity to absorb new product as well as external events that can drive timing.
We'll use the generic product manager label as the title for those who are responsible for defining the features of the system at this level, though we'll also see that many other titles can be applied to this role.
The Portfolio Level
At the Portfolio level, we'll talk about a mix of investment themes that are used to drive the investment priorities for the enterprise. We'll use that construct to assure that the work being performed is the work necessary for the enterprise to deliver on its chosen business strategy. Investment themes drive the portfolio vision, which will be expressed in as a series of larger, epic-scale initiatives, which will be allocated to various release trains over time.
In the rest of this chapter, we'll walk through the various elements of the Big Picture to describe how it works. While we'll highlight the requirements value delivery stream, we'll also expose the rest of the picture including the roles, teams, and processes that are necessary to deliver value. In this way, we'll provide a systemic view of our lean and agile requirements process that works for teams and yet scales to the full needs of the enterprise.