Daily Standup Withdrawal in Scrum Teams

By Stacia Viscardi

There’s a terrible affliction that seems to be going around many Scrum teams. Its symptoms are easy to recognize: glassy eyes, pale skin, robotic answers, and narcoleptic episodes during and immediately following daily standup meetings. Soon, the entire daily standup meeting has become infected. The good news is, this syndrome can (and should) be prevented.

When I’ve been called in to diagnose and treat daily standup withdrawal (DSW), I begin by observing an actual daily standup. In most cases, I observe that the meetings have denigrated to “status report” meetings where individual members “give status” to the ScrumMaster, the ScrumMaster writes everything down, and everyone else drools on the table. Not surprisingly, the goal then becomes to make this meeting as short and sweet as possible.

Many teams really, truly believe that the purpose of the daily standup* is to “just answer the three questions without exceeding fifteen minutes.” Maybe it’s that the questions (what did you do yesterday, what will you do today, what obstacles are you facing) seem so simple. They are not. There is so much underneath the surface of the three little questions. Coach your team to think about these questions and come prepared to the daily standup (see sidebar articles “The Power of Knowledge” and “Seven Fundamentals for Effective Daily Standups”). In other words, think about the tasks, the accomplishments, how it may impact John’s work or Mary’s next task, and keep in mind who you are working with to complete the task. Go into the daily standup with answers to the three questions that are meaningful, insightful, and proactive.

Continue reading this article

Scrum Smells: Loss of Rhythm

By Mark W. Randolph

Importance

Very high

Symptoms

Lack of rhythm has a variety of odors, all related to inconsistency:

• Daily Scrum ritual is inconsistent or is drifting (subtly changing)
• Daily Scrums are skipped or meeting times vary
• Sprint durations are inconsistent or change arbitrarily mid-sprint
• Sprint planning ritual is inconsistent or drifts
• Sprint planning meetings are skipped

Discussion

Rhythm helps make routine things routine. Consider the daily Scrum. Intent is communicated, priorities set, plans laid, results delivered. No announcements, no agendas, no minutes, no paper. That daily Scrum rhythm allows teams to avoid daily noise and focus on delivery. Not bad for fifteen minutes a day.

Establishing rhythm is like feeding chickens on a farm. When the chickens learn they get fed in the morning at the porch, you no longer have to go to the coop, they come to you. You have established credibility with the chickens. They trust they will be fed where and when you want to feed them, and they'll eat what you give them.

To use a negative example, when sprint duration varies, teams have a harder time selecting the right amount of work for the sprint backlog. This, in turn, makes predictions less accurate. When promised results are not displayed or results are not proven, then the chickens start to peck. Trust me on that. They will start to peck.

Analysis

Daily Scrum ritual is the clear responsibility of the ScrumMaster, so why is that responsibility not being met?

• Does the ScrumMaster know what to do? Has the ScrumMaster been trained?
• Has the ScrumMaster set expectations for the daily Scrums? For example:
  • Everyone comes every day.
  • Scrums always start exactly on-time, and never last longer than fifteen minutes.
  • Everyone answers three questions: what has been accomplished since last time, what will be done today, what obstacles were encountered.
  • Problem solving occurs outside the daily Scrum.
  • External stakeholders may attend but not participate.
  • We don’t sit down.
• Are these rules enforced?
• Is ScrumMaster influence being undermined from outside the team, for example:
  • Are project managers permitted to appeal for exceptions?
  • Are supervisors allowed to make extraneous assignments?

The monthly sprint planning ritual is also the responsibility of the ScrumMaster, but because external stakeholders are involved, it can be harder for a ScrumMaster to control dynamics. Nonetheless, analysis can start with the same questions:

• Has the ScrumMaster been trained? Does the ScrumMaster know what to do?
• Has the ScrumMaster set expectations for sprint planning with the stakeholders?
  • Ideas, requirements, even unreasonable demands—they all go on the backlog.
  • These things only come off the backlog at sprint planning.
  • Sprint planning occur without fail every ___ (pick a period up to, but not beyond, three months).
  • Sprint planning always includes evaluation, stakeholder input, retrospection, planning.
  • External stakeholders (should, are expected to, are required to—pick the phrase that applies) attend evaluation and stakeholder input portions of sprint planning.
  • Retrospection and sprint planning always includes the team and (may/may not) include external stakeholders.
• Does the ScrumMaster (within the ScrumMaster’s limits of authority and influence) work diligently to ensure rules are followed?
• Is the ScrumMaster being undermined from outside the team?
  • When the ScrumMaster makes a recommendation, is that recommendation routinely questioned or is it endorsed by project sponsors?
  • Are there dynamics within the organization beyond the control of the ScrumMaster that the ScrumMaster can work to make visible or get resolved? For example, if the human resources, finance, and marketing departments fight over whose features get done first, can the ScrumMaster use sprint planning as a forum to mediate a solution? Can an executive be invited to sprint planning to resolve the issue?

Alternatives

There are other things that promote rhythm:

• Clarify expectations
• Conduct training
• Be consistent
• Resort to mommy rules

Clarify Expectations

When rhythms emerge, what do you want them to be? The benefits of setting expectations are cooperation, increased likelihood of success, early visible results, and the rhythm you want.

Adjustment will always be required, but having clarity of purpose and shared understanding reduces confusion, argument, and power struggles. Set expectations for backlog management, sprint planning, and daily Scrums.

Pay special attention to clarifying roles.

• What do you want your ScrumMasters to do? Do they manage the backlogs, or do the product owners?
• If team members cannot make a daily Scrum, are they still expected to report, and if so how and to whom?
• Can stakeholders observe daily Scrums?

To discover what you want, do research. Conduct pilot projects. Invite participation of external stakeholders. Talk to grumblers.

Conduct Training

Train ScrumMasters, teams, and external stakeholders. Training does not have to be elaborate: it often doesn’t have to be any more than an explanation to teams or a presentation to stakeholders. However, formal training may be best for ScrumMasters because there is nothing like an overeducated ScrumMaster. They train others.

Be Consistent

Never agree to a deviation that can be avoided. When deviation is observed, take action. For dailies, speak to absentees and find out why they did not attend, then remove the obstacle. Is it a misunderstanding? Then explain and train. Were they given a task they could not refuse? Speak to the source. Is it lack of commitment? Advocate, persuade, and sell. Take similar action for other possible disruptions.

For sprints, use sprint planning to look ahead and anticipate possible deviations (vacations, holidays, absences, etc.), and the sprint retrospective to ask how a deviation arose, and what could have been done to prevent it.

Resort to Mommy Rules

Use this one with discretion because it violates the collaborative spirit of agile programming, but sometimes there is nothing quite like a mommy rule to get compliance:

“I’m clean! Why do I have to take a bath?” “Because I’m the mommy.”

“I’m busy! Why do I have to come to every daily Scrum?” “Because I say so.”

Set rules and stick to them (see Clarify Expectations ). Start each project with a review of the rules. Post the rules in the daily Scrum meeting space. Have a checklist, and occasionally take an inventory of compliance.

Case history

We had one project manager who blew apart three Scrums. This manager had been trained in classic management techniques, and told us CPM scheduling with Microsoft Project(TM) would be used for planning, not the product backlog. He went on to explain that sprint planning meetings and daily Scrums were a waste of time. Individuals on the project would take direction only from the project manager. When the ScrumMaster tried to clarify the ScrumMaster role, the manager's response was that the ScrumMaster role was redundant and therefore unnecessary.

We tried inviting this manager to daily Scrums to observe, but the manager instead would wait until after the daily Scrum and then make assignments that team members could not easily decline. Sprint planning meetings were a clash of wills and dramatic.

The project manager’s supervisor was sympathetic to anything that might improve our abysmal software delivery performance, and agreed to send the project manager to two days of ScrumMaster training. The supervisor attended also.

We still don’t let this particular project manager attend daily Scrums, but the arguments ended immediately, and the project subsequently developed a very clean rhythm and met its first tight deadline. Educating stakeholders clarified expectations, and consistency emerged.

Resources

• Agile Alliance website. www.agilealliance.org.
• Schwaber, Ken. 2004. Agile Project Management with Scrum. Microsoft Press.

Sprint Planning: Better Together

By Mike Cohn

While teaching a recent Certified ScrumMaster class I was asked what a ScrumMaster should do about a team member who doesn’t want to participate in a sprint planning meeting. In this specific case, the question referred to a team member who told the others, “Whatever you come up with is fine with me.” As you’d expect, I answered that the reluctant team member needed to participate in sprint planning. I recommended that the ScrumMaster tell the team member that while he appreciated his conscientiousness in seeking to avoid unnecessarily wasting time, the value of his participation in the meeting would outweigh any perceived waste.

Most of us know what to do in a case such as this, and wouldn’t consider letting a team member skip sprint planning meetings. Yet, many ScrumMasters do allow and even encourage a similar practice: rather than having the whole team work together to plan a sprint, different specialties within the project team plan independently, each focusing solely on “their part” of the sprint plan. Independent plans are then consolidated. The usual sequence of activities goes like this:

