6
Team and Technical Agility
“Continuous attention to technical excellence and good design enhances agility.”
—Agile Manifesto
The team and technical agility competency describes the critical skills and Lean-Agile principles and practices that high-performing Agile teams and teams of Agile teams use to create innovative business solutions for their customers.
Why Team and Technical Agility?
Agile teams and Agile Release Trains (ARTs) create and support the business solutions that deliver value to customers. Consequently, an organization’s ability to thrive in the digital age depends entirely on whether its teams can quickly deliver innovative solutions that reliably meet customer needs. The team and technical agility competency is the cornerstone of business agility and consists of three dimensions (Figure 6-1).
Figure 6-1. The three dimensions of team and technical agility
Agile teams. High-performing, cross-functional teams anchor the competency by applying effective Agile principles and practices.
Teams of Agile teams. Agile teams operate within the context of an ART, a long-lived team of Agile teams that provides a shared vision and direction and is ultimately responsible for delivering solutions.
Built-in quality. All Agile teams apply practices to create high-quality, well-designed solutions that support current and future business needs.
These three dimensions are complementary and help shape the high-performing teams that power the Scaled Agile Framework (SAFe) and, ultimately, the entire enterprise. Each of these dimensions is further discussed next.
Agile Teams
The first dimension of the team and technical agility competency is Agile teams. The Agile team is the basic building block of Agile development—a cross-functional group of 5 to 11 individuals who can define, build, test, and deliver an increment of value in a short timebox. These teams have the authority and accountability to manage their own work, which increases productivity and reduces time to market. Agile teams commit to developing in small batches of work, which allows them to shorten feedback cycles and adjust to changing needs. They can be software, hardware, business, operations, or support teams. Or they can be a cross-cutting team of multiple disciplines.
Although organizations have traditionally been organized for functional excellence, value delivery spans across functional silos. Therefore, Agile teams are cross-functional, with all the people and skills needed to deliver value in short iterations, avoiding handoffs and delays (Figure 6-2). Each team member is dedicated to a single team. This reduces the overhead of multitasking and provides a single-minded purpose to achieve the team’s goals.
Figure 6-2. Agile teams are cross-functional
Agile teams in SAFe have two specialty roles:
The Product Owner (PO) is responsible for managing the team backlog, ensuring it reflects the customer’s needs. This includes prioritization and maintaining the conceptual and technical integrity of the solution’s features and components.
The Scrum Master is a servant leader and coach for the team, instilling the agreed-to Agile process, removing impediments, and fostering an environment for high performance, continuous flow, and relentless improvement.
Team Backlog
The team backlog contains user and enabler stories. It may include other work items as well, representing all the things a team needs to do to advance their portion of the system.
User stories are the primary means of expressing needed functionality. Because they focus on the user as the subject of interest, and not the system, user stories are value-centric. To support this, the recommended form of expression is the user-voice format, shown here:
As a (user role),
I want (activity) to,
so that (business value)
This user-voice format guides teams to understand who is using the system, what they are doing with it, and why they are doing it. Applying this format tends to increase the team’s domain competence; they begin to better grasp the real business needs of their user. Stories may come from the team’s local context; however, they also typically result from splitting business and enabler features (Figure 6-3). Features are further described in Chapter 7, Agile Product Delivery.
Figure 6-3. Stories typically originate from splitting business and enabler features
In addition, enabler stories describe the work needed to build the architectural runway, which supports the efficient development and delivery of future business features.
These may include items such as exploration, architecture, refactoring, infrastructure, and compliance concerns.
To achieve flow, the team backlog must always contain some stories that are ready to be implemented without significant risk or delay. This is accomplished by frequently refining the backlog. Backlog refinement looks at upcoming stories (and features, as appropriate) to discuss, estimate, and establish an initial understanding of acceptance criteria.
Also, as multiple teams refine their respective backlogs, new issues, dependencies, and stories are likely to emerge. In this way, backlog refinement helps surface problems of understanding or challenges with the current plan.
SAFe Teams Typically Blend Agile Methods
SAFe teams use Agile practices of choice based primarily on Scrum, Kanban, and quality practices derived, in part, from Extreme Programming (XP) (Figure 6-4).
Figure 6-4. SAFe teams typically blend Agile methods
Scrum is a lightweight, team-based process that fosters fast feedback and quick, iterative development of the solution. In Scrum, teams define, build, test (and where applicable, deploy) functionality in short sprints (iterations).
To assure throughput and continuous flow, most teams integrate the best practices of Kanban with Scrum to visualize their work, establish Work In Process (WIP) limits, and illustrate bottlenecks and opportunities for improving throughput. Teams whose work is more active and demand-based often choose Kanban as their primary practice. However, they still plan in cadence with other teams and typically apply the Scrum Master and Product Owner roles (or equivalents) for consistent operation within the ART.
Estimating Work
Agile teams use story points to estimate their work. A story point is a single number that represents a combination of qualities.
Volume. How much is there?
Complexity. How hard is it?
Knowledge. What’s known?
Uncertainty. What’s unknown?
Story points are relative, without a connection to any specific unit of measure. The size (effort) of each story is estimated relative to other stories, with the smallest story assigned a size of one. A modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) is applied to reflect the inherent uncertainty in estimating, as the size get larger. (e.g., 20, 40, 100).1
1. Mike Cohn, User Stories Applied: For Agile Software Development (Addison-Wesley, 2004).
Iterating
Agile teams work in iterations, which provide a regular, predictable planning, development, and review cadence. This ensures that a full Plan–Do–Check–Adjust (PDCA) cycle is executed as quickly as possible. Each iteration is a standard, fixed timebox, which is typically one to two weeks.
These short time periods help the team and other stakeholders regularly test and evaluate the technical and business hypotheses in a working system. Teams integrate their code frequently throughout the iteration. Each iteration also anchors at least one significant, system-level integration point. This event, known as the system demo, assembles various system aspects—functionality, quality, alignment, and fitness for use—across all the teams’ contributions.
Planning the Iteration
The iteration starts with iteration planning, a timeboxed event of four hours or less (for a two-week iteration). During planning, the team does the following:
Reviews, refines, and estimates stories, which are typically presented by the PO
Defines the acceptance criteria
Splits larger stories into smaller ones where necessary
Determines what they can deliver in the upcoming iteration, based on their known velocity (story points per iteration), into iteration goals
Commits to a short set of iteration goals
Some teams further divide stories into tasks, estimating them in hours to better refine their understanding of the work ahead.
Even before iteration planning starts, Agile teams prepare content by refining the team backlog. Their objective is to better understand the work to be delivered in the upcoming iteration.
Coordinating with Daily Stand-Up Events
Each day, the team has a Daily Stand-Up (DSU) to understand where they are, escalate problems, and get help from other team members. During this event, each team member describes what they did yesterday to advance the iteration goals, what they are going to work on today, and any blocks they are encountering. The DSU should take no more than 15 minutes and typically occurs standing before the team’s Kanban board (or electronic equivalent for distributed teams).
But team communication does not end there, as team members interact continuously throughout the iteration. Facilitating such communication is the main reason why teams should be collocated whenever possible.
Delivering Value
During the iteration, each team collaborates to define, build, and test the stories they committed to during iteration planning, resulting in a high-quality, working, tested system increment. They deliver stories throughout the iteration and avoid ‘waterfalling’ the timebox. These completed stories are demoed throughout the iteration. Teams track the iteration’s progress and improve the flow of value by using Kanban boards and the DSU.
To ensure they are solving the right problem, teams apply design thinking and customer centricity (see Chapter 7). To build the system right, teams also apply built-in quality practices, which are described later in this chapter.
Improving the Process
At the end of each iteration in Scrum, the team conducts an iteration review and an iteration retrospective. During the iteration review, the team’s increment of stories is demoed for that iteration. This is not a formal status report; rather, it’s a review of the tangible outcomes of the iteration. Teams also conduct brief retrospectives—a time to reflect on the iteration, the process, things that are working well, and current obstacles. Then the team comes up with improvement stories for the next iteration.
Teams of Agile Teams
The second dimension of the team and technical agility competency is teams of Agile teams. Even with good, local execution, building enterprise-class solutions typically requires more scope and breadth of skills than a single Agile team can provide. Therefore, Agile teams operate in the context of an ART, which is a long-lived team of Agile teams. The ART incrementally develops, delivers, and (where applicable) operates one or more solutions (Figure 6-5).
Figure 6-5. Agile Release Trains develop, deliver, and support one or more solutions
ARTs align teams to a common business and technology mission. Each is a virtual organization (typically 50 to 125 people) organized around the enterprise’s significant value streams and existing solely to realize the promise of that value by building solutions that deliver benefit to the end user.
The ART applies systems thinking (SAFe Principle #2) and organizes around value (SAFe Principle #10) to build a cross-functional organization optimized to facilitate value flow from ideation through deployment and release and into operations. This creates a far leaner organization, one where traditional daily task and project management is no longer required. Value flows more quickly, with a minimum of overhead.
In addition to the Agile teams, the following roles help ensure successful ART execution:
Release Train Engineer (RTE) is a servant leader who facilitates program execution, impediment removal, risk and dependency management, and continuous improvement.
Product Management is responsible for ‘what gets built,’ as defined by the vision, roadmap, and new features in the program backlog. They are responsible for defining and supporting the building of desirable, feasible, viable, and sustainable products that meet customer needs over the product-market lifecycle.
System Architect/Engineering is an individual or team that defines the overall architecture of the system. They work at a level of abstraction above the teams and components and define Non-Functional Requirements (NFRs), major system elements, subsystems, and interfaces.
Business Owners are key stakeholders of the ART and have ultimate responsibility for the business outcomes of the train.
Customers are the ultimate recipients of the solution’s value.
In addition to these critical ART roles, the following functions can often play an essential part in ART success:
System Teams typically assist in building and supporting DevOps infrastructure for development, continuous integration, automated testing, and deployment into the staging environment. In larger systems they may do end-to-end testing, which cannot be readily accomplished by individual Agile teams.
Shared Services are specialists—for example, data security, information architects, Database Administrators (DBAs)—who are necessary for the success of an ART but cannot be dedicated to a specific train.
All the teams on the ART apply the same iteration cadence and duration to synchronize their work, so that they can plan, demo, and learn together, as illustrated in Figure 6-6. This provides the objective evidence that the whole system is iterating. This alignment also enables teams to independently explore, integrate, deploy, and release value, as further described in Chapter 7, Agile Product Delivery.
Figure 6-6. Agile Release Trains build, deliver, and support significant solutions
Built-in Quality
Built-in quality is one of the SAFe core values, as well as the third dimension of the team and technical agility competency. All Agile teams—software, hardware, business, and others—must create quality solutions and define their own built-in quality practices. These practices directly affect their ability to deliver predictably and meet commitments. The following quality practices apply to all types of Agile teams, both business and technical.
Establish Flow
To develop and release high-quality work products quickly, Agile teams operate in a fast, flow-based environment. Creating flow requires eliminating the traditional start-stop-start project initiation and development process, along with the phase gates that hinder progress. Instead, teams visualize and limit WIP, reduce the batch sizes of work items, and manage queue lengths (SAFe Principle #6). They also base milestones and measures on an objective evaluation of working systems (SAFe Principle #5).
Teams build a Continuous Delivery Pipeline (CDP) to guide new pieces of functionality from ideation to on-demand releases of value to the end user. Unlike traditional project management, where success is measured by completing an entire initiative, small features flow through the system quickly to provide feedback and allow course correction.
Peer Review and Pairing
Peer review and pairing help ensure built-in quality during development. Peer review provides feedback on another team member’s work. Pairing is when two or more team members work on the same item simultaneously.
Some teams primarily use peer reviews for design-level feedback and pair during development when addressing a challenging problem or performing an activity that requires diverse skills; other teams pair work more frequently or even continuously. Each of these practices builds in quality by leveraging the knowledge, perspectives, and best practices from others. They also raise and broaden the skillset for the entire team, as people learn from each other. Regardless of the approach, all artifacts are subject to multiple sets of eyes and perspectives before being accepted or released.
Collective Ownership and Standards
Collective ownership means that anyone can change an artifact to enhance the system or improve its quality. This reduces dependencies between and within teams and ensures that a team member’s absence doesn’t block progress. But because the work is not ‘owned’ by one team or individual, standards are required to assure consistency, enabling everyone to understand and maintain the quality of each work product. Standard peer reviews and lightweight governance help assure that individuals don’t make a local change that has an unintended, system-level consequence.
Automation
To increase speed, accuracy, and consistency, Agile teams automate repetitive, manual tasks. Teams typically automate in two ways.
Automate the processes that build, deploy, and release the solution. This approach takes the teams’ raw artifacts (e.g., code, models, images, content) and generates production-ready versions as necessary, integrates them across teams and ARTs, and makes them available in a production environment.
Automate quality checks in the CDP to ensure standards are followed, and artifacts meet agreed upon quality levels (e.g., unit and integration tests, security, compliance, performance).
Definition of Done
Agile teams develop a Definition of Done (DoD), which is a standard way to ensure that artifacts and larger increments of value can be considered finished only when they demonstrate the agreed level of quality and completeness. For example, the following might be a few DoD conditions:
Acceptance criteria have been met.
Tests are automated.
All tests have been passed.
NFRs have been met.
No must-fix defects.
Relevant documentation updated.
These DoD agreements align teams around what quality means and how it’s built into the solution.
Additional Technical Practices
To continually improve the solution under development, additional quality practices for software teams can also be applied. These are summarized here with links provided for further reading:
Agile architecture.2 This supports Agile development practices through collaboration, emergent design, intentional architecture, and design simplicity.
Agile testing.3 In Agile testing, everyone tests. Solutions are developed and tested in small increments, and teams apply test-first and test-automation practices.
Test-Driven Development (TDD).4 This philosophy and practice recommends building and executing tests before implementing the code or a component of a system.
Behavior-Driven Development (BDD).5 This test-first, Agile testing practice helps assure built-in quality by defining and automating the testing of the full functionality of the solution. It also serves as a method for determining, documenting, and maintaining requirements.
Refactoring.6 This activity updates and simplifies the design of the existing code or a component without changing its external behavior.
Spikes.7 This is a type of exploration enabler story in SAFe. Spikes are used to gain the knowledge necessary to reduce risk, better understand a requirement, or increase the reliability of a story estimate.
2. https://www.scaledagileframework.com/agile-architecture/
3. https://www.scaledagileframework.com/agile-testing/
4. https://www.scaledagileframework.com/test-driven-development/
5. https://www.scaledagileframework.com/behavior-driven-development/
Summary
Although organizational hierarchies and organization by function provide time tested structures, practices, and policies, they simply can’t provide the speed and quality needed for the digital age. In contrast, team and technical agility focuses on organizing cross-functional Agile teams, and teams of agile teams that apply the best of Agile methods and techniques, without being bound to any one specific Agile way of working. This approach creates long lived teams that apply built-in quality practices throughout the product lifecycle; they learn together and grow together.
Further, these teams form cross-functional teams of Agile teams (ARTs) that are aligned along the enterprise value streams and are thereby able to cover the full development lifecycle, from inception, to deployment and production.
These teaming constructs help instantiate the second operating system, which gives the enterprise the resiliency and adaptability it needs to deliver value directly, with far fewer dependencies, handoffs, and delays. The result is more innovative business solutions, delivered to the market more quickly than ever before.