In the first two parts of this series, I examined two of the three roles of Scrum-the ScrumMaster and the Product Owner-and how they each interact with the framework's other two roles to generate increased productivity. To conclude this discussion, I will turn to the remaining role: the team. Unlike the previous roles, which have both been individuals, the team is, of course, made up of a group of people. As such, it's unique in that responsibilities are distributed among multiple parties in order to successfully deliver a product increment. Just as the entire Scrum team (i.e. the ScrumMaster, Product Owner, and team) must depend upon one another to complete projects, so, too, the development team's members must trust each other to self-organize their way to success. The development team's tight-knit dynamic builds shared accountability and, with every successful project, confidence in one another that culminates when it transforms into ownership. That degree of collaboration is the single most important ingredient in Scrum's ability to boost productivity.
The Team
In Scrum, the team is responsible for completing or burning through work, expressed as product backlog items (PBIs). Where the Product Owner determines vision and negotiates sprint goals and the ScrumMaster enforces the rules of the framework and often acts as the point person for resolving team-based and organizational impediment, the team is tasked with the difficult job of not only getting the work completed, but also figuring out how to do so.
Ideally, teams consist of seven cross-functional members, plus or minus two individuals. Although, recently there have been a few arguments for even smaller teams.
For software projects, a typical team may include a mix of software engineers, business analysts, quality assurance, technical writers and UI designers. What is most important about the team composition is the range of required skills is collectively represented by the team to accomplish whatever tasks the Product Owner may present to them.
Each sprint, after negotiating the PBIs that will be moved into the sprint backlog, the team must determine how it will accomplish the work. In Scrum, this process of the team creating its own plan to complete work is known as "self-organization" and marks a significant departure from traditional project management. It grants teams a great deal of autonomy, but that freedom is accompanied by increased responsibility to meet the goals of the sprint. Thus teams are at liberty to choose how they tackle PBIs, but they must deliver what the Product Owner has asked for, when it is due (POs will inspect what the team has done during the sprint review meetings).
The Team and the ScrumMaster
As discussed in part one, the ScrumMaster's role in relation to the team can be succinctly summarized: He or she usually acts as the point person who tracks impediments that obstruct the team's progress. In addition, he or she ensures that the rules and meetings of Scrum are observed. However, great teams require a great ScrumMaster and the best ones provide much more proactive support for the team than the above description would suggest. The most effective ScrumMasters understand the team is one part of a larger system and, in order to maximize the team's potential for productivity, all of those parts must align. Thus, the ScrumMaster's focus on team impediments and leading the team to follow Scrum is only the tip of the iceberg. Other questions ScrumMasters may want to consider to help their team include:
- How is the Product Owner doing? Is the Product Owner adequately informed about the team's progress and successes, or the impediments and dependencies that obstruct its completion of sprint goals? Does the Product Owner need help articulating requirements, creating stories in the backlog, or prioritizing work? These are all questions that a ScrumMaster needs to be attuned to in order to streamline communication between the team and the Product Owner, while helping them to maintain a high level of productivity.
- How is the team doing? Apart from the impediments and updates that team members explicitly report during daily stand-ups and other meetings, a ScrumMaster can glean a great deal of information about a team just by observing how its members interact. Are they comfortable with one another? Do they crack jokes and enjoy one another's company? Or do they keep to themselves? Do certain team members not get along with others? Examining-and addressing-the psychology of the team is another way that ScrumMasters can spur teams to do their best.
- How are its engineering practices doing? A ScrumMaster can do the team a lot of favors by reminding them at every opportunity of the value of agile engineering practices and thorough testing. Many agile techniques would appear to sap a team's productivity. (For instance, a common misconception of pair-programming is that it assigns two developers to do the work of a single person.) However, these techniques actually build testing and, consequently, risk mitigation into every step of development, which allows teams to accelerate cycle time considerably.
- How is the organization doing? ScrumMasters can even work together to help the organization itself-a much broader definition of "team," certainly-evolve into a more productive and efficient entity. Especially in larger Scrum installations, which often require a Scrum-of-Scrums management architecture, ScrumMasters can meet with one another frequently to discuss those problems that impact the organization as a whole and develop plans to resolve them. Of course, in situations such as these, it is not only the ScrumMaster's team that benefits from their work, but the entire organization.
The Team and the Product Owner
As previously stated, the Product Owner negotiates with the development team to determine what work it will attempt to complete in the next sprint. However, the Product Owner also helps the team maintain a state of productivity by remaining available to answer questions and further clarify acceptance criteria. By now, we understand that Product Owners communicate product vision and goals to team members in the form of PBIs during the sprint planning meeting, but what does that process actually look like?
Most Certified Scrum Trainers (CSTs) would agree that PBIs should be written in user story format. The formulaic wording can be a great guide rail when teams are struggling to articulate exactly what needs to be built and for whom. A simple way to explain user stories is that it is a formulaic phrasing that captures a product increment, using the following format: "As a [role], I want [function] so that [rationale]." There have been numerous books written on the topic and the one that most everyone points to is Mike Cohn's book User Stories Applied. However, PBIs and user stories are not enough. Next, we will need to discuss the single trickiest thing to master once your teams are up and sprinting: defining what it means to be "done." To me, "done" might mean that a piece of software works on my laptop, but "done" to my team member may mean that the same application works for 2,000 simultaneous users. The definition of ‘done' is where scope creep can kill you. It is where individuals who like to gold-plate things can end up in the weeds for days or weeks, and where sophisticated Product Owners can muddy the waters (sometimes on purpose) to leave themselves room to maneuver later. Alert: Team members, if you do not get anything else out of this three part series, understand this. Sometimes, Product Owners will intentionally leave acceptance criteria vague so that they can maneuver within the sprint review meeting. This can get really tricky if your Product Owner is also your boss. Do you call them out on it? What happens if you do? What happens if you don't? It's really safe to assume that most Product Owners are just more skilled at negotiating than most team members. We see this all the time with our politicians. Most politicians would say that we're winning the war on drugs, but fail to answer questions about what their acceptance criteria for success really are.
Empowerment and Productivity
And though both the Product Owner and ScrumMaster help facilitate productivity for the team, what truly empowers Scrum teams to outperform traditional teams is self-organization. The fact is when individuals are vested with more responsibility, they almost always respond by rising to meet the challenge. In Colleen Frye's recent article in Tech Target, "How Teams Transition to Agile Development Methodologies," the author concludes that all of the organizations interviewed for the story had undergone Scrum transformations observed the same result: self-management leads to ownership. Intuit's Basab Dattaray, an engineering manager for the Turbo Tax group who was interviewed for the article, explains, "With Scrum, team members take responsibility and ownership...We don't have anyone hounding people." When team members rely on one another to deliver their share of the work, it yields team members who are engaged in their work and willing to take ownership of the problems they face. When a team is full of such inspired team members, productivity is nearly assured.
However, Scrum's unique potential for productivity occurs over time, as a team has a chance to establish a rhythm and gradually improve itself. Key to this is the retrospective meeting, which occurs at the end of each sprint. When a sprint concludes, the team and the ScrumMaster get together to assess the previous work cadence and discuss what went well, what didn't, and what could be improved for next time. This is an informal and candid opportunity for the team to evaluate its own performance-often without the Product Owner present-and adapt its processes for improvement. The team can enter a state of flow, sometimes called the ‘zone' in sporting events.
Now, any team that worked together over time would naturally develop camaraderie among its members and function at a higher level than, say, a newly formed team. However, retrospective meetings, Scrum's mechanism for incremental team improvement, provide teams with a dedicated time to focus on how it can do its job better. By keeping performance at the front of the team members' minds, Scrum's iterative and incremental lifecycle encourages teams to evolve. Just as features are added to products every sprint, a team accrues skills and experience as its members learn how to best work together. Scrum uses its own metric, called velocity, to gauge how many story points a team can accomplish within a given sprint. The best Scrum teams-those that evolve to perform at higher levels-can demonstrate their increased thresholds for productivity through a velocity that steadily climbs over time.
Pitfalls
In addition to the "definition of done" pitfall outlined above, there are numerous other anti-patterns of which teams should be wary. Although Scrum provides team members with the freedom to choose how they do work (my teams do work on things as they see fit. Very rarely do I get involved on anything at the task level and, if I do, it's usually to clarify a point), sometimes that freedom can be too much. Here's an analogy I use when talking to new recruits.
A friend of mine, who we'll call "Laura," was raised in a strict household with perhaps overbearing parents. When she turned 18, she packed her bags and flew across the country to attend her first year at college. Our alma mater is a liberal arts institution where really everything was "optional." Unlike larger universities, liberal arts programs individualize your learning experiences by encouraging you to take a wide variety of classes spanning multiple disciplines. Laura wasn't ready for this brave new world. She could go to class or she could skip. She could sleep all day or stay up all night. The freedom that this new paradigm offered was too much for her. She was used to strictly enforced 10 PM curfews, homework reviews by parents, and the like. In other words, she had no idea how to function without someone to tell her what to do and when to do it.
Sometimes people aren't ready for the freedom Scrum offers. Some people have had their tasks managed for years and wouldn't even know where to start without knowing their place on the load balancing chart (I'm talking people, not servers here). Or they may be so beat down from the constant supervision that they abuse their newfound freedom by simply doing nothing at all.
Your team may not be ready for self-organization, or it may experience many challenges before seeing the benefits. If you hired someone with the expectation that you'd be telling them how to do their tasks and then you ask them to figure it out on their own, they may not know how to do that and, ultimately, they may leave.
My colleague Dan Rawsthorne, PhD. makes a similar case. He asks the students in his class, "What's your business model? Are you in the business of keeping people busy, or are you in the business of producing product? If you're in the business of keeping people busy, don't bother with self-organization; in fact, don't bother with Scrum. Scrum is about producing product."
Another pitfall is the lack of an established career track for team members. To help avoid this particular pitfall, human resources departments need to develop a strong understanding of Scrum principles and play a role in the transformation process. Usually when I tell people that, they're surprised to hear it, but developing opportunities for professional growth and advancement-within a framework that values teamwork, not individual performance-is necessary for talent retention and satisfaction. Team members are team members, so how can they advance in the organization or earn more money? Those questions should be answered by the human resources department. If you're interested in reading more about Scrum and HR, I recently wrote a piece on the topic for the Scrum Alliance here.
Conclusion
As you can see, the Scrum framework is a carefully constructed system that relies on its own authoritative checks and balances and distribution of labor as much as common sense and human psychology. Not only does every role work to maximize the productivity of the other two, but is, in turn, supported by the other two roles, as well. In the case of the team, it is aided by the ScrumMaster, who helps enforce the rules of the road, encourages the use of agile engineering practices, and radiates metrics, progress, and impediments, and the Product Owner, who articulates the vision for the product to be built. Of course, Scrum's mandate for self-organization also spurs the team to redefine its own standards of productivity. And while the combination of self-organization and retrospective evaluation allows the team to push itself to accomplish great things in the hopes of reaching a state of flow, it's also important to note that the team's sense of autonomy plays a major factor in boosting morale. Rather than reduce a team to ‘resources' capable of little more than carrying out instructions, Scrum recognizes that trusting the team with big decisions has an equally big payoff. Specifically, it gives members of the development team more say in the work they do. No wonder most Scrum transformations start from a bottom-up approach-this is how developers want to work.
About the Author
In August 2000, Laszlo Szalvay founded Danube Technologies, Inc. with his brother Victor in Seattle, Wash. to provide software and training exclusively focused on the Scrum method of agile software development. The company's ScrumWorks® Pro and ScrumWorks Basic products are licensed to more than 105,000 software professionals worldwide, making it the most widely used software in the industry for managing Scrum projects. ScrumWorks Pro recently received a Jolt Productivity Award at the 19th annual Jolt Product Excellence Awards. Danube complements its software offering with a comprehensive schedule of ScrumCORETM training courses, which are taught globally by Danube's five Certified Scrum Trainers.
The company's on-site software delivery model makes it the leading choice for enterprises of all types, including large corporate and government organizations, which require the utmost in security, compliance, ease-of-use and customization. Danube's customers include Adobe, Amazon.com, AMD, F5, General Electric, HP, Intel, Intuit, Kofax, LexisNexis, Microsoft, Motorola, Oracle, QVC, Siemens and Sun Microsystems. Danube is self-funded and has achieved steady organic growth as Scrum has emerged as the preferred agile method for developers and executives. The company is headquartered in Bellevue, Wash. and has a sales office in Portland, Ore. Please visit http://www.danube.com or call (503) 248-0800 for more information on Danube.