1. The whole team selects the product backlog items they will work on during the sprint.
   
2. Team members divide into specialties to discuss what will be needed of their specialty in order to deliver the selected product backlog items. That is, the programmers are in one room discussing what programming tasks will be needed while the testers are in another room discussing what testing tasks will be needed, and so on.
   
3. Everyone reconvenes for a very short meeting in which the plans are combined.

I find this approach to be no better than allowing a team member to skip sprint planning entirely. Three serious things go wrong when teams take this specialization-based approach to sprint planning.

First, the plans that result are not as good as the plans created through a whole-team approach. When specialties plan independently, the team loses the opportunity to identify valuable tradeoff opportunities. For example, I’ve been in countless sprint planning meetings in which a tester comments that testing a particular product backlog item will be much harder than might have appeared at first glance. In many of these cases, the programmers then offered to alter slightly how they would program the feature so that it could be more easily tested. Perhaps they could provide the tester with a programming interface into the feature, perhaps they could expose the feature through a different layer of the architecture, perhaps they could provide an alternative user interface, and so on. When specialties plan independently, these discussions do not happen and the opportunities are lost.

Second, the individuals of one specialty do not develop a shared understanding of the tasks and estimates of another specialty. The level of understanding necessary isn’t such that one group could do the work of another; however, the more the whole team comes to a shared understanding of the work to be performed, the better. Sprint planning meetings are about far more than just identifying tasks and putting an estimate on each. Sprint planning meetings are about discussing the work to be performed, understanding what the product owner wants, how we might collaboratively deliver that, how we’ll collectively address risks, and so on.

Third, when the tasks of the sprint plan are identified independently, the team does not establish a “we’re all in this together” mindset. Instead your specialty’s estimates are yours and my specialty’s are mine. When we start off on this incorrect footing we are very unlikely during the sprint to share the burden of finishing all of each specialty’s work. Each team member will focus on finishing the work that was identified by their specialty. This often results in symptoms such as the programmers continuing to program features that the testers won’t have time to test during a sprint. When a sprint is planned by the whole group, if the programmers find themselves outpacing the testers during a given sprint, some of their time usually shifts to completing testing tasks.

Sprint planning needs to be viewed as a collaborative, whole-team effort. When sprint planning is viewed solely as the sum of individual or specialty-based planning, both the product and the team will suffer. To avoid this, ensure not only that all team members participate but that they all participate together.

Code Reviews & the Developer Handbook

By Martin Jul

We’re six months into a project. The code base is 53,000 statements, 2/3 of which are tests.

We have been working 6 months according to a set of standards: test-driven development with unit and integration tests, model-view-control architecture, NHibernate OR-mapping for the persistence layer, and the Castle container for weaving it all together.

Then an external consultant shows up. He has been hired to check the quality of the work to ensure that a “normal” developer can take the code and work with it inside a “reasonable” amount of time.

I convince him to look at a few architecture diagrams, before he starts looking at the code. I try to show him how to find the implementation code corresponding to the tests but he is not interested in the tests. His goal is to ensure that code is properly documented – and in his world this means the implementation only, not the tests.

Instead he starts at the top with one of the client applications, a web-based intranet for editing data in the system. He starts browsing the code – looking through the container and some of the controller and model classes that it uses.

A few weeks later we get a report.

There should be more comments in the code (our guideline is to write simple, readable code rather than spaghetti with comments).

Oh and member variables should be prefixed with an m, value parameters with a v and reference parameters with an r. And the type of a variable must be derivable from its name.

He also raises a number of concerns about the use of NHibernate and Castle. Basically he wants us to write documentation for these as well (never mind they come with documented source and books and on-line articles).

More or less the audit says to use his idea of what constitutes a good project. So basically he is testing the documentation quality against an arbitrary set of requirements.

We need to devote a lot of effort to convince him.

So, note to self – a pragmatic solution for documentation and auditing:

• Write a simple developers handbook with coding and documentation guidelines etc. and have the customer sign it off. 
• Involve the auditor early to check the guidelines. 
• Use the handbook as the guideline for audits. 
• In any event have the auditor provide a set of “functional requirements” to the documentation, e.g.. “it should be possible to easily find out what a method is doing” rather than saying arcane things like “there should be a two lines of comments for every branch statement”. 
• Create a HOWTO document for each of these requirements and add it to the developer handbook: for example, “The requirements are captured in integration tests using the Selenium tool, they are named so and so.” etc..

Effective Collaboration through Standardization

By Roman Pichler

Let’s face it: for most of us, the term standardization has a negative connotation. We think of rules that are strictly enforced, procedures that must be followed, no matter what. This article tries to put a different perspective on standardizing software development activities. It focuses on a Scrum team making a conscious decision on how its team members create software, thereby fostering effective collaboration.

At Toyota, value creation is optimized by removing waste from the value stream. Defects are a prime example of waste. Defects are created when a task is not properly performed or is accidentally skipped. To prevent defects, minimize variation, and ensure a smooth work flow, Toyota standardizes the work carried out: the same tasks are performed in the same order and same way by every worker. Common work practices serve another purpose: they allow workers to collaborate effectively and cover each other’s work. Following a standard, workers become more effective at doing their work: once we get into a routine, we can do things quicker.

How can we leverage the benefits of standardization and apply them to software development? To start with, we must be clear on two things. First, software development is creative work that generates beneficial variation and involves non-repetitive tasks and experimentation, for instance in form of spikes or prototypes. Second, standardization that is forced on a Scrum team violates the team’s self-organization. At the same time, my experience working with Scrum teams shows that the team members have to adopt a common way of working to collaborate effectively. How can two people pair well if the team members have not agreed on coding standards and other development practices, such as test-first or continuous integration? And are there not some software development activities that are repetitive? Using Test-Driven Development for instance, we carry out a standard task sequence: we first write the unit test; we then implement the class to make the test compile, fail, and succeed. Finally, we may refactor the code to enhance its extensibility.

Often, teams create their own standards over time. Pair programming helps team members to explore different ways of working and to eventually converge on common practices. Sometimes, though, teams can benefit from a facilitated decision-making process that leads to embracing common work practices, for instance, when the team needs to become productive very quickly, the team members have not worked together before, or the team is new to Scrum and is struggling to deliver a potentially shippable increment at the end of each sprint. Note that the team’s ability to agree on standards and norms may be affected by team dynamics. A team caught in the storming phase is likely to struggle to quickly agree on common work practices.

Standards should be developed by the team and not be pushed onto the team. Anyone who feels forced to adopt a new way of working is likely to resist the change. In order to create an awareness within the team of how different ways of working affect the team’s performance, techniques such as pair programming, videotaping team members working together, or simply making a conscious effort to observe each other’s way of working are useful. The team should then analyze the degree of variation, discuss its impact on its ability to transform requirements into working software, and identify and agree on improvement measures. Carefully facilitated, the team will end up standardizing its own work. Retrospectives provide a great opportunity for the team to reflect and monitor how effectively its members collaborate and how common work practices are used.

Depending on the team member’s experience with agile development practices, it may be helpful to involve a mentor to teach the practices, ideally through pairing. Agile development practices such as test-first can be counterintuitive and difficult to understand at first. At Toyota, it is the job of the supervisor or team lead to train employees in standard procedures, by the way. As the ScrumMaster, you need to watch out for any impediments that prevent standardized work and ensure that these are swiftly removed. Otherwise, the team members are likely to disengage from the process and revert back to using their own non-standard work practices.

References

• Ballé, F., and M. Ballé. 2005. The Gold Mine: a Novel of Lean Turnaround. Lean Enterprise Institute.
• Kaner, S., L. Lind, C. Toldi, S. Fisk, and D. Berger. 1996. Facilitator’s Guide to Participatory Decision-Making. New Society Publishers.
• Liker, J. 2003. The Toyota Way: 14 Management Principles From The World’s Greatest Manufacturer. McGraw-Hill.
• Reinertsen, D. 1997. Managing the Design Factory: A Product Developers Tool Kit. Simon & Schuster Ltd.

Poisonous Scrum Anti-Patterns

By Victor Szalvay

My colleagues and I work with a number of organizations implementing agile and Scrum. We are starting to see patterns (and anti-patterns) emerge in the way in which many companies go about transitioning their products to Scrum. Two of these patterns are particularly disturbing: the bored, part-time ScrumMaster and a permanent acceptance of the status quo. In this article I will demonstrate how these two anti-patterns weigh organizations down and ultimately lead to failure during agile transitions.

The Mythical, Part-time ScrumMaster

In nearly every Certified ScrumMaster course I’ve taught, one of the first questions people ask is whether the ScrumMaster role is really a full-time job. Even though my answer is an unequivocal “Yes.” doubts linger about whether a ScrumMaster can really keep themselves busy doing nothing but “ScrumMastering” all day. It seems as though many people have their minds set on how long it should take to fulfill the duties of an average ScrumMaster.

