Team Resources in Scrum
A scrum team doesn’t work in a vacuum. There’s usually an organization that exists around scrum, and that supports the efforts of the scrum team with the resources it needs to produce the work. There’s a two-way relationship that must be maintained between the scrum team and the rest of the organization, so that each is able to benefit from the process.
Just as the organization and its hierarchy should have no influence on the rituals, artifacts, and roles of scrum, scrum has no formal opinions about how the outer organization is structured. Scrum can exist successfully in a rigidly tiered company with clearly defined titles and roles just as easily as it can work in a “holacracy” (an organization without any formal chain of command). As long as the scrum team is provided with the resources it needs, and can justify its existence by producing the results that the organization wants, the relationship should be maintainable.
There are sometimes different opinions about how the resources a team needs should be provided. An agile approach to working this out is to try one way, notice how well it works, and iterate to find what’s most productive.
In particular, there are a few key resources most scrum teams doing web and mobile development find themselves needing that aren’t formally defined as part of scrum.
A critical input into any web or mobile project is design. Designers help establish the user experience, the flow, and the visual consistency of a project. With the trend toward design thinking as a process, designers have become elemental in all phases of product development, from initial problem definition through wireframing, creating style guides, building graphical assets, validating visual consistency, and doing user experience testing.
Designers work closely with product owners during the development of new stories. In most cases design choices drive ideation, and much of the innovation in how a product evolves iteratively comes from the designer. But designers also need to be available to team members when questions of layout and style come up. Sometimes designers need to be prepared to drop everything and produce assets, or make decisions that are critical to unblock developers in the middle of a story. Switching between high-concept thinking and detailed, hands-on production can make the designer’s role very challenging.
Some teams choose to integrate designers into the team, and include them in all the rituals. The advantage of this approach is that the designer is constantly aware of how the team is working, and able to give immediate feedback by participating during story creation as well as estimation and development. A designer who chooses to work as part of the team should be prepared to commit to the scrum process just like any other team member.
However, unlike most members of a scrum team, a designer is usually not trained or inclined to work as an engineer, or to pair with other engineers on development work. Additionally, the skills and responsibilities of a designer may not lend themselves to paired work with engineers not trained in design themselves. Because of this, a designer who’s integrated into the team may need to be treated differently from other team resources. This can sometimes create a sense of imbalance, leaving the design role feeling poorly integrated.
Another approach that many teams use is to create an extended sprint sequence, with a separate design sprint that precedes the development sprint. This helps isolate the work of designers from the work of engineers, while still keeping designers integrated into the scrum process as members of the team.
Using the design sprint approach can be effective, but it limits the agility of scrum. Because design sprints happen before development sprints, the team is effectively committing to working in increments that are twice as long. This means that the product owner’s ability to adjust requirements needs to be pushed out an additional sprint, so changes need to be planned that much further in advance. For some teams this may be a good solution, as long as they’re prepared to accept the tradeoffs.
A third method worth considering is maintaining a separate Design team, and treating them as a resource. Designers on the Design team can be called upon to participate in the ideation, story creation, asset development, user flow testing, or anything that the scrum process needs. Because the designers are independent of the scrum process, they’re welcome to attend the rituals as guests, but aren’t required to be active participants.
A Design team that operates as an independent resource may choose to structure itself using a different agile approach known as kanban. Kanban is similar to scrum, but instead of operating in sprints with contracted deliverables at predetermined intervals, a kanban team commits to a specified amount of work-in-progress. Kanban teams can accept new stories from the product owner without advance planning, as long as the resources of the team are never committed to more than the amount of work they’re capable of doing sustainably.
The details of kanban are more complex than what we’ve covered here, but it’s another approach worth looking into for organizing work that involves a constant flow of services. In particular, kanban is very effective for managing the workflow of organizations such as Operations and Customer Support, where there’s a steady stream of similar stories that all need to be addressed, and that frequently require rapid response on a priority basis.
Quality assurance is the responsibility of every member of the team, but most organizations have professionals who are specially trained in the techniques of creating and managing test suites. For web and mobile work, this can be an intricate and complex process, involving tools that simulate the behavior of a wide range of devices and browsers, and automation to follow both common and uncommon paths through a product.
QA engineers may be isolated into their own group, working independently of the team doing the development of the product. When this is the case, coordination with the team is critical. Unless QA is taken into account early, a scrum team may find itself rushing to complete stories before the sprint demo meeting, and then dumping a load of work onto the QA team at the last minute, so that stories will be ready to demo.
Not unlike designers, QA engineers are sometimes given a separate sprint to do their testing. This avoids the issue of trying to get the stories verified quickly at the end of every sprint, but it introduces the same kind of reduced flexibility as having a separate design sprint. Further, when it comes time for a demo of the stories, most of the team has already moved on to newer stories, and the details of the previous sprint’s work may not be fresh in their minds.
The biggest problem with isolating QA from development is that engineers feel free to take on the next story on their list before the previous story has been verified as done. Frequently in a web and mobile context, stories will build on each other in subtle ways, even if the stories are technically independent. This can lead to situations where the work on a new story needs to be redone based on inconsistencies found when testing a prior story.
Ideally, QA should be considered part of the team’s definition of “done” for any story. This means that QA engineers should start writing the tests for a story at the same time that developers are creating the code. The QA cycle for a story should be part of the sprint, and the developers working on a story shouldn’t abandon it to start something new until QA has been completed.
On some teams, QA engineers are integrated into the team directly. This provides a number of advantages. The skills and training of development and QA engineers are complementary, and people in both roles can benefit professionally from pairing with each other to learn more about the techniques and approaches they use. A team with integrated QA engineers also naturally considers testing and validation as part of the effort of rendering a story done, and makes sure stories are sized and scheduled appropriately to include that.
The folks who keep the networks running and handle technical support for a company are often part of the same Engineering department that’s the home of the product development team. Because of this, some companies try to integrate the people on these teams into their scrum process. But the structure of the organization shouldn’t influence the needs of a scrum team.
Unless there is a compelling reason, it can be a bad practice to try to integrate Operations engineers into a product development scrum team. While the people in Operations are trained engineers, the responsibilities they handle should live independent of the product development process. Keeping the networks up, the computers running, and the servers online is constant and challenging in a different way than product development. It can be dangerous to confuse these roles.
It’s always important to keep Operations informed as product development progresses, so that any changes in the product that might have an impact on the reliable availability of services and resources can be considered. A good scrum team includes engineers and product owners who can recognize when changes may have an impact on system or network load, and will call in the opinions of qualified Operations engineers to help with planning for a story.
Note: Operations and Pair Programming
It may be impractical to pull Operations professionals away from their duties to pair on development, although it can be useful for developers to pair occasionally with Operations engineers to enhance their understanding of the issues that affect the availability of the product.
One of the benefits of scrum is that teams have the opportunity to self organize and figure out the best way to develop the product iteratively, testing things out, making changes, and improving as they go. What this means is that the team takes responsibility for what they do, and organizes themselves around the goal of completing the work in the most efficient way possible. As a result, sometimes managers can be confused about their role in a scrum organization.
The self-organizing nature of scrum doesn’t have anything to do with the hierarchy of the company that assigns a manager in a different role and a set of responsibilities relative to an employee. Scrum should have no opinion about the hierarchy of the organization, just as the hierarchy of the organization should have no impact on the scrum process.
In any company, management is a vital role. Managers are responsible for hiring, firing, allocating resources, and representing the employees throughout the organization. Without managers, employees would have nobody to turn to in the event that there’s a problem outside the scrum process that needs to be addressed. Managers often have responsibility for the productivity of the team, including reporting results to senior executives, and demonstrating the value of the scrum process as it’s working.
Managers may also participate as developers on a scrum team. Often people in management roles in engineering also have deeper experience with some of the problems the team may be facing. These managers may serve as architects or senior developers, and may have valuable knowledge to share. Within the scrum team, a manager is treated as one of the developers, and given no other authority than any developer on the team.
Tip: Managers as Developers
In some organizations, the role of manager is viewed with disdain. We’ve all seen the image of the pointy haired boss from Dilbert cartoons. One of the advantages of scrum is that it doesn’t care how the manager performs outside of the scrum process, as long as sufficient resources are provided to support a continuing scrum process. An effective scrum team should operate independent of these preconceptions, but the opportunity to work with a manager as a peer on a scrum team can help improve communications outside scrum as well.
Employees on the team who feel uncomfortable about interacting with their manager as a peer, or managers who feel uncomfortable with their reduced authority within scrum, should discuss the issue with the scrum master. A strong scrum master will be experienced in dealing with issues around management and authority, and how it relates to scrum.
The Rest of the World
A scrum team doesn’t operate in a vacuum. Outside the scrum team, there’s an organization that needs a product developed, for whatever reason. Part of the responsibilities of the scrum master is to evangelize the value of scrum to the rest of the company. Along with that comes the responsibility to make sure scrum actually is serving the needs of the company and the constituents of the scrum process.
Among these constituents are senior executives within the company, users of the product being developed, customers who may have commissioned the creation of the product—whether inside the company or outside—and other groups inside the company.
From the outside, scrum can seem like a mystery. Despite the emphasis on transparency, the terminology of scrum can confuse people who aren’t familiar with what the terms actually mean. The artifacts and charts that scrum creates may seem to imply meaning that just isn’t there. Any confusion from outside the scrum team can influence the stability of scrum, both in terms of resources being allocated, and the flow of stories into the process.
One of the most obvious constituents of the scrum team is the set of users the product is being developed to support. The user should be visible in practically every story, even if the story doesn’t affect the front-end interface of the website, or show up on the screen of the mobile device. Administrative users are users. Content managers who populate the product are users. Anyone who interacts with the product is a user.
To the user, the fact that the product was developed with the scrum process is irrelevant. However, user testing is an important part of iterative development. Much of scrum happens in organizations that are using lean development practices. This means starting with a minimum viable product, and then iterating as the user experience testing indicates.
Instrumentation to make sure that user experience can be captured and tracked effectively is usually important for web and mobile products developed with a scrum approach. Without instrumentation to track clicks, gestures, goals, and interactions with critical features, the product owner will have fewer data points for reference when it comes time to decide what stories are most important to work on next. The intent of scrum is to support an agile process that allows quick adjustments in product direction based on real user needs.
The customer for a product being developed with scrum may be a client of the company, or may be an internal department inside the company. Regardless, direct interaction with the customer is the responsibility of the product owner. A strong product owner will shield the team from the customer, and protect the customer from feeling disconnected.
Customers may or may not know what they want. Often a customer will have an idea, and it’ll need to be worked out through the scrum process. This may mean several rounds of work with designers, and perhaps a few iterations through the product development process. As a result, the desired path from vision to reality may not be as straight as a customer may wish. Product owners step in, keeping the customer informed and satisfied, while clarifying the customer’s vision to the point that a team can estimate it and work on it productively.
A good product owner is a strong line of defense between the team and the chaos of direct interaction with the customer. This isn’t an easy role to fill, since the customer is either paying the bills, or working for another department inside the same company. The support of a strong scrum master may be needed to help defend the scrum team. If the team feels they’re getting too much direct influence from the customer—that isn’t properly filtered through the product owner—they should feel free to engage the scrum master to help improve the process.
Executives and Other Employees
A scrum master is both a coach and an evangelist when it comes to the rest of the company. Scrum masters need to be able to represent the power and value of scrum effectively, and explain it in terms that don’t rely on the custom vocabulary of scrum. Not only will the process attract interest from other employees, but also from executives, who will rightly be concerned about the value provided.
Happily, scrum generates a lot of data. Among the artifacts of scrum will be real-world information about how much work the team can do in a given amount of time, how many stories have been completed, what features have been produced, working software to demonstrate, and the feedback of the team, the product owners, and the customers. The scrum master may choose to formulate reports for different audiences, host brown-bag lunches to explain scrum, or invite people to attend scrum rituals to see for themselves what’s going on.
While managers are responsible for securing the resources necessary to support their employees, a scrum master is responsible for getting the buy-in and organizational support for the scrum process. If scrum is running well, everyone on the team will be an evangelist for it. Encourage scrum participants to let other employees know how it’s working. Positive word-of-mouth around the company is good for the careers of everyone on the scrum team, as well as the stability of the scrum process.