- 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
Big Picture: Team Level
Figure 2-2 summarizes the Team level of the Big Picture.
)
Figure 2-2 Team level of the Big Picture
The Agile Team
)
The "front line" of software development consists of some number of agile teams that implement and test code and collaborate on building the larger system. It's appropriate to start with the team, because in agile, the team is the thing, because they write and test all the code that delivers value to the end user. Since it's an agile team, each has a maximum of seven to nine members and includes all the roles necessary to define/build/test2 the software for their feature or component. The roles include a Scrum/Agile Master, product owner, and a small team of dedicated developers, testers and (ideally) test automation experts, and maybe a tech lead.
In its daily work, the team is supported by architects, external QA resources, documentation specialists, database specialists, source code management (SCM)/build/infrastructure support personnel, internal IT, and whoever else it takes such that the core team is fully capable of defining, developing, testing, and delivering working and tested software into the system baseline.
Since testing software is integral to value delivery (teams get no credit for untested code), testers are integral to the team. Often the testers are logically part of the QA organization but are physically assigned and dedicated to an agile team. In this matrix fashion, their primary allegiance is to the team, but as members of the QA organization, they can leverage other QA teammates and managers for skills development, automation expertise, and any specialty testing capabilities that may be necessary at the system level. In any case, it must be clear that the agile team itself is responsible for the quality of their work product and that responsibility cannot be delegated (or abrogated!) to any other organization, in or out of house.
Teams are typically organized to deliver software features or components. Most enterprises will have a mix of both types—some component teams focused on shared infrastructure, subsystems, and persistent, service-oriented architectural components and some feature teams focused on vertical, user-facing, value-delivery initiatives. Agile teams are self-organizing and reorganize when necessary based on the work in the program backlog. Over time, the makeup of the teams themselves is more dynamic than static—static enough to "norm, storm, and perform"3 for reasonable periods of time and dynamic enough to flex to the organization's changing priorities.
Pods of Agile Teams
)
In addition, within the larger enterprise, there are typically some number (three to ten) or so of such teams that cooperate to build a larger feature, system, or subsystem (the program domain in the Big Picture). Although this isn't a hard or fast rule, experience has shown that even for very large systems, the logical partitions defined by system or product family architecture tend to cause "pods" of developers to be organized around the various implementation domains. This implies that perhaps 50 to 100 people must intensely collaborate on building their "next bigger thing" in the hierarchy, which we'll call a program. As we'll discover later, this is also about the maximum size for face-to-face, collaborative release planning.
Of course, even that's an oversimplification for a really large system, because there are likely to be a number of such programs, each contributing to the portfolio (product portfolio, application suite, systems of system).
Roles in the Agile Team
Product Owner
)
As we have described, Scrum is the dominant agile method in use, and the product owner role is uniquely, if arbitrarily, defined therein. In Scrum, the product owner is responsible for determining and prioritizing user requirements and maintaining the product backlog. Moreover, even if a team is not using Scrum, it has been our experience that implementing the product owner role—as largely defined by Scrum—can deliver a real breakthrough in simplifying the team's work and organizing the entire team around a single, prioritized backlog.
But the product owner's responsibilities don't end there. In support of Agile Manifesto principle #4—Business people and developers must work together daily throughout the project—the product owner is ideally co-located with the team and participates daily with the team and its activities.
Scrum/Agile Master
)
For teams implementing Scrum, the Scrum Master is an important (though sometimes transitional4) role. The Scrum Master is the team-based management/leadership proxy whose role is to assist the team in its transition to the new method and continuously facilitate a team dynamic intended to maximize performance of the team.
In teams that do not adopt Scrum, a comparable leadership role typically falls to a team lead, an internal or external coach, or the team's line manager. As their skills develop, many of these Agile Masters become future leaders by illustrating their ability to deliver user value and by driving continuously improving agile practices.
Developers and Testers
)
The rest of the core team includes the developers and testers who write and test the code. Since this is an agile team, the team size is typically limited to about three to four developers plus one to two testers, who are (ideally) co-located and work together to define, build, test, and deliver stories into the code baseline.
Iterations
In agile development, new functionality is built in short timeboxed events called iterations (sprints in Scrum). In larger enterprises, agile teams typically adopt a standard iteration length and share start and stop boundaries so that code maturity is comparable at each iteration-boundary system integration point.
Each iteration represents a valuable increment of new functionality, accomplished via a constantly repeating standard pattern: plan the iteration, build and test stories, demonstrate the new functionality to stakeholders, inspect and adapt, repeat.
The iteration is the "heartbeat of agility" for the team, and teams are almost entirely focused on developing new functionality in these short timeboxes. In the Big Picture, the iteration lengths for all teams are the same since that is the simplest organizational and management model. Although there is no mandated length, most have converged on a recommended length of two weeks.
Number of Iterations per "Release"
A series of iterations is used to aggregate larger, system-wide, functionality for release (or potential release) to the external users. In the Big Picture, we've illustrated four development iterations (indicated by a full iteration backlog) followed by one hardening (or stabilization) iteration (indicated by an empty backlog) prior to each release increment.
This pattern is arbitrary, and there is no fixed rule for how many times a team iterates prior to a potentially shippable increment (PSI). Many teams apply this model with four to five development iterations and one hardening iteration per release, creating a cadence of a potentially shippable increment about every 90 days. This is a fairly natural production rhythm that corresponds to a reasonable external release frequency for customers, and it also provides a nice quarterly planning cadence for the enterprise itself.
In any case, the length and number of iterations per release increment, and the decision as to when to actually release an increment, are left to the judgment of the enterprise.
User Stories and the Team Backlog
)
User stories (stories for short) are the general-purpose agile substitute for what traditionally has been referred to as software requirements (the stuff in the middle of the iron triangle of Chapter 1).
Originally developed within the constructs of XP, user stories are now endemic to agile development in general and are typically taught in Scrum, XP, and most other agile implementations. In agile, user stories are the primary objects that carry the customer's requirements through the value stream—from needs analysis though code and implementation.
As opposed to requirements (which by common definition represent something the system must do to fulfill a business need or contractual obligation), user stories are brief statements of intent that describe something the system needs to do for some user. As commonly taught, the user story often takes a standard user-voice form of the following:
- As a <user role>, I can <activity> so that <business value>.
With this form, the team learns to focus on both the user's role and the business benefit that the new functionality provides. This construct is integral to agile's intense focus on value delivery.
Team Backlog
The team's backlog (typically called a project or product backlog) consists of all the user stories the team has identified for implementation. Each team has its own backlog, which is maintained and prioritized by the team's product owner. Although there may be other things in the team's backlog as well—defects, refactors, infrastructure work, and so on—the yet-to-be-implemented user stories are the primary focus of the team.
- Identifying, maintaining, prioritizing, scheduling, elaborating, implementing, testing, and accepting user stories is the primary requirements management process at work in the agile enterprise.
Therefore, we will spend much of the rest of this book further describing processes and practices around user stories.
Tasks
For more detailed tracking of the activities involved in delivering stories, teams typically decompose stories into tasks that must be accomplished by individual team members in order to complete the story. Indeed, some agile training uses the task object as the basic estimating and tracking metaphor.
However, the iteration tracking focus should be at the story level, because this keeps the team focused on business value, rather than individual tasks. Tasks provide a micro–work breakdown structure that teams can use (or not) to facilitate coordinating, estimating, tracking status, and assigning individual responsibilities to help assure completion of the stories—and thereby—the iteration.