To be clear, if the ScrumMaster is not focusing 100 percent of their work time on team and organizational impediments and improvements, the ScrumMaster is not doing enough to make important organizational change happen. While most new ScrumMasters are comfortable in the role of removing team-facing impediments, they often forget (or conveniently ignore) the organizational work they need to do. Removing organizational impediments, over time, will contribute to changing conditions and culture to maximize the benefits of agile product development.

Some common examples of organizational impediments include:

• Deficient product owners. There are several variations on this theme.
• No one is willing to take on the responsibilities of the product owner role at the organization.
• A product owner is identified that does not have enough time to fulfill the demands of the PO role effectively.
• The product owner providing product direction is not directly responsible for the profit and loss or ROI of the product.
• The product owner passes the buck to the team by forcing improper decisions regarding risk.

While the above represent a few recent experiences, there are many, many more.

The challenge facing an organization full of part-time ScrumMasters is that they have limited capacity for change. Tom DeMarco’s book Slack illustrates that middle management is often an organization’s only hope for changing and improving itself. When that layer of management is cut for efficiency, the organization is so busy that no one has slack time to make meaningful change happen. The same is true for ScrumMasters. While they may not explicitly be middle managers, ScrumMasters are the agents of directed and meaningful change in any organization adopting Scrum. If the ScrumMasters are not working to change those ingrained and complex organizational issues most likely no one is.

That’s Not How We Do Things Around Here

Another dangerous pattern is when the status quo is blindly accepted by the organization at large. This smell surfaces clearly when the group is confounded by a situational constraint or problem but no one suggests that the constraint be questioned or altered. Scrum itself will surface these situations because the process is often impeded by organizational constraints. Rather than resolve or remove the constraint, the first reaction of some groups is to shoe-horn Scrum into the constraint and carry on as best as possible. Perhaps making a change is overwhelming in scale and ignored as a possibility from the outset. But in one particular case I learned that people in an organization were still following rules that no longer existed simply out of habit. Often a little blood, sweat, and tears up front nip organizational issues in the bud that would otherwise blossom into destructive product killers down the line.

A Deadly Cocktail

When an organization suffers from both part-time ScrumMasters and a status quo culture, the negative effects of either alone are amplified. Consider the example organization that simply accepts as unavoidable complex organizational impediments. At the same time, the organization has no agents explicitly advocating change. No one is actively scanning the horizon looking for issues that might interfere with the effectiveness of the organization’s ability to deliver the right products. In fact, over time, as the teams’ velocity starts to dim as a result of the impediments, more pressure is applied to the team and the product quality starts to suffer as a consequence. Perhaps the impediment is finally addressed when the negative consequences are tangible and too great to ignore, but by then it is usually too late. The organizational impediments coupled with no means to change them creates a downward spiral of failed products and ultimately a bankrupt organization.

Both of these issues are related to an organization’s openness and willingness to change or to challenge the status quo in hopes of improving organizations. Without a doubt, ScrumMasters play a key role in making change happen. In fact, I’ve consistently seen a positive correlation between successful agile transitions and organizations that take the ScrumMaster role seriously. However, the organization in general also should foster a culture of openness toward ferreting out root causes rather then searching for compromises that act as temporary band-aids. With both active full-time ScrumMasters and a culture of change, organizations will be primed to tackle the root problems that impede effective product development. Who knows, with a little elbow grease perhaps you, too, can make some meaningful changes at your place of work.

One Word Can Change Your Daily Scrum

By Richard Lawrence

In my experience, the daily Scrum serves two purposes:

1. for team members to make and follow up on commitments to one another, and
   
2. for team members to raise and start resolving impediments.

Both these purposes are directed towards reaching the Sprint goal.

I started coaching a development team in an IT department this week. Most of the team is officially full-time on their project, but unlike the consulting teams I often work with, no one is ever really full-time on a project. There are production apps to support, people management issues, requests for technical help from other projects, non-project meetings, and a variety of other distractions.

Observing this team’s daily Scrums, I noticed that they talked a lot about what they did in the past 24 hours and what they would do in the next 24. Everyone seemed busy and could account for their time. But I had a hard time connecting their busyness to the work they’d committed to do in the Sprint.

So, I suggested a slight change to the three questions that I learned from Mishkin Berteig. Instead of answering the questions, “What did you do in the last 24 hours?” and “What will you do in the next 24?,” I had the team answer the questions, “What did you complete in the last 24 hours?” and “What will you complete in the next 24?” I recommended that they point at tasks and stories on the task board while answering the questions to keep them focused on the work for the Sprint.

There were some objections:

“But I’ll feel uncomfortable saying I’m not going to complete anything today…” To which I say, “Good. You should feel uncomfortable if you’re not helping the team follow through on its commitment for the Sprint.”

“But our tasks are too big to complete in a day…” “Many of them are. This will give you an incentive to make them smaller in the next Sprint, which will increase your visibility into the state of the work.”

Nonetheless, they agreed to try it, and I’m glad they did. The change in the daily Scrum with the new questions was striking. Conversation was more focused on their commitments. Since team members couldn’t use work from outside the project to show how busy they were, they were motivated to fight the distractions and find project tasks they could commit to. The few team members who are spread across multiple projects now can see clearly where the multi-tasking is hurting their commitments to this team.

If your daily Scrums seem unfocused, even though everyone has lots to talk about, consider changing the questions to change the team’s behavior. Just one word can make a big difference. Try asking each other:

1. What did you complete since we last met?
   
2. What will you complete before we meet again?
   
3. What impediments are keeping you from completing something?

Contracts for Implementing Scrum

By Dan Rawsthorne & Douglas E. Shimp

Introduction

Scrum provides the essential framework that an organization needs to create high-performing, rapidly-responding, product-producing software teams. It gives organizations the tools to develop a working product in the face of complex domains and shifting organizational needs. Successfully implementing Scrum, though, requires commitment both on the part of the Scrum team members and on the part of the organization. This has led us to create a list of promises, a “contract” if you will, that gives both teams and organizations a familiar framework for understanding what is necessary for Scrum to succeed and for communicating a sense of ownership by all parties involved.

Intent of the Contracts

These contracts are not meant to be recognized in any legal sense; rather, they are for raising awareness of what is required for a Scrum implementation to work. And remember, even with best intentions, promises are sometimes broken. What is important is that the parties involved commit to a good faith effort to recommit to the promises when this occurs, and to resolve issues whenever they arise.

There are two starting contracts, each containing unique promises. The first contract is between the organization and the Scrum team. The second contract is within the Scrum team and its various parts. Both contracts consist of promises that when kept will maximize the chances of achieving the full benefit of a Scrum implementation.

Scrum provides a working framework, not an “out-of-the-box” solution. Because each organization’s inherent complexities (both product and cultural) are unique, Scrum requires that the Scrum team conduct a periodic “inspect and adapt” analysis. The Scrum team incorporates the results of this analysis into its own processes and the organization incorporates the results into its deployment of Scrum. Therefore, as the organization learns what Scrum means to them, they should periodically reconsider any contracts for implementing Scrum and modify the contracts accordingly.

Parties and Definitions

For the purposes of this contract the following parties and terms are defined. The organization is the business or entity with administrative responsibilities and functional structures, intent on successful delivery of the product. Stakeholders are parties with an interest in the product being developed and/or the Scrum process. They might include suppliers, customers, the business owner, subject matter experts, or product support. The business owner is a key stakeholder who supplies resources for the project. The Scrum team members are also stakeholders, with an interest in the product, process, and project.

Scrum is an empirical development process framework for solving complex problems. Scrum defines three distinct roles that must work together as a Scrum team to produce a successful product. The product owner is responsible for understanding what stakeholders require, interpreting these requirements for the team, and providing clear prioritized direction. The team is composed of those people actively engaged in building the product. The team collectively and members individually are responsible for building the product according to the priorities and requirements provided by the product owner. The team is completely responsible for deciding how to achieve its goals and how to organize its work. Finally, the ScrumMaster is responsible for the health of the process, reporting the progress of the team, and removing impediments to progress.

Period of the Contract

Again relying on Scrum’s framework, we need an “inspect and adapt” analysis of the Scrum implementation. The Scrum team incorporates the results of this analysis into its own processes and the organization incorporates the results into its implementation of Scrum. Additional promises may be required as a result of this analysis.

Decide how often your organization will review and renew the contract:

This contract will be renewed each ____________ (specify period) by retrospection, facilitated by the ScrumMaster and product owner. If at any time the process is found to be inactive, a reimplementation of the contract and the process will be required. Reimplementation is the responsibility of the organization.

Contract between the Organization and the Team

The team promises the stakeholders that there is a product owner on the team driving the team based on stakeholders interests.

The organization promises the team that there are stakeholders (including subject matter experts) who will help when needed.

The team promises to use the stakeholders’ time wisely, by focusing on questions that are relevant to the work being done now.

The organization promises that they will help the ScrumMaster in the removal of impediments to the Scrum team’s progress.

