Why the Focus on Scaled Agile Teams?
As we dive into the realm of software requirements, one might question the need to commence with a thorough examination of the organization, roles, and responsibilities within a Scaled Agile team. The essence of Agile diverges so drastically from traditional methodologies that we are compelled to reevaluate the foundational practices of software development. For many, embracing Agile entails questioning the prevailing organizational structures, reassessing relationships among team members, and even reconfiguring reporting structures.
More significantly, in the Agile world, the organization of requirements and the team itself are inextricably linked. Gone are the days of large batches of pre-defined requirements tossed “over the wall” to developers who implement them based on various organizational methods. Instead, Scaled Agile teams now rally around requirements to maximize efficiency in defining, constructing, and testing code that brings value to end-users.
The entire Scaled Agile team is deeply involved in defining requirements, optimizing requirements and design trade-offs, implementing them, testing them, integrating them into a new baseline, and ensuring they are delivered to customers. This singular focus defines the Agile team’s purpose.
To better understand the team organization challenge, let’s explore the task of “producing working code within a timebox” and examine what kind of organization might excel at this.
The fundamental work unit for the team is the User Story. The team aims to define, build, and test a certain number of User Stories within an iteration, achieving even greater value throughout a release. Each Story has a brief yet highly concentrated development life cycle, ideally followed by a lengthy stay in a software baseline that provides user value for years to come.
Upon arrival, a story may already have some elaboration from previous iterations or be a mere placeholder for a task to be determined later. However, at the iteration boundary, the time for action is now. Each story follows the same pattern: define the story, write the code and test, and run the test against the code. These steps occur simultaneously, which we call the define/build/test sequence. This process is concurrent, collaborative, and atomic—done completely or not at all.
Nonetheless, even an atom has its components, and ours include:
- Define: The developer may need to engage with the product owner to comprehend the story’s intent, even if it is well-elaborated. A design may already exist in the developer’s mind; if not, one will be swiftly generated and communicated to the product owner, peer developers, and testers. We use “define” to convey that this function is a blend of requirements and design, inseparable and meaningless without the other.
- Build: New insights may emerge as the story’s code is written. Conversations will likely occur between the developer, product owner, and other developers and testers. The story’s understanding evolves throughout the coding process.
- Test: A story is deemed complete only after an acceptance test, ensuring the code fulfills the story’s intention. Developing functional acceptance tests (alongside unit tests) before or while writing the code further tests the team’s understanding of the story.
This process occurs every day, in real time, and multiple times a day for each story in the iteration.
How could such a process function in a traditional environment where a product owner or manager may be absent or assigned elsewhere? How could it work if the developer is involved in multiple projects or works part-time “on assignment” from a resource pool? How could it work if test resources are not dedicated and available when the code is written? The answer is it doesn’t.
It becomes evident that we must restructure our organization to achieve agile efficiency. We must organize around the requirements stream and build teams that can fully define, build, test, and accept stories into the baseline daily.
Why do we focus on teams? It’s because teams are the foundation of agile development, and only by understanding their roles, responsibilities, and interdependencies can we unlock the true potential of the agile methodology. Agile development revolves around collaboration and communication, and the team breathes life into this concept.
By placing the team at the center of our approach, we foster a culture of collaboration, accountability, and adaptability that empowers the team to respond quickly and effectively to evolving requirements and user needs. In essence, the agile team becomes the beating heart of software development, fueling the continuous delivery of value to end-users.
As we continue our journey through software requirements, let us keep the team at the forefront of our minds, embracing the agile mindset and continually seeking ways to optimize our work together. With the right team structure in place, we can tackle the challenges of agile development head-on and create software that genuinely serves its users and stands the test of time.
Breaking Down Functional Silos
Regrettably, many of us work within organizational structures that do not embody the agile spirit. Instead, we are often organized into functional silos, which inhibit collaboration and hinder our ability to adapt quickly to change.
Developers collaborate primarily with their fellow developers, while product management, business analysts, and program managers are grouped, often reporting to entirely different departments. In larger organizations, architects may work together to promote common architectures across business units but may lack a strong connection with the development teams. Product owners may not even exist, or if they do, their roles as product managers leave them stretched thin and unavailable, causing the team to stall as they await answers. Testers will likely report to and be co-located with a separate QA organization rather than development.
Why are we organized this way, and how can we shift our perspective to bring about meaningful change? Agile development calls for reevaluating what constitutes a team and demands dismantling silos that separate essential functions.
By starting with the “why,” we can inspire a new way of thinking about team organization that prioritizes collaboration, communication, and adaptability. As we break down these functional silos, we can empower our teams to work more efficiently and effectively, seamlessly integrating their expertise and skills to create solutions that truly serve our users and stand the test of time.
In pursuing a more agile organization, let us embrace the power of unity and strive to eliminate the barriers that have historically held us back. As we forge new connections and nurture a shared vision of success, we can unlock the full potential of our teams and drive lasting, meaningful change in how we approach software development.
Scaled Agile Team Roles and Responsibilities
Thankfully, although restructuring our organizations may seem daunting, the fundamental organizational structure of agile teams remains consistent, providing us with a clear objective to strive for.
In the Scrum framework, for example, there are three key roles within an agile project team: the product owner, the Scrum Master, and the team members, who are primarily developers and testers responsible for writing and testing code.
Product Owner
The product owner holds a crucial position in the Scaled Agile team, as they are primarily responsible for defining and prioritizing requirements. Their primary responsibilities include:
- Collaborating with product managers, business analysts, customers, and other stakeholders to determine requirements
- Managing the backlog and setting priorities based on user value
- Establishing objectives for each iteration
- Elaborating on stories, participating in progress reviews, and accepting new stories
Scrum Master
Scrum specifies this role distinctly and offers specialized training and a specific title (Scrum Master) for those who assume it. Regardless of the method, the Scrum/Agile Master is responsible for:
- Facilitating the team’s progress towards goals, challenging old norms of development while keeping the team focused on the iteration’s objectives
- Leading the team’s continuous improvement efforts, helping them take responsibility for their actions and become problem solvers
- Enforcing the rules of the agile process, reinforcing the lightweight and flexible rules with the team
- Eliminating impediments, addressing blocking issues beyond the team’s authority, or requiring support from other teams to maintain focus on the iteration’s objectives
Developers
Developers are responsible for writing the code for each story. Their responsibilities include:
- Collaborating with product owners and testers to ensure the right code is developed
- Writing the code
- Writing and executing unit tests for the code
- Creating methods to support automated acceptance tests and other testing automation
- Checking new code into the shared repository daily
Additionally, developers actively participate in improving the development environment.
Testers
Testers play an integral role in every agile team, participating from the beginning of the code development process and continuing throughout the release process. Their workflow parallels that of the developer:
- Writing the acceptance test case while the code is being written
- Interfacing with the developer and product owner to ensure the story is understood and that acceptance tests align with the story’s desired functionality
- Testing the code against the acceptance test
- Checking test cases in the shared repository daily
- Developing ongoing test automation to integrate acceptance and component tests into the continuous testing environment
Additional Scaled Agile Team Roles
In addition to the primary roles within an agile team, there are other roles and shared resources that collaborate and interface with the team members, including:
- Architects: While many agile teams do not have members with “architect” titles, architecture remains crucial to agile teams. In these instances, the team typically determines local architecture through a collaborative model, such as components, services, or features, allowing for the “emergence” of architecture from team activities. At the system level, architecture is often coordinated among system architects and business analysts responsible for the system’s overall structure, use cases, and performance criteria. As a result, agile teams are likely to have a key interface with one or more architects who may reside outside the team.
- Quality Assurance (QA): QA plays a unique role in agile, as the primary responsibility for quality shifts to the agile team (developers and testers). Many QA personnel reassume their original role, overseeing overall system-level quality while remaining one step removed from daily team activities. Some QA personnel will work outside the team, while others (mainly testers) may join the product team, working daily with developers to test new code and ensure real-time code quality. Additionally, QA personnel contribute to developing system-level testing to assure overall system quality and conformance to both functional and non-functional requirements.
- Other Specialists and Supporting Personnel: Additional supporting roles may include user experience designers, documentation specialists, database designers and administrators, configuration management, build and deployment specialists, and any other roles necessary for developing and deploying a complete product solution.
By embracing collaboration and adaptability, agile teams can efficiently and effectively integrate individual expertise and skills, ultimately creating solutions that genuinely serve users and withstand the test of time.
User Stories and the Team Backlog
Scaled Agile teams must maintain the utmost efficiency to ensure overall organizational effectiveness. To achieve this, we must adopt the simplest and leanest possible requirements model that caters to the needs of all stakeholders, especially team members. This model must be quintessentially agile, consistent with most agile training and common practice, and devoid of unnecessary administrative overhead, manual traceability, reporting, or detailed requirements.
Backlog
Initially introduced by Scrum as a product backlog, the term “backlog” has evolved in our enterprise model to accommodate various levels of work. As a result, we use the term backlog in a more generalized sense. In the Big Picture, we refer to the backlog we’re discussing here as the Scaled Agile team’s local backlog.
This local backlog is the Scaled Agile team’s single, definitive source of work, containing all tasks (primarily user stories) that must be completed. Managed and maintained by the team, it serves as their repository for all identified work items, with its contents typically of little concern to others within the enterprise. The team has full autonomy over managing, tooling, and organizing their backlog to meet their iteration objectives.
The product owner, a Scaled Agile team member, is responsible for maintaining and prioritizing the backlog.
The Scaled Agile team’s backlog consists of all the team’s identified work items. In the meta-model, we generically refer to these work items as stories (or backlog items). For our purposes, we define a story as follows:
A story is a work item contained in the team’s backlog.
This simple definition encapsulates the agile approach’s focus on value delivery. The user story is a special kind that defines the system’s behavior and value for the user. We need to expand the model slightly to make the user story explicit.
With this minor addition, the backlog now consists of user stories and other work items. Other work items include refactors, defects, support and maintenance, tooling, and infrastructure work. These other work items help the team track all tasks needed to deliver value and enable better estimation of the time required to deliver user stories. We will discuss the rationale for specifically identifying these other work items later.
User Story Fundamentals
User stories are the agile alternative to traditional software requirements statements (or use cases in RUP and UML), serving as the backbone of agile development. Initially developed within the framework of XP, they are now a staple of agile development in general and are covered in most Scrum courses.
We can define a user story as:
A user story is a concise statement of intent that outlines what the system needs to do for the user.
Typically, user stories follow a standard (user voice) format:
As a <role>, I can <activity> so that <business value>.
This format encompasses elements of the problem space (the delivered business value), the user’s role (or persona), and the solution space (the activity the user performs with the system). For example:
“As a Salesperson (<role>), I want to paginate my leads when I send mass e-mails (<what I do with the system>) so that I can quickly select a large number of leads (<business value I receive>).”
Tasks
To ensure that teams fully comprehend the work required and can meet their commitments, many agile teams adopt a detailed approach to estimating and coordinating individual work activities necessary to complete a story. This is done through tasks, which we’ll represent as an additional model element:
Tasks implement stories. Tasks are the smallest units in the model and represent activities specific team members must perform to achieve the story. In our context:
A task is a small unit of work essential for completing a story.
Tasks have an owner (the person responsible for the task) and are estimated in hours (typically four to eight). The burndown (completion) of task hours indicates one form of iteration status. As suggested by the one-to-many relationship shown in the model, even a small story often requires more than one task, and it’s common to see a mini life cycle coded into a story’s tasks. Here’s an example:
- Story: Select a photo for upload
- Task 1: Define acceptance test—Josh, Don, Ben
- Task 2: Code story—Josh
- Task 3: Code acceptance test—Ben
- Task 4: Get it to pass—Josh and Ben
- Task 5: Document in user help—Carly
In most cases, tasks are “children” of their associated story (deleting the story parent deletes the task). However, for flexibility, the model also supports stand-alone tasks and tasks that support other team objectives. This way, a team need not create a story to parent an item like “install more memory in the file server.”
Acceptance Tests
Ron Jeffries, one of the founders of XP, devised a memorable way to think about user stories. He used the catchy alliteration of card, conversation, and confirmation4 to describe the three aspects of a user story.
- Card refers to the two or three sentences that convey the story’s intent.
- Conversation involves elaborating on the card’s intent through discussions with the customer or product owner. In other words, the card also signifies a “commitment to a conversation” about the intent.
- Confirmation is the process by which the team, via the customer or customer proxy, determines that the code fulfills the story’s entire intent.
Note that stories in XP and Agile are often manually written on physical index cards. However, agile project management tools usually capture the “card” element as text and attachments in the enterprise context. Still, teams frequently use physical cards for planning, estimating, prioritizing, and visibility during daily stand-ups.
This straightforward alliteration and Agile’s passion for “all code is tested code” demonstrates how quality is achieved during code development rather than afterward.
The SAFe Requirements model represents the confirmation function as an acceptance test verifying that the story has been implemented correctly. To distinguish it from other acceptance tests (a term frequently overused in software), we’ll refer to them as story acceptance tests and consider them an artifact separate from the (user) story itself.
There are numerous reasons for this decision, which we won’t delve into here. Regardless, the model is explicit in its insistence on the relationship between the story and the story acceptance test as follows:
- In the one-to-many (1..*) relationship, every story has one (or more) acceptance tests.
- It’s done when it passes. A story cannot be considered complete until it has passed the acceptance test(s).
Acceptance tests are functional tests that confirm the system implements the story as intended. Story acceptance tests are automated whenever possible to prevent the creation of many manual tests that would quickly hinder the team’s velocity.
Unit Tests
To further ensure quality, we can supplement acceptance tests with unit tests.
Unit tests verify that the smallest module of an application (a class or method in object-oriented programming; a function or procedure in procedural programming) functions as intended. Developers create unit tests to check that the code executes the logic of the specific module. In test-driven development (TDD), the test is crafted before the code. Before a story is complete, the test should be written, passed, and incorporated into an automated testing framework.
Mature agile teams employ extensive practices for unit testing and automated functional (story acceptance) testing. Moreover, for those in the process of implementing tools for their agile project, adopting this meta-model can provide inherent traceability of story-to-test without burdening the team. Real Quality in Real Time
The fusion of crafting a streamlined story description, engaging in a conversation about the story, expanding the story into functional tests, augmenting the story’s acceptance with unit tests, and automating testing are how Scaled Agile teams achieve top-notch quality during each iteration. In this manner: Quality is built in, one story at a time. Ongoing quality assurance is accomplished through continuous and automated execution of the aggregated functional and unit tests.