Continuous attention to technical excellence and good design enhances agility.
Team and Technical Agility
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 high-quality solutions for their customers.
It is one of the seven core competencies of the Lean Enterprise, each of which is essential to Business Agility.
Why Team and Technical Agility?
Agile teams and teams of Agile teams create and support the business solutions that deliver value to the enterprise’s customers. Consequently, an organization’s ability to thrive in the digital age is entirely dependent on the ability of its teams to deliver solutions that reliably meet a customer’s needs. The team and technical agility competency is the real cornerstone of Business Agility. It consists of three dimensions, as illustrated in Figure 1.
- Agile Teams – High-performing, cross-functional teams anchor the competency by applying effective Agile principles and practices.
- Team of Agile Teams – Agile teams operate within the context of a SAFe Agile Release Train (ART), a long-lived, team of Agile teams that provides a shared vision and direction and is ultimately responsible for delivering solution outcomes.
- Built-in Quality – All Agile teams apply defined Agile practices to create high-quality, well-designed solutions that support current and future business needs.
Agile teams create an environment that maximizes innovation, value delivery, and sustainability. Teams unite around a shared purpose and apply a Lean-Agile, flow-based delivery model. ARTs provide the structure needed to align multiple teams to a common mission. Built-in quality guarantees that team members have the skills and practices to create the best possible solutions. These three dimensions are complementary and dependent forces that shape the high-performing units that power SAFe and, ultimately, the entire enterprise.
The Agile team is the basic building block of Agile development. It is the first dimension of this competency. The SAFe Agile team is a cross-functional group of 5-11 individuals who can define, build, test, and deliver an increment of value in a brief 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 small batches of work, allowing them to shorten feedback cycles and adjust to changing needs.
Although originally envisioned for software teams, the Agile Manifesto’s values (Figure 2) and principles have proven invaluable in guiding the creation of high-performing teams of all types in technology and business. Its insights, shown below, apply to and will benefit any type of team:
- Be collaborative
- Ship frequently
- Use objective measures for progress
- Interact with customers frequently
- Expect and support change
Many other disciplines have already successfully applied the Manifesto to their domains, including hardware development, marketing, and supply chain management, to name a few.
While organizations commonly align for functional excellence, value delivery spans functional silos. Therefore, all Agile teams are cross-functional, with all the people and skills needed to deliver value across traditional organizational silos, largely eliminating handoffs and delays (Figure 3). Individual members are committed full time to one team, which reduces multiplexing, reduces overhead, and provides singleminded purpose.
Agile teams have two specialty roles (Figure 4). The Product Owner defines Stories (along with other team members) and prioritizes the team backlog to streamline the execution of program priorities, while also maintaining the conceptual and technical integrity of the Features or components the team is responsible for. 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.
Agile teams have all the skills necessary to define, build, test, and deploy value in short iterations. They are empowered, collaborative, and focused on shared goals. To deliver and sustain value to customers, they can be software teams, hardware teams, business teams, operations teams, support teams, or a cross-cutting team of multiple disciplines.
Typically, Agile teams employ a blend of Agile methods, including Scrum, XP, and Kanban. Most configure their work events using the following Scrum practices:
- Work in short iterations, typical two-week
- Break work into small user stories managed in team backlogs
- Plan the work together for the upcoming iteration
- Have Daily Stand-Up (DSU) meetings to communicate and assess progress towards iteration goals
- Demonstrate working solutions continuously, or at the end of each iteration
- Discuss how to improve the process before starting the iteration cycle
To optimize flow, teams visualize and manage their work progress using a Kanban system. Kanban boards help teams identify bottlenecks to improve flow and limit work-in-process (WIP) to ensure teams finish work before starting new stories. An example appears in Figure 5 below.
Teams of Agile Teams
Building enterprise-class solutions typically requires more scope and breadth of skills than a single Agile team can provide. No lone team has the capacity to build and deliver large systems within a reasonable timeframe. And significant systems require a broad range of specialty skills that cannot be contained within a single Agile team. Therefore, multiple Agile teams must collaborate. SAFe’s Agile Release Train (ART) is a long-lived team-of-Agile-teams, which—along with other stakeholders—incrementally develops, delivers, and where applicable operates, one or more solutions (Figure 6).
Organized around the enterprise’s value streams, ARTs align teams to a common business and technology mission. They exist to realize the promise of value by building and delivering solutions that benefit the end user. In order to ‘build and run’ significant systems, ARTs require broad skills, including operations, supply chain, security, compliance, product marketing, distribution, training, support, legal, finance, licensing, product management, R&D, procurement, contracts, suppliers, manufacturing, and engineering. These members may form their own teams, join other teams, or function as a Shared Service (specialty roles, people, and services required for value delivery, but are not required full-time on any one team). Wherever they appear, all are members of the ART and participate in all ART events and commit to the ART’s plans and deliverables with other members.
The SAFe core value of Alignment ensures that teams work toward a common objective and to create value together. Short iterations provide a regular heartbeat that synchronizes all work and events. Like Agile teams, ARTs plan together, commit together, execute together, and retrospect together.
The ART focuses on fast execution and value delivery. To ensure it creates the right value, the ART aligns to the portfolio vision, and through it, to the Enterprise strategy. This connection of strategy to execution permits decentralized decision-making and allows the ART to achieve its intended purpose with near autonomy.
Alignment with the portfolio, however, requires constant engagement with the portfolio stakeholders responsible for the direction of the train. Business Owners are involved in ART events and continuously provide guidance, communicating back to the rest of the portfolio about where the train is headed and why.
Built-in Quality powers the lean goal of delivering value in the shortest sustainable lead time. It should be no surprise, then, that it’s 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, or other—must create quality solutions and define their own built-in quality practices. Work quality also directly affects the ability to deliver predictably and meet commitments. To avoid rework and delays, quality must be ‘built into’ value creation, not ‘inspected in’ later. In addition, by working in small batches, different individuals in cross-functional teams will be able to update work artifacts frequently. To support their ‘collective ownership’ of artifacts, code, and other content, Agile teams adhere to standards and processes. They also continually improve their product quality through refactoring and by reducing technical debt.
The remainder of this section presents general quality practices that apply to all types of Agile teams. For more information, SAFe’s Built-in Quality article describes software and hardware development quality practices. And several SAFe Advanced Topics articles discuss quality practices, including:
- Agile Architecture
- Agile Testing
- Behavior-Driven Development
- Test-Driven Development
Non-development teams can use these articles as guidance on best practices to adopt for their discipline and work products.
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 incumbent phase gates that hinder progress. Instead, teams visualize and limit work in process (WIP), reduce the batch sizes of work items, and manage queue lengths (SAFe Principle #6). They also base milestones and measures on objective evaluation of working systems (SAFe Principle #5).
Teams build a Continuous Delivery Pipeline (CDP) to shepherd new pieces of functionality from ideation to an on-demand release of value to the end user. Unlike traditional project management, where success is measured by completing an entire initiative on time and on budget, Agile teams quickly release small, Minimal Marketable Features (MMF) to learn and adapt. Small features flow through the system quickly to provide feedback and allow course correction.
Peer Review and Pairing
Peer review and pairing create built-in quality during development. Peer review provides feedback on another team member’s WIP before release. When pairing, two or more team members work on the same item together. Both create and maintain quality because the work will contain knowledge, perspectives, and best practices from multiple members. They also raise and broaden the skillset for the entire team as teammates learn from each other.
Teams often apply both practices, with some teams pairing frequently. Other teams use reviews for feedback and pair when addressing a challenging problem or performing an activity that requires diverse skills. Regardless of the approach, all artifacts are subject to multiple sets of eyes and perspectives before ever being accepted or released.
Collective Ownership and Standards
Collective ownership means that anyone can change an artifact to improve its quality. This reduces dependencies between and within teams, and ensures that a member’s absence doesn’t block progress.
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. Standards also provide lightweight governance to help assure that individuals don’t make a local change that has an unintended, system-level consequence.
Agile teams automate repetitive, manual tasks to increase speed and ensure they are performed accurately and consistently. Teams typically automate in two ways.
- They automate the processes that build, deploy, and release the solution. This process takes the teams’ raw artifacts (code, models, images, content, etc.), generates production versions as necessary, integrates them across teams and ARTs, and makes them available in a production environment.
- They automate the quality checks along this path to ensure standards are followed, artifacts meet quality levels (e.g., broken link and spelling checkers), etc.
Some disciplines have products that provide these types of automation (e.g., software development, content creation, and publishing). However, these solutions are rarely complete and almost always require some form of scripting or development. In the spirit of cross-functional teams and ARTs, it’s common to see software developers join non-software teams and ARTs to support their automation needs.
SAFe’s Systems Team supports teams and ARTs by developing and maintaining many of the automation practices discussed here. Those Systems Team members have prior experiences automating in multiple domains and provide a unique perspective on the approach and the technology needed to support automation goals.
Definition of Done
Agreeing on a ‘Definition of Done’ (DoD) is a standard way to ensure that artifacts and larger increments of value can only be considered finished when they demonstrate the agreed level of quality and completeness. Teams and ARTs use the DoD to ensure they agree on and follow a common set of practices when completing work. For example, a few DoD conditions might be to:
- Require work to be peer-reviewed
- Show all quality tests passed successfully (ideally automated)
- Ensure that all associated files have been checked-in and delivered
- Ensure all versions have been generated and published
- Check that email notifications have been sent
These agreements align teams around what quality means and how it is built into the solution.
The team and technical agility competency is one of the seven core competencies of Business Agility. It is the fundamental principle on which Agile development is based. Only by creating high-performing teams and ARTs, that apply built-in quality practices, can true value be delivered quickly and reliably to customers. To promote Business Agility, teams and ARTs must cross the traditional boundaries of development and engage everyone responsible for defining, deploying, maintaining, and evolving critical business solutions.
Learn More Manifesto for Agile Software Development. http://agilemanifesto.org/.  Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.  Beck, Kent. Test-driven Development: By Example. Addison-Wesley. 2000
Last update: 24 September 2019