The team promises that they will do quality work the best way they know how within the constraints set forth by the organization.

The organization promises the team that they will not change priorities or constraints in the middle of a sprint without team’s consent.

The team promises to deliver demonstrable product at the end of every sprint for review and validation by the stakeholders.

The organization promises that being on a Scrum team will not hurt the members’ careers.

Signed on this date:______________________

For the organization

Key stakeholders representatives

x___________________________

x___________________________

x___________________________

x___________________________

x___________________________

For the Scrum team

ScrumMaster

x___________________________

Product owner

x___________________________

Download a PDF of this contract.

Contract between Members of the Scrum Team

The product owner promises the team to he/she will supply an initial product backlog.

The product owner promises the team that he/she will prioritize the product backlog when needed.

The ScrumMaster promises to keep the team healthy by focusing on the removal of impediments, both internal and external.

The product owner promises that an empowered “voice of the customer” will be provided to answer business domain questions promptly (minutes or hours, not days).

The team promises that its work will be transparent, that it will make decisions and solve problems as a group, and that no individual team member will be left behind.

Each member of the team promises that they will bring issues, problems, impediments and realities encountered to the team.

Signed on this date:______________________

For the Scrum team

ScrumMaster

x___________________________

Product owner

x___________________________

Team members

x___________________________

x___________________________

x___________________________

Download a PDF of this contract.

7 Ways to Revitalize Your Sprint Retrospectives

By Esther Derby

Retrospectives are an integral part of Scrum. But too often, when I talk to Scrum teams, they tell me that they’ve stopped doing retrospectives. “We’ve run out of things to improve,” one ScrumMaster said. Another complained that after six sprints, they were saying the same things over and over at every retrospective.

If your retrospectives have gone stale, here are seven things you can do to inject new energy.

1. Rotate leadership. Rather than always have the ScrumMaster lead the retrospective, rotate leadership among team members. Ask each team member to try one new adaptation when he or she leads the retrospective. By doing this, you’ll experiment with new activities and build the team’s group process savvy.
2. Change the questions. Rather than asking the two standard questions ("What did we do well?" and "What could be improved in the next sprint?"), start by asking, “What happened during the iteration?” Even when people work in the same team room, they see things from a different perspective. Ask about surprises and challenges. Then ask about insights. When you have a list of insights, ask about possible improvements.
3. Vary the process. If you’ve been leading group discussions, try using structured activities to help the team think together. Reconstruct the timeline of the project to help the team see patterns. Create a histogram that shows how satisfied team members are with the process they used and the product they created during the last sprint. Try using a fishbone diagram to explore root causes. Use dot voting to select improvements for the next sprint.
4. Include different perspectives. For the retrospective after a release, include people from the extended project community—people who aren’t part of the team, but who play a critical part in deploying and supporting the software. Focus on understanding and improving the interface between the Scrum team and other parts of the organization.
5. Change the focus. If you’ve been concentrating on improving how the team works the Scrum process itself, switch the focus to engineering practices or teamwork. If you’ve been focusing on a narrow goal (“How can we improve the build process?”), try a broad goal for the next retrospective.
6. Try appreciative inquiry. Instead of looking at where to improve, look at what’s working well and how you can build on that. Use short, pair interviews to explore questions such as, “When were you at your best on our last sprint?" "Who else was involved?" and "What conditions were present?” After the interviews, put the pairs together in groups of four or six (two pairs or three pairs together) to find common themes.
7. Analyze recurrent themes. If your team is bringing up the same issues at each retrospective, examine the list of issues. If nothing changes as the result of your team’s retrospectives, analyze the factors behind inaction. Are the issues related to organizational policies, systems, and structures? You may not be able to change organizational factors right away, but you can use your influence, and the team can change its response. Are the improvements the team chooses included in the next sprint plan? Change plans that are kept separate from daily work fall by the wayside.

Retrospectives are the key mechanism for examining and improving methods and teamwork. If they aren’t working for you, inspect and adapt!

Scrum Delivers

By Boris Gloger

“In factories around the globe, Toyota consistently raises the bar for manufacturing, product development, and process excellence,” says Jeffrey K. Liker in The Toyota Way. He goes on to define fourteen principles that he claims drive Toyota’s success.

If we accept his premise that Toyota is the world’s best manufacturer and that this success is based on fourteen clearly identified principles, then we should model these principles in our own product development processes to increase our own success. Scrum practices map very well to these principles and provide an effective way of making them part of your day-to-day workflow.

Principle 1: Base your management decisions on a long-term philosophy even at the expense of short-term financial goals.

In a Scrum project, the vision is defined by a key representative of the organization: the product owner. He translates the company’s long-term philosophy (road maps or financial goals) into specific, tactical decisions within the project. These decisions are communicated to the project through the product backlog.

Continue reading this article

Scrum Shouldn't Be a Burden

By Mike Cohn

After some time off in December I've been back on the road and traveling every week since the start of the year. In that time I've noticed something new: people are telling me that Scrum is too much overhead. Too much overhead? I don't think so...

“Too much overhead” isn't a complaint I heard at all last year, but I've heard it a handful of times since the start of 2006. These comments have surprised me—Scrum requires only a single fifteen-minute meeting each day plus a half- to full-day at the start and finish of a sprint. That doesn't seem like much overhead. However, by studying the teams doing the complaining, I have uncovered three reasons why some groups might harbor these misconceptions.

First, the teams may really be complaining about something else entirely. Comments like these could be symptomatic of Scrum adoptions that were started outside the teams. These teams, in effect, have been told that they will do Scrum because doing so has been established as a corporate direction. I believe there's a natural tendency to bristle at any direction given from above. Calling the few generative rules of Scrum “too much overhead” may be a team's way of expressing displeasure at having any decision pushed down onto them from above.

Second, it is possible that Scrum could look like a lot of overhead to a team that was running with almost no process at all. However, I'm skeptical of the ability of a team to consistently deliver valuable products with much less “overhead” than Scrum. There just isn't much that you could cut out of Scrum in order to reduce overhead. In one of the cases I encountered, the perception of Scrum's overhead seemed to stem from the cost of iterating every two to four weeks. Prior to adopting Scrum, this company was not using an iterative process at all. The need to periodically drive the software to a shippable state must have felt like needless overhead to some individuals in that company. On the other hand, their prior process led to late products that missed on fully fulfilling market needs.

Third, the individuals who believe Scrum is a lot of overhead may not fully understand it. They may be looking only at the new things they have to do (daily Scrum meeting, sprint planning, sprint review, and so on). They may not yet see the benefits they will get from Scrum, such as greater visibility into progress, closer contact with customers and users who can validate that the most-desired features are being built, closer coordination and greater communication with coworkers to ensure all team members are heading in the same direction, and so on.

If Scrum feels too heavy or if it has too much overhead, it likely is being done incorrectly. I first ventured into Scrum because I desperately wanted a process that would allow me time to work as a manager of teams but also to program on the systems we were developing. Scrum appealed to me because it was lightweight, the management needs were low, and it wouldn't take much of my time away from programming. Those characteristics just don't mesh with complaints of high overhead. An astute ScrumMaster will hear these comments as a warning signal and investigate to determine the true source of the problem.

Use Your Scrum Senses

By Tobias Fors

Scrum is about learning and taking action. There are many ways to learn, the most elemental of which we use as infants: we explore the world with our senses. While that sounds easy, effectively using your senses takes practice. Gladly, opportunities for practicing your Scrum senses are plentiful. Here are just a few ways to begin.

See

Try looking at people you work with. I know you see them every day, but are you actually looking at them? Looking means more than just resting your eyes on people. Really seeing requires you to actively try to decipher people’s body language. What might their actions be trying to tell you that their words are not? Look closely at the person you are talking to. Is her body resisting your advice while her mouth is busy thanking you for it? Once you notice a disparity between body language and words, act on it. Ask questions aimed at uncovering the emotions hidden behind the mask of politeness that we often wear.

Hear

While our favorite thing to listen to is often the sound of our own voice, you can’t listen while you are talking. If you find yourself discussing a topic of which you are fond, you have found an opportunity to practice shutting up. I myself have to practice break-taking very diligently. If I don’t, I can go on and on until your ears come off. If you wonder if you are monopolizing conversations, try inserting forced breaks into your monologues. Start by putting a thirty-ten limit on yourself. Speak for thirty seconds, shut up for ten. Ten seconds might feel far longer than you thought it would. (If it does, you might have learned something about yourself. Latch on to that something and think about what it’s trying to tell you.) If you’re lucky, someone else will jump in during the ten-second break and fill the silence. Once they do, you can sit back and practice your listening skills. You will probably gather information you wouldn’t have had if you’d spent the same time talking. To keep them talking, ask questions. Learn more.

Feel

You don’t have to focus solely on others. There is a great deal to be learned from honing in on yourself once in a while. Notice your own body. If it’s tense—curled up and ready to snap at a touch—that’s probably not a good sign. Don’t ignore it. Think about why it’s behaving like that. Maybe it’s trying to remind you that it’s okay to get angry at times, or maybe you just need to switch office chairs. In either case, you’ve got something you can learn from and act on.

Confirm

There is one danger to avoid in using your senses: you do not always understand what they are telling you. They can collude with your brain to fool you—to make you think that you actually understand other people. You probably don’t. It’s not a hard problem to solve though. All you have to do is tell people what you think you just sensed; they will sometimes be more than happy to tell you if you sensed correctly.

How will using your senses help you with Scrum? If you use your Scrum senses wisely, you can uncover information where you previously saw none. You might see problems where you once only observed ignorant bliss and conflicts where formerly you saw only slap-on-the-back team spirit. By learning from this information, you will be able to eliminate impediments, improve productivity, and slowly make your world a slightly more pleasant place to be.

New to User Stories?

By William Nazzaro & Dr. Charles Suscheck

Having coached traditional requirements, use cases, user stories, and agile development, I’ve fielded a lot of questions around the differences among the three major ways of specifying requirements, particularly by people migrating to user stories. To set the record straight on requirements, use cases, and user stories, I will describe each methodology and then compare the three against each other.

Traditional requirements

Traditional requirements are criteria to which the system or business must adhere. They are usually created before the coding begins and are nearly always written as text. They often are thought of as constraints, conditions, or capabilities to which the system must conform.
Good requirements have the following characteristics:

• Complete. Requirements should be as complete as possible—no open-ended requirements.
• Testable. Must be able to create a test for all requirements.
• Consistent. Requirements must be consistent with each other—no conflicts.
• Design Free. Software requirements should be specified in the business perspective rather than the software perspective. 
• Unambiguous. Use "shall" and other related words. Don’t be wishy-washy.

Continue reading this article.

Scrum's Complex Simplicity: Nowhere to Hide

By Jim Schiel

“Extremely Simple, But Very Hard”—these five words are the most important in the entire Certified ScrumMaster training course and, indeed, in the entire act of making Scrum part of your organization. Ken Schwaber says that, of all the organizations that take on Scrum, only about 30 percent will succeed. Once most organizations get past the “extremely simple” part and start experiencing the reality of “very hard,” it is challenging to stay the course. Quite simply, the pain caused by transitioning to Scrum can be much worse than the pain caused by the organization’s current software development efforts. The implementation of the cure can be, in effect, worse than the disease.

My organization began its transition to Scrum and agile development in April 2005. At the time, we had ten Scrum teams. As of the beginning of 2006, we have nearly seventy teams simultaneously sprinting on three continents. Over the past year, I have watched our transition to Scrum take on a reality that shook my organization to its roots. Fortunately, we are one of the 30 percent who made it through the hard change to success.

To help you overcome these inevitable growing pains more gracefully, I will be writing four articles, each one focusing on one of the four transitional challenges the CSM training warns you about: the era of opacity, the tyranny of the waterfall, the illusion of command and control, and the belief in magic. This first article will focus on the end of the era of opacity and the transparency in process, status, and team state that Scrum introduces.

End of the Innocence

Opacity appears in many ways in non-Scrum projects, but usually it hides an unreported (or under-reported) lack of progress. Teams and individuals, previously safe from prying eyes, could wait to report issues until the weekly status meeting or the monthly status report. Scrum, with its high degree of daily collaboration and specific reporting in the sprint burndown and the sprint review meeting, removes this opacity and exposes lack of progress in a frequently painful manner.

Sometimes the transparency provided by Scrum requires action to be taken in order to ensure that a small problem doesn’t become worse. For example, when an employee for the third day in a row reports little to no progress on his assigned tasks, it’s up to the team to start asking questions about why. What obstacle is impeding progress that the employee is unwilling to admit to? Is the team member unwilling to get the expertise they need from a particularly difficult expert outside the team? Maybe the team member is getting pulled into too many other things. Maybe the team member doesn’t have the necessary skills to do the job.

In many instances, however, the transparency that Scrum creates is used inappropriately by project management to isolate causes for delays and to level blame. In a Scrum environment, where any given day can illuminate both minor and major issues, management may incorrectly decide to act immediately on each and every negative report. This can cause teams to begin misreporting their progress or even deliberately failing to update or display their burndown chart each day. It will most certainly perpetuate an environment of fear.

While it’s quite simple to put Scrum practices in place, it is very difficult to get Scrum teams and managers to understand that Scrum team progress varies from day to day. You need to carefully consider the state of the sprint each day, and then take appropriate steps. Sometimes that means getting an employee the education they need (remember, not having the appropriate skills is a shared responsibility between management and employees). Sometimes it means removing an employee from a team. And sometimes it means doing nothing at all and re-evaluating the situation at a future time.

Report Health, Not Status

When you are transitioning your organization to Scrum and agile development, you may find it useful to discuss Scrum team condition in terms of “sprint health,” not “sprint status.” Health can be reported in terms that will not necessarily result in action being taken immediately. In addition, “sprint health” removes the accusatory tone that you get when speaking of a “team being behind schedule.” Try these terms, which are all based on the linear projection of the current sprint burndown:

• Excellent—team will complete their sprint goals with at least two days to spare. In this situation, the team might want to consider taking on an additional story from the product backlog.
• Good— team will complete their sprint goals on time; their trend line shows the team completing the sprint on time or as much as one day to spare. The team should not make any changes; they are right on target!
• Poor— team will not complete their sprint goals on time; their trend line shows that between one and two additional days will be necessary to complete the sprint goals. The team should review their obstacles and make sure that they are being addressed. They may also want to review their task assignments. Any changes, however, should be made carefully. Too much change can be more disruptive than none at all.
• Critical— team will not complete their sprint goals on time; their trend line shows that three or more days will be necessary to complete the sprint goals. It’s time to start dropping scope from the sprint goal. The team and the product owner should handle this and should try to return the team to “Good” health.

Offer Support, Not Direction

Educate your managers on the “care and feeding of Scrum teams.” In general, unless a manager is also playing one of the Scrum roles on a team (e.g., ScrumMaster or product owner), they should focus on supporting the team by listening to their issues and offering suggestions for improvement. In this environment, managers should be prepared to offer support, not direction. This is very important because 1) the team already has a product owner to provide prioritization of the backlog; and 2) the team already has themselves to support self-management and self-organization. What they need from experienced managers is support and guidance.

Collaborate & Facilitate

Educate your team members on how to collaborate. Scrum teams do not suffer hermits gladly. Everyone on the team needs to be willing to be held accountable by the rest of the team; they need to be willing to help those on the team that need help; and they need to be willing to be helped when they appear to need it.

Educate at least some of your team members on the finer arts of facilitation. Facilitation, a much overlooked skill, is about making things easier to do. You will give your teams a major advantage by ensuring that there are team members who are practiced at coaxing ideas on the table and then getting the team to elaborate, prioritize, eliminate alternatives, and select the best solutions. Scrum teams engage in group design—by giving the team the skills to do group activities rapidly and effectively, you’ve added an important tool to their toolkit of skills.

Consider all of the time you’ve wasted in the last month in meetings that went nowhere fast. When you left the meeting no better informed than when you walked in. How much time could you save, and how much could the quality of your teams’ decisions be improved, just by learning some very simple facilitation methods? My favorite technique is mind-mapping, where ideas can be generated in any random fashion and can be rapidly linked together on the flip chart or white board as the concepts developed. There are tools on the market today that support mind-mapping, but a fast hand, a marker, and a flip chart are all that’s really needed.

Be Prepared

As Scrum is rolled out in an organization, it naturally removes the opacity usually present in non-Scrum projects. Defects in planning, team make-up, management, and even individual performance can be made painfully obvious in very short order. An organization unprepared for the spotlight that comes with Scrum will be spending a large portion of the first couple months digging deeply and disruptively within every Scrum team to find the rocks under which the obstacles have scurried. On the other hand, an organization prepared for Scrum’s spotlight will be able to immediately use the resulting transparency to identify and remove obstacles while improving productivity and software quality.

Common Product Owner Traps

By Roman Pichler

Product owners play a key part in creating successful products with Scrum: They are in charge of the product and lead the development effort. But this new, multi-faceted role can be challenging to apply. For many organizations, the path to effective product ownership is littered with traps and pitfalls. This article helps you recognize and avoid some of the most common traps.

The Product Owner in Scrum

“The Product Owner is the one and only person responsible for managing the Product Backlog and ensuring the value of the work the team performs. This person maintains the Product Backlog and ensures that it is visible to everyone,” writes Ken Schwaber in the Scrum Guide (Feb 2010 edition, p. 7). This definition sounds rather harmless until we consider its implications. It requires the product owner to lead product discovery, to help identify and describe requirements, and to make sure that the product backlog is ready for the next sprint planning meeting. It also means that the product owner has to engage in product planning, visioning and product road mapping. The individual decides on the content of a release, carries out release planning, reviews work results and provides feedback to the team, and manages customers, users and other stakeholders. So many diverse responsibilities make the product owner a multi-faceted and challenging role. What’s more, the product owner duties often cut across existing roles including the product marketer, product manager and project manager roles. It’s not surprising that organizations can find it challenging to apply this new role encountering traps and pitfalls along the way. Let’s have a look at some of the most common ones.

The Underpowered Product Owner

A project with an underpowered product owner is much like a car with an underpowered engine: The car runs, but it struggles when the going gets tough. An underpowered product owner lacks empowerment. There may be several causes: The product owner does not have enough management attention; the sponsorship comes from the wrong level or the wrong person; management does not fully trust the product owner or finds it difficult to delegate decision-making authority. As a consequence, the product owner struggles to do an effective job, for instance, to align the Scrum team, stakeholders, and customers or to exclude requirements from the release. A product owner of a new-product development project I worked with, for instance, had to consult his boss, the head of the line of business, for every major decision. Not surprisingly, this caused delays and eroded the team’s confidence in the product owner. Ensure that the product owner is fully empowered and receives support and trust from the right person.

The Overworked Product Owner

Being overworked is not just unhealthy and unsustainable on a personal level; overworked product owners quickly become bottlenecks and limit the project’s progress. Symptoms of an overworked product owner include neglecting product backlog grooming, missing sprint planning or review meetings, and not being available for questions or giving answers only after a long delay. Overworked product owners are at odds with the Agile Manifesto’s concept of sustainable pace. “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

There are two main causes of product owner overburden: not enough time to perform the role and not enough support from the team. Availability tends to be an issue when the product owner role is just one of many jobs competing for time and attention or when the product owner looks after too many products or teams. Not enough support from the team is rooted in a wrong understanding of product ownership: Even though there is one product owner, most of the product owner work is carried out collaboratively. The team and ScrumMaster must support the product owner.

To avoid an overworked product owner, try the following: First, free the individual from all other responsibilities. Start with the assumption that being a product owner is a full-time job, and that one product owner can look after only one product and one team. Second, ensure that the team makes time in every sprint to collaborate with the product owner. Scrum allocates up to 10% of the team’s capacity in every sprint for supporting the product owner (Schwaber 2007). Not only does collaboration spread the work across many shoulders; it also leverages the team’s collective knowledge and creativity.

The Partial Product Owner

Some organizations split the product owner role and distribute its duties across several people, for instance, by employing a product manager and a “product owner.” The product manager takes care of the product marketing and product management aspects, owns the vision, is outward-facing, and keeps in touch with the market. The “product owner” is inward-facing, drives the sprints, and works with the team. In these cases, the so-called product owner is little more than a product backlog item writer. This approach reinforces old barriers, blurs responsibility and authority, and causes handoffs, delays, and other waste.

Instead of splitting the product owner role, organizations should face the challenge of applying the role properly. One person should be in charge of the strategic and the tactical product management aspects. This may well require organizational changes, including adapting job roles and career paths and developing individuals to take on a rich set of responsibilities.

The Distant Product Owner

A distant product owner works separately from the team. Distance may evoke images of a globalized world with the product owner on one continent and the team on another. But distance comes in many forms and degrees. It starts with working on the same site in different rooms, and it ends with product owner and team being separated across continents and time zones. I have found recurring issues with distant product owners, including mistrust, miscommunication, misalignment, and slow progress. There is a reason: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Avoid distant product owners by colocating all Scrum team members. As mentioned earlier, mobile.de experienced a significant productivity and morale increase after colocating its product owner, ScrumMaster, and team. If colocation is not an option, the product owner should spend as much time as possible in the same room as the rest of the Scrum team. Remote product owners should be on-site at least for the sprint planning, the review, and the retrospective meetings. Moving from a distant to a colocated product owner often takes time. It may require hiring and training a local product owner. In some cases, it may also require rethinking the company’s product strategy, including where the company develops its products.

The Proxy Product Owner

A proxy product owner is a person acting as a placeholder for the actual product owner . I have found proxy product owners used to compensate for overworked, partial, and distant product owners. At a client of mine, the vice president of product management was asked to take on the product owner role for a business-critical product. Even though he was ideally suited for the job, he struggled to spend enough time with the team. The business analyst on the team consequently stood in as a proxy product owner when the real product owner could not be there. The proxy did most of the product owner work without being empowered. The actual product owner ultimately decided about product backlog prioritization, release planning, and whether to accept or reject work results. What followed was an increase in conflicts and miscommunication, a slowdown in decision making, and a decrease in productivity and morale.

Using a proxy product owner is an attempt to superficially treat a systemic issue. Rather than employing a quick fix, organizations should address the underlying issues. This might require freeing up the product owner from other obligations; colocating the product owner, ScrumMaster, and team; or even finding a new product owner.

The Product Owner Committee

A product owner committee is a group of product owners without anyone in charge of the overall product. There is no one person guiding the group, helping to create a common goal, and facilitating decision making. A product owner committee is in danger of getting caught in endless meetings with conflicting interests and politics—something also referred to as “death by committee.” No real progress is achieved; people stop collaborating and start fighting each other. Always ensure that there is one person in charge of the product, an overall or chief product owner who guides the other product owners and facilitates decision making, including product backlog prioritization and release planning.

Summary

Applying the product owner role effectively is not only key to developing successful products with Scrum. It is also a learning process for the individuals playing the role and for the organization. As making mistakes is part of that process, don’t expect to apply the role perfectly from day one. But watch out for the traps discussed above. Ensure that there is always one product owner responsible for each product in your organization. (If more than one product owner is required, use a product owner hierarchy with a chief product owner in charge of the entire product.) Make sure your product owners are empowered, have a realistic workload, and can work with their teams onsite. This will allow you to apply the role effectively thereby increasing the likelihood of developing successful products.

Scrum in a Fixed-Date Environment

By Paul Given

I recently worked as the project leader (ScrumMaster) on a project trying to transform its ongoing work stream. Historically, our teams were structured very tightly along roles in a typical waterfall fashion. We produced two software releases a year that aligned with major releases of software from partner financial associations. These two releases spanned up to twelve different systems and development teams. The releases had hard dates. Requirements and test data trickled in and changed until thirty days prior to the go live date. These last minute changes and difficulty in managing the test environments were causing tremendous spikes in hours expended at the end of our projects. Something had to change.

Our situation

Our workstream was full of repetitions and disconnects that contributed to our time crunch issues. The project lifecycle usually began when the business systems analyst (BSA) received documents from a partner financial association. The BSA would review these documents with the business customer to create business requirements. The BSA would then review the business requirements with the design leads to create systems requirements.

In turn, the design leads would create both high-level and detailed designs. The developers would subsequently develop and write unit tests according to the detailed design. The design lead would trace the unit tests to the design, and then trace the design to the system requirements. The BSA would trace system requirements to business requirements, and then trace business requirements to the association documents.

Meanwhile, the testing team would write system and end-to-end test cases. The testing team would trace test cases back to system requirements and then to business requirements. Eventually, the developer would turn his code over to testing.

Without fail, two weeks before go live, a tester would find an issue—and no one would know how to follow the tracing to determine the cause of the issue. There would be a mad scramble to fix the problem, hence the spike in hours. Meanwhile, our business customers couldn’t validate results because they had not had any contact with the project since the BSA reviewed requirements with them. All along the way, the project manager hounded everybody for document approvals.

Solution

You can see why we needed to try something different, something leaner. We scrapped our old process and applied Scrum. During the first thirty days of the project we completed the following tasks:

1. Reviewed documents from the financial associations as a team (two BSAs, seven design leads, three test leads, and three customers)
2. Developed the system requirements as a team and integrated these requirements into the association documents.
3. Built a systems testing environment and an end-to-end testing environment.
4. Using the system requirements (and eliminating the high-level and detailed designs), we defined the necessary changes to system interfaces, built the stubbed/shell version of the systems interfaces, and released them to the system test environment.

After the first thirty days, we divided the remaining system requirements into four sets of iterations. An iteration was considered “done” when the code was turned over to the systems and end-to-end test environments.

Outcome

The work was finished and systems testing completed forty-five to sixty days prior to the release, at a sustainable pace and with a high quality.

At that point, the associations announced a significant interface change. Still using Scrum, the teams handled the interface change, the associated business functions, and the testing in thirty days and were ready to go when test data was available from the associations.

Analysis

The Scrum process we instituted worked well. Several factors contributed to our success: team collaboration, multi-level Scrum, and visual tools.

While the teams were not co-located, we were able to accomplish team collaboration through twice-weekly Scrums between the teams. We let teams manage their own work (some offshore, some in-house, some vendor-supplied changes). We set aside time for inter-team issues twice a week. Because they were continually asked to validate functions in the end-to-end test environment, the business customer was engaged throughout the process, which helped eliminate any unnecessary work.

The team collaboration also helped engage technical resources into the requirements gathering process early. This involvement eliminated the need for all of the effort we used to expend on tracing requirements to everything else. The team was engaged in the goals and needs of the business, allowing them to offer solutions to how to get features done easily. Finally, the impacts of any changes were better understood by all.

Another key factor in our success was multi-level Scrum. Specifically, defining the interfaces by which a team could work “behind” allowing teams to work independently. This ability helped eliminate the tension between “decide as late as possible” and “define it and build it as quickly as possible.” Multi-level scrums also allowed the business to be on call for issues providing insight without having to be present 100 percent of the time.

The final key factor in our success was our use of Scrum’s visual tools. We used burndown charts to show the feature milestones being produced (with our common definition of “done”). These charts showed a sustainable but focused effort. The test status dashboards were helpful in giving business a good indicator of quality and progress.

Of course, as in all endeavors, there is still room for improvement. We’d like to move to daily Scrums. We need to find a way to link the offshore and vendor system to the iterative process to generate less confusion on who is doing what in which sprint/iteration. We should create even more transparency by increasing our use of visual tools by individual teams. Finally, we want to find a way to better use automated tests. Doing this would allow testing to be repeated easily and avoid timely regression testing with each sprint/iteration.

Overall, though, we have found that Scrum worked well—even in a fixed-date, fluid requirement environment like ours.

Managing Myopia with Release Burndowns

By Pat Guariglia

The burndown chart is one of the staples of Scrum. Many of us use and love it. Its simplicity and straightforwardness makes it an effective tool for project teams, management, and for the passive observer. A well-displayed burndown chart is one of the greatest information radiators you can use. From time to time, however, project sponsors, functional managers, and others on the periphery misunderstand its purpose. They can sometimes view a project burndown as a short-sighted tool that fails to provide insight into how the project’s end date is affected when features and tasks are re-prioritized and/or moved out of an iteration to meet the sprint’s burndown target. Stakeholder education certainly mitigates the risk of this misconception, but introducing “whole” project burndown charts, or release burndowns, seals the deal for upper management.

The effectiveness of my team’s burndown charts is demonstrated daily. Once I started using burndown charts regularly, I became a better ScrumMaster and communicator, plus my teams became more productive and predictable. I became almost proud of the success of using burndown charts on my projects and felt the need to talk about the charts and use them in presentations to upper management. This served me well and poorly at the same time.

The problem started when someone in my organization’s executive management, “Jeff,” took notice of the burndown charts hanging around our project area. Jeff started to review the charts and drew his own conclusions. As he saw it, the burndown seemed like a good way for the team to drop scope at will, without regard for what it did to project dates and costs.

I was unaware of Jeff’s misinterpretation until I gave a quarterly project briefing to executive management. During the briefing, he asked me to explain the burndown chart. I described how the product owner and team move stories out of the sprint if the chart shows us trending above our planned progress line. Conversely I explained how stories could be moved into the sprint when the chart is trending below the progress line.

Jeff explained that while he understood the need to move stories and tasks in and out of a sprint, he didn’t have a warm and cozy feeling about how those actions affected the cost and time for the project. He asked questions such as, "What happens to the duration of the project if something in the current sprint takes longer than you planned and you need to move something out?" and "What happens to the cost of the project if something gets moved out?” Although I was able to answer these questions during the meeting, I realized that I needed to do a better job of giving upper management a picture of the whole project. I decided to start using release burndown charts, which provide a view of the progress of releases throughout the project.

Scrum teams can often get away with a somewhat myopic, or nearsighted, view of their sprints and releases. After all, teams are rightly focused on delivering the functionality in the current sprint. Their metrics, therefore, are also focused on the current iteration. A sprint burndown focuses solely on the current sprint and illustrates progress along an expected path for that time box (as shown in the figure below). At the start of each sprint, the team plans to tackle a subset of the entire project’s user stories. This subset of user stories has an associated story point value. Teams use sprint burndowns for various reasons. They may want to see how much time and work is left in the sprint. Sprint burndowns also help the team understand whether or not stories are at risk within that sprint. If stories are at risk, the sprint burndown may be an indicator that stories should be removed. If progress is greater than anticipated, the burndown chart can be an indicator that stories may need to be added to the sprint.

On the other hand, sponsors, stakeholders, and other members of management who fund the project need to move beyond that myopic view and look at the big picture. They need to have answers to the following questions: How well is the project funded? How much money is left? When will it be completed? What value is being delivered and when? The release burndown provides a more complete picture of value and time. In the figure below, the entire project consists of 750 story points. The team’s velocity (the amount of product backlog a team can handle in each sprint) is 75 story points. The team estimates it will take 10 sprints to complete the work (750 total story points / 75 points per sprint = 10 sprints). Therefore, the release burndown shows ten release bars extending across the chart from left to right. The vertical axis shows show the number of story points. As value is delivered over the course of the project, the story points (shown in a blue bar in the figure below) burndown; as scope is added or as  estimates increase, the story points increase as well (as shown by the red bars in the figure below). The trendline shows how the project is trending overall. Release burndowns provide the overall project status and the value delivered to date for each release or sprint.

A release burndown shows, at a glance, all of the project’s sprints and their cumulative effect on the project. Release burndowns allow you to visualize the overall project timeline and calculate total project costs, assuming you know approximately how much each sprint costs. A simplistic example would be as follows: Ten sprints, at a cost of $10,000 each, would equal $100,000 for the complete project. If you add an extra sprint, the project cost goes up by approximately $10,000. Management can also see from a release burndown chart when extra sprints were added because remaining work has been re-estimated or work has been added. They can also see the affect of other factors (such as changes in the team’s velocity or membership) on the long-term project outlook.

Product owners can use release burndowns to take corrective scope action when they see the overall progress line trending in the wrong direction. If they see the team is progressing faster than planned, the project may end earlier or they may have the option of pulling in lower priority work from the backlog. If they see the team is not completing as much as planned in each sprint, the product owner may opt to de-scope some of the project, re-prioritize the backlog, or look to project sponsors to increase the length of the project or add project resources.

Release burndowns are an important tool for communicating the condition of the project, the long-term team velocity, and delivered value. In contrast, the sprint burndown is not intended as a long-term project information radiator; a single sprint burndown can't show you what happens to the project when you move work out of a sprint or re-estimate. A tool like the release burndown is much better suited for this level of communication.

Now that I've been using release burndowns for a while, it's hard for me to imagine running a project without one. What about you? Are you using release burndowns?

Rolling Lookahead Planning

By Mike Cohn

Agile processes replace some of the upfront planning of a traditional process with a just-in-time approach in which plans are progressively refined. For the often-used example of a team working in isolation, progressive refinement usually takes the form of creating a high-level release plan and then planning each iteration as it starts. While this is often sufficient for the lone team working on a desert island, it will generally be inadequate on a project being built by multiple teams. When a team needs to integrate its work with the work of other teams, all teams involved will usually benefit from what is known as rolling lookahead planning.

A team doing rolling lookahead planning will begin its iteration planning meetings just like any other team. Usually this is by doing commitment-driven iteration planning, which takes most teams two to five hours to plan a two- to four-week iteration. This is because commitment-driven iteration planning requires the team to determine which product backlog items it will commit to deliver during the iteration by carefully considering each. Product backlog items are discussed and considered in roughly the priority order established by the product owner or customer. The tasks necessary to complete a product backlog item are identified and estimated. When the team finishes discussing the work involved to complete a product backlog item, team members decide whether they can commit to completing it in the coming iteration.

Once the current iteration has been planned, the team remains in the iteration planning meeting and plans two more iterations. Wait, before you panic let me point out that while it often takes two to five hours to plan the first iteration, this is because the second and third iterations are planned at the user story or product backlog item level rather than with tasks as was done with commitment-driven iteration planning for the current iteration. Using data such as its historical average velocity, or a projection of future velocity if there’s a good reason to deviate from history, the product owner and team identify the product backlog items that are likely to be developed in the next two or so iterations.

The team is not committing to deliver these more distant items in the same way it is committing to complete the product backlog items of the current iteration. Specific commitments will be made to those iterations when each rolls forward to become the current iteration. Until then, each is planned only at a high level and only by identifying the work likely to be done in each iteration.

A team does not perform rolling lookahead planning to identify design considerations for the current iteration, although that may occur and be a side-benefit. The chief purpose of rolling lookahead planning is the coordination of work to be done by multiple teams. As new iterations roll into the planning horizon, teams look ahead to the functionality likely to be developed in those iterations. In doing so, teams on a large project are likely to find dependencies upon one another.

For example, suppose both your team and mine are ready to plan the fourth iteration of what will be a seven-month project. We conduct separate meetings, committing to features to be developed in iteration four. We separately identify and estimate the tasks to be performed in that iteration. Before concluding our separate meetings, our teams each use historical velocities to forecast what they will do in iterations five and six.

After both iteration planning meetings are over, you tell me that your team has identified a dependency on my team. You need me to develop something and pass it along to you so that you can complete a particular product backlog item. I tell you that my team cannot do it during iteration four as we just finished planning that iteration. That’s fine with you because you don’t need it until iteration six as it just now rolled into view. We agree that my team will develop the requested functionality in iteration five, delivering it to you at the start of iteration six. By looking ahead two iterations we have successfully avoided the emergency of "my team needs this from you this iteration" that can otherwise be common on large agile projects.

Rolling lookahead planning, and specifically looking ahead two iterations, is a useful technique that belongs in the toolbox of any agile team working on a large project.

From Meager Beginnings to Masterful Ends

By Maria Matarelli

I’ve used Scrum on many software development and IT projects.  In addition to the projects I was working on, I received a request to work on a role-advisory team tasked with analyzing the effectiveness of a specialized project role.  This new team was pulled together with minimal allocations and replaced a full-time team that had just been disassembled due to budget cuts.  Given the constraints and uniqueness of the project, we decided to use Scrum for our approach.  It worked—flawlessly.

Demanding Circumstances

The going was uphill from the start.  We were a team of ten, allocated to contribute only 20 hours per person over the entire calendar year.  The team was just told, “Go.”  Success was undefined and the scope was unclear.  With a meager budget and minimal direction, we had to guide role development, training, knowledge sharing, and create a solution to provide overall direction to support more than 150 people.  The only thing we knew for certain was that the requirements were bound to change as work progressed.

As we discussed our options, it became more and more apparent Scrum was the right approach.  The limited ingredients and project constraints were the perfect recipe for a self-directed team.  Though we could have easily made the business case for additional funding, we were told from the beginning that “additional funding is not possible.”  Any solutions we found would have to be found within the team itself.  Frequent, incremental deliveries would help bring clarity to the project vision.  Though only few of us had used Scrum outside of IT (and most of the team had never used Scrum at all) we felt it was the perfect solution for the constraints facing our team, constraints that probably sound familiar to many teams out there. 

A Creative Solution

I was elected as the ScrumMaster.  My job was to guide the team through the framework, facilitate our meetings, keep the team focused on the goal, and remove any impediments standing in our way.  We selected the functional manager as the product owner, our primary interface with the other stakeholders.  We created a product backlog, using the list of work items as epics and categorizing the stories appropriately.  We ranked the priority and voted on the complexity of the stories.  With the limited availability of our team, we could only work on very small chunks of work within a sprint.

Our success with Scrum was directly tied to the team’s commitment and buy-in to the framework from the beginning.  Those that were new to Scrum listened to the overview of the artifacts, roles, and ceremonies, and eagerly applied the practices to the work to be accomplished.  As a result, project overhead was reduced and the team began producing results immediately.  In the coming sprints, the team was able to collaborate more effectively, giving them the time they needed to maintain their existing workloads.

Something to Prove

Meanwhile, the people who were working in the role that we were redefining had little confidence in the announcement of a new guidance team.  Although they had been promised changes by previous "strategy teams" the end results were not always seen or had little value.  Our team was able to build trust with this community by sharing our backlog and deliverables in a collaborative online environment.  This transparency enabled our team to provide a forum for iterative and incremental feedback.

Our team went further into engaging the input of these and other stakeholders.  It was apparent that we neeeded to gain buy-in in a short amount of time.  I introduced the team to Open Space, a meeting format in which a theme replaces the traditional agenda and the participants identify the topics for discussion.  Using Open Space, we asked the people what they wanted to talk about and enabled them to self-organize and discuss the topics that were important to them.  The greatest benefit from our use of Open Space was the involvement from the people that attended.  Our team was then able to get input on many items in the product backlog from the entire community while also gaining their buy-in and understanding the root of any issues.  While many of the backlog items were completed within the Open Space session, we also added new stories as a result of the discussions, helping us to avoid critical oversights.  By engaging the community in such an open way, we not only were able to greatly increase our velocity in a given sprint, but also were able to uncover additional ways we could enhance the role and truly deliver value as a team.

Space to Work

The product owner asked me to explain our approach and review the backlog with other stakeholders, including high-level managers.  The backlog prioritization received a lot of scrutiny.  The stakeholders had many questions as to why certain items were chosen for the current sprint over others they felt were higher priority.  Their questions gave me an opportunity to explain the Scrum framework.  I discussed planning and complexity size. I talked about how we worked with the product owner to deterimine our priority and took into account work for future sprints through release planning.  I explained the need to bring in only one or two high complexity stories per sprint and how we broke large stories into smaller deliverables.  Given our team's velocity, some lower-complexity stories were often brought in to help round out the sprint with what we could accomplish to achieve some quick wins.

After explaining the rationale behind backlog prioritization and sprint selection, management and the other stakeholders trusted the team’s approach and allowed us to continue working without interruption.  The Scrum framework worked as designed, protecting the team, the work in progress, and ultimately the project’s overall integrity.

A Clear View Changes Perspectives

Another benefit of our approach and backlog overview was that it gave management insight into how much work we could take on during a sprint’s timeframe and still fulfill our other work commitments.  Had the other managers been able to interject new work mid-sprint based on their own prioritization schedules, the team would not have been able to deliver and would have accumulated multiple work in progress activities without completing any of them.  By displaying the work priorities in the backlog and communicating the timing of the sprints, we were able to project which work items could begin in the next sprint without interrupting the current sprint.  The framework provided a means of having a single source for prioritization.  It is not always easy to tell a manager, "no," but when you can explain the framework you are using to complete the work and provide them a controlled mechanism to provide input to the work, they will have a way to navigate work priorities without disrupting the team.

Scrum Just Fit

This was a small team of people in a large corporate arena.  Our ability to adopt the framework and willingness to try something innovative is how this project got “done” in spite of the constraints that come with large enterprise.  The product owner quickly picked up on his role and was very engaged.  The team self-organized, took on the work we could, and consistently completed the work we set out to do.  Our managers understood what we were doing and left us alone to do it, meanwhile still having input into future tasks.  We gave our customers the ability to communicate their concerns and opinions through collaborative tools and open space activities, a key factor in our success. 

We pulled off the near impossible, moving from a challenge with countless limitations to a valuable end result.  We credit Scrum's simple framework for enabling our high productivity.  Through self-organization and collective incremental delivery, we built momentum that translated into real value.  Our experiment, born of necessity, was a true success and is a model that other projects can follow.  While we can’t change the whole business all at once, we can inspect, adapt, and start the transformation one opportunity at a time.

The Art of Compromise: Scrum & Project Governance

By Mike Cohn

The concepts of agility and project governance are not fundamentally opposed. Each is an attempt to improve the finished product. Scrum strives to do this through close collaboration and the short inspect-and-adapt cycles of the timeboxed sprints. Project governance strives to do it by what we might call inspect-and-approve (or reject) checkpoints in which the product or project is compared to a set of desirable attributes.

However, while pursuing similar goals, Scrum and project governance take entirely different routes to achieving those goals. It is in these different routes where problems will arise in mixing the two. Fortunately, a few compromises on each side, combined with the following actions, can lead to a successful combination of agility and oversight.

Negotiate and set expectations up front. Undoubtedly, the first Scrum project to go through the governance process in your company will have challenges. There will almost certainly be some things they cannot do; for example, a Scrum team cannot provide a thorough design before getting permission to start coding, because design and coding will be done concurrently. The only solution to this is for the team to negotiate with the necessary governance groups in advance. The more support a team has for this and the higher up in the organization that this support reaches, the better. The team does not need to solicit a permanent change in governance policies. The change can be pitched as a one-time experiment.

Fit your reporting to current expectations. The project review boards or oversight committees that provide project governance have existing expectations for what information each project is to provide at each checkpoint. Don't fight these expectations. If they expect a Gantt chart, provide a Gantt chart. When you can, however, try to slowly shift expectations by providing additional, more agile-friendly information. If burndown charts are suitable to show, do so. Or perhaps you want to include a report showing the number of times the build server kicked off continuously integrated builds and the thousands (or perhaps tens or hundreds of thousands) of test runs that were executed.

Invite them into your process. Scrum teams can supplement less-detailed formal governance checkpoints by inviting governance committee members to participate in the regular meetings they will hold. I like to extend the well-known technique of management by walking around into management by standing around. Encourage managers and executives involved in the governance of a project to attend the daily scrums, where they can stand and listen to what is occurring on the project. The same shift from documents to discussions that is created by working with user stories needs to occur with project reporting. Encourage people to visit the team or join its meetings to see for themselves what is being built.

Reference a success. Nothing convinces like success. Do whatever you can to get a first project or two through lightened or reduced governance checkpoints. Then point to the success of those projects as evidence that future projects should also be allowed through.

It's one thing to look at agile software development in a test tube; it's another to experience it in the real world. In the test tube, agile methodologies like Scrum are easily adopted by all members, and the nasty realities of corporate politics, economics, and such cannot intrude. In the real world, though, all of these unpleasant issues do exist. It is rarely as simple as deciding to use Scrum and then being able to do so with no other constraints.

Because few organizations will go so far initially as to completely revamp their current approaches to governance, teams need to work with their organization's non-agile governance. Adopting an attitude of compromise and taking the actions outlined above will go a long way towards easing those first Scrum projects through the gates.