Scrum, Virtually: Applying Scrum in a Global Delivery Model

By Jerry Buchana and Srikant Chellappa

Scrum has long been touted as an agile methodology that delivers results in an application development project. The methodology includes short iterative cycles called Sprints, typically 3-4 weeks. During each sprint, the team creates a version of user-ready software. The set of features that go into each sprint comes from the product backlog, which is a prioritized set of work to be done. Which items go into the sprint is determined during the sprint planning meeting held at the beginning of each sprint. During this meeting the Product Owner informs the team of the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint. This cycle can keep repeating itself until a product has met its release requirements or release date. The key factor is that the product is user ready at the end of any sprint (while it may not have all the features) and that the features that have been developed are the most important features. The teams who deliver this work are self-organizing. Scrum is intended to work best for collocated teams working in a team room with no walls and rolling desks so the teams can self arrange their working settings.

Global Delivery Model: Reality for a Flat World

Application development lifecycles have taken a new twist in a flat world. Rapid advances in communication and technology have led to teams collaborating in a global setting to deliver products in shorter timeframes, with better quality, and at a lower cost. This trend started with manufacturing, where companies like GM and Boeing built their products by sourcing parts from several different manufacturers around the globe in an effort to maximize cost, quality, and time, and then assembled them at their locations. This global delivery model found its way to application development in the early 90s, as the cost and quality of communication improved by magnitudes. In a global delivery model, teams are distributed geographically into separate groups within the application development teams. For example, the business analysis team may be placed near the users to have better interactions and fully understand the context of the business process while the core group of developers may be situated in an offshore location such as India or Russia.

Adapting Scrum for a Global Delivery Model

Scrum-based project delivery in a global or a distributed delivery model requires some creative modifications to the Scrum methodology set forth by Ken Schwaber. At eMids, we have adapted Scrum, adding some Rational Unified Process and PMI project management principles, to best support our global delivery team. Despite being distributed we communicate often. We call our daily standup Scrum Calls. Scrum Calls take place early in the morning via phone. Both the onsite teams and offshore teams participate. Our onsite business analysts and the offshore teams collaborate frequently on requirements, progressively elaborating them twice a week via phone. These meetings can be made more frequent as necessary but are not substitutes for the Scrum Calls.

This collaboration doesn’t stop with our delivery teams. We work closely with stakeholders during the entire process. The progress and the features delivered are made highly visible, and are developed collaboratively whenever possible. As a result, there is stakeholder buy in during the whole process. After all, the best way to validate software is to actually put it in the user’s hands!

We have augmented Scrum’s project metrics with metrics from Rational Unified Process (RUP) and Project Management Institute (PMI), including earned value analysis, resource utilization, and estimate-to–complete. We have also incorporated key PMI knowledge area tracking for issues, risks, and statuses. We share our consistent and measureable progress on a daily and weekly basis. This helps alleviate stakeholder concerns and facilitates their buy in.
As we prioritize our product backlog, we keep the RUP principle “do the most architecturally significant features first” in mind. This allows the risks to be taken head on without compromising the features later in the development cycle. We also have a consistent definition of done. When we say we deliver working software, we mean that the software delivered in each sprint must have gone through QA either offshore or onsite before being released to the customer.

We avoid project handoff by running multiple scrum teams in parallel. Each team has a ScrumMaster. The teams’ ScrumMasters report to a project-wide ScrumMaster for a Scrum of Scrums. Having multi-threaded teams avoids the serial delivery of functionality (mini-waterfall) and accelerates delivery timelines.

Above all, we strive for flexibility within the structure of a well-defined process. The key aspect to our blended methodology is that it should never be a stringent process where the users are frustrated with the inflexibility. No onerous change management is involved. There is a fundamental belief that requirements and the feature priorities can change but the onus is on the product manager to ensure that the impact of the change is communicated to the sponsors so that they fully understand the true cost of altering their requirements or priorities.

Scrum, Virtually

At eMids, we believe that Scrum can be adapted to work seamlessly with, and actually improve performance inside, the global delivery model. The best practices we use each day have resulted in a vast improvement in end-user satisfaction and a rapid product development lifecycle that has not only advanced the budgetary benefits of the global delivery model but also has resulted in higher quality and a more usable product.

A Cure for Task Estimation Obsession

By Alan Atlas

I often see teams obsess over sprint planning, especially the task estimates. I mean really obsess. Two days of planning for a two-week sprint? Believe it or not, it happens. Even as they complain about spending too much time in scrum meetings, they will insist on arm-wrestling over each and every task estimate. For teams that want to take advantage of their scrum experience and streamline their planning, eliminating task estimates can be an option.

Don’t look so shocked. It is possible. One big caveat, though. For those teams that are new to Scrum, I do not recommend eliminating task estimates until you have established a stable velocity.

Once you have a stable velocity, however, you can use the concepts of story points and velocity to eliminate the need for task estimates in sprint planning. The time you used to spend estimating tasks can then be used more wisely to create working software. I will present a series of steps you can take to gradually eliminate task estimation from your sprint planning process.

Background

Before we get started, let’s quickly recall the reasons why we do the sprint planning things that we do. (We’ll want to make sure we can still meet those needs when we’re done streamlining the process.) We plan the sprint in order to create the following:

1. A shared understanding across the team of the goals of the sprint;
2. A shared understanding of the work that needs to be done during the sprint;
3. An environment in which team members know what to do next (or can find out in seconds);
4. An achievable team commitment to deliver a certain amount of value, expressed as product backlog items; and,
5. A burndown chart that we can use to track our progress through the sprint.

Task estimates most often contribute to goal five above, and for some teams, to goal four. If we can achieve those two items without creating task estimates, then we are free to choose not to use task estimates at all, aren’t we? If you agree, here’s a way to transition away from doing task estimates as part of your sprint planning.

Step 1. Establish Stable Velocity

Use your normal sprint planning process, whether it takes two days or two hours, for each sprint until you can demonstrate stable velocity. (There are many discussions of how to achieve stable velocity out there; it is too large a subject to treat here. For more on agile estimation, I recommend Mike Cohn’s Agile Estimating and Planning.) Make sure your team passes the Nokia test by producing potentially shippable software each sprint (in other words, you’ve proven that you can calculate your velocity correctly). When you have achieved stable velocity, your team will be able to make, and meet, sprint commitments based solely on demonstrated velocity and story point estimates of Product Backlog items. You want to do this anyway as part of having a good scrum implementation, right?

Step 2: Experiment with a Task-Based Burndown

When you think you’re ready to stop estimating tasks, start to use two burndown charts instead of one. Continue to use your normal work-based burndown, which is based on the task estimates from the sprint backlog. Add to it a new burndown chart, which will be based only on the number of tasks in the sprint backlog, regardless of their estimates. The new burndown chart can be called a task-based burndown chart.

Your familiar work-based burndown chart starts with the total of all task estimates for the sprint and, as estimates are updated daily, the burndown continues to reflect the estimated amount of work left in the sprint.  Hopefully it will usually trend down toward zero. Your new, task-based, burndown chart starts instead with the total number of tasks listed for the sprint. Estimates aren’t updated for this chart, and work is burned down when a task is completed (its value on the burndown goes from 1 to 0).  For best results, make sure your task breakdown results in the smallest tasks possible. The task-based burndown chart reflects the estimated total number of tasks left to do in the sprint and not the estimated work effort left. This works best if you have lots of small tasks, typically ones that can be done in a day or less.

Make sure that both burndowns agree and that both give you the same visibility into your progress during the sprint. If you find that the task-based burndown isn’t useful, take a look at Step 3.

Step 3: Shrink Tasks to Improve the Task-Based Burndown

A good, informative task-based burndown chart depends on there being many small tasks to burn down. Conceptually, if you only had one task per PBI on a sprint backlog, you could have a perfectly good work-based burndown chart because the daily updates of the task estimates are given with arbitrary granularity (Now, if your PBIs really have only one task each, it’s indicative that there is a problem with either your stories or your task decomposition). In contrast, the task-based burndown chart for this sprint would be very insensitive on a daily basis, because the tasks would tend to span many days, and progress would not show until a task was completed. The remedy is to make tasks small. A good rule of thumb is that a task should be something that can be completed in a day or less.

Step 4: Stop Doing Task Estimates

When your two burndown charts convey similar information and when you can deliver on velocity-based sprint commitments, you can stop doing task estimates and do away with the work-based burndown. For some teams this will be easy to achieve and for others it could take many sprints. The key to this is to use the idea of velocity correctly. Note that you will still want to be doing the task breakdowns for now. Eliminating them is a different step altogether.

What did we lose when we did away with the task estimates? Task estimates support planning needs four and five from the list above. We still have a burndown chart that we can use to track progress, so we still support goal five.  We have removed the need to support goal four because our team has demonstrated the ability to make commitments based on story point estimates of PBIs and does not need task estimates for validation.

The only thing we might have lost is tangential support for planning need number two. That is, by not asking for estimates, we may have removed some of the mental pressure and motivation to think deeply, look for issues, recall similar efforts, and in general actively bring knowledge and experience to bear on the problem of correctly planning out the tasks. How big a deal is that? The answer to that question is unique to you and your team.

The Product Vision

By Roman Pichler

True North

Have you ever worked on a Scrum project where the overall goal was not clear? Where you had a product backlog but the people involved in the development effort only vaguely understood the purpose of the release? It happens more frequently than any of us would like, even on projects with multi-million dollar budgets! Often Scrum’s emphasis on “getting work done” is misunderstood as a rush to develop with not enough thought to where the project should be going. Don’t make that mistake. Every Scrum project needs a product vision that acts as the project’s true north, sets the direction and guides the Scrum team. It is the overarching goal everyone must share – Product Owner, ScrumMaster, team, management, customers and other stakeholders. As Ken Schwaber puts it: “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.” (Schwaber 2004, p. 68)

Five Questions

“Vision is the art of seeing things invisible,” observed the English writer Jonathan Swift. The product vision paints a picture of the future that draws people in. It describes who the customers are, what customers need, and how these needs will be met. It captures the essence of the product – the critical information we must know to develop and launch a winning product. Developing an effective product vision entails carefully answering the following questions:

1. Who is going to buy the product? Who is the target customer? 
2. Which customer needs will the product address? 
3. Which product attributes are critical to satisfy the needs selected, and therefore for the success of the product? 
4. How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points? 
5. What is the target timeframe and budget to develop and launch the product?

Answering these five questions also gives us the information to create a business case. It allows us to decide if and how the project should proceed.

Creating the Product Vision

Since the Product Owner is responsible for the success of the product and its return on investment (ROI), he or she should lead the vision-creation activities through close collaboration with the team (Pichler 2008). For innovative projects, this team may include business and technical people; for instance, marketers, product and user interface designers, and developers. The more innovative and complex the product is, the more important the vision is and the more effort is required to create it. For new-product development projects and major product updates, market research and prototyping activities are usually carried out. Since it may take several weeks or even months to compile the relevant information in this case, running one or more sprints is the best way to carry out the necessary work. Contrast this with a small product update or a maintenance release where creating the vision may only take a few hours or days.

The Heart of the Product Vision

At the heart of the product vision is the description of the selected customer needs and the necessary product attributes meeting those needs. To arrive at this vision, we first select our target customers and then the relevant customer needs, thereby deciding which market or market segment we are going to address. Then we identify the product attributes, those critical high-level requirements the product must fulfill to satisfy the needs.

Product attributes typically comprise both nonfunctional and functional requirements. Nonfunctional requirements include performance, robustness, and usability requirements. Functional requirements describe specific product functions or features, for instance making a call or sending an email. The product attributes serve as a guide for the team; they constrain the solution space – the set of all possible solutions.

Describing product attributes at the right level of detail is a balancing act that requires close collaboration between the Product Owner and the team. Under-specifying attributes causes a lack of guidance and direction. Over-specifying product attributes results in making decisions earlier than necessary and negatively impacts the team’s creativity. The techniques useful to describe attributes include personas and scenarios, use cases, and user stories.

Desirable Qualities

Like any important goal, a good vision equally appeals to our intellect and to our emotions. It should motivate and inspire people. The product vision should be clear and stable; broad and engaging; and short and sweet.

Clear and Stable

The product vision must be clear and easy to understand to create alignment and a common purpose, and to avoid misinterpretation and confusion (Lynn&Reilly 2002, Pichler 2008). The English term vision is derived from Latin visio, which translates to “seeing, view, notion, idea.” The product vision should hence allow us to see the future product. The vision should not be fuzzy or hazy.

Vision changes, particularly with regards to customer needs and critical attributes, can cause confusion, de-motivation, and project failure. Small adjustments are usually fine, as long as the product’s value proposition stays the same.

Broad and Engaging

The product vision should describe a broad and engaging goal: a goal that guides the development effort but leaves enough room for creativity; a goal that engages and inspires people, fosters creativity, and generates buy-in.

Short and Sweet

The product vision should be brief and concise (Pichler 2008). It should contain only information critical to the success of the product. The blockbuster products researched by Lynn&Reilly (2002), for instance, had visions with no more than six product attributes. The product vision is, therefore, not a feature list and should not provide unnecessary detail.

The Elevator Test

The classic way to validate the product vision is to answer the elevator test: “Can you explain your product in the time it takes to ride up in an elevator?” Moore (2006, p. 152). Passing this test ensures that your product vision is clear, engaging, and brief (assuming we ride up a building with the right height and don’t get stuck). Notice that the elevator test does not tell us if we have selected the right customer needs and the right product attributes; only early customer feedback can do that.

Business-as-Usual Projects

Even our business-as-usual projects should be guided by a product vision. For example, I manage my own marketing activities using Scrum. I fill my marketing backlog with new items on a regular basis, sometimes as frequently as every other day. It would be an overkill to carry out market research and prototyping activities before I decide what to work on. Instead, I set myself a marketing vision that guides my work and provides focus. My vision is, by design, less substantial than the vision for a new-product development project but it’s still important that I have one.

Summary

An effective product vision guides the Scrum team and aligns stakeholders and customers. Spending time and money on vision creation is a worthwhile investment. As Robert G. Cooper notes: “Too many new-product projects move from idea stage right into development with little or no up-front homework. The results of this ‘ready, fire, aim’ approach are usually disastrous. Solid pre-development homework drives up new-product success rates significantly and is strongly related to financial performance.” (Cooper 2000, p. 3) This does not mean procrastinating the start of development, using an upstream waterfall process that creates a mighty product concept or employing a separate project. The trick is to spend as little time as possible but as much as required; to use Scrum to create the vision; and to ensure that as many of the team members involved in the vision creation as possible also transform it into the actual product.

References

Cooper, Robert G. Doing it Right. Winning with New Products. Ivey Business Journal. July/August 2000.
Lynn, Gary S. and Richard R. Reilly. Blockbusters. The Five Keys to Developing Great New Products. HarperCollins. 2002.
Moore, Geoffrey A. Crossing the Chasm. Marketing and Selling Disruptive Products to Mainstream Customers. Revised edition. Collins Business Essentials. 2006.
Pichler, Roman. Scrum – Agile Projektmanagement richtig einsetzen. dpunkt.verlag. 2008.
Schwaber, Ken. Agile Project Management with Scrum. Microsoft Press. 2004.

Yin Yang & Project Management

By Jann P. Thomas

The Chinese philosophy of yin yang is based on four laws.

1. Yin and Yang are opposing. Yin and yang describe the polar effects of phenomena.  For instance, winter and summer would be the yin and yang for the year.  
2. Yin and Yang are mutually rooted. They are complementary qualities that make up the whole phenomena, just as daylight and night together make up a single day.
3. Yin and Yang mutually transform. That is, a change in one quality causes change in the other.  For example, snow melting in the spring cause a rise in the river.
4. Yin and Yang mutually wax and wane. There is a dynamic equilibrium between Yin and Yang; even as winter days grow shorter, the night grows longer.

Agile and traditional management methodologies have a yin yang relationship that is felt quite keenly by many project managers charged with moving a software team toward agile practices. Handed an edict from on high or a mandate from the software team’s own grassroots effort, the manager must figure out how to function in his new reality. Will the developers now have free reign to do whatever they want to do?  Who will be in control?  What is the job of the manager on an agile development team?  How can I move from command and control to cooperation?  Learning agile’s guiding principles and how their inherent balance translates to concrete actions is the first step to a truly productive conversion to Agile.

Balanced Principles

Like the yin yang philosophy, agile also has four guiding principles—principles that are also opposing, mutually rooted, mutually transforming, and mutually wax and wane. These principles are captured in the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Let’s examine the yin and yang of these guiding principles and see how it can help guide a project manager in converting to agile.

Individuals and Interactions & Process and Tools

This principle lends itself to several concrete actions. If possible, remove cubicles and have the team together in one shared workspace. Schedule daily stand-up meetings for each team member to discuss what they did yesterday, what they are doing today and what blockers stand in the way of completing work. Remove any blockers or impediments to delivery, whether that means buying tools or putting a process in place to encourage productivity.  

A process? Yes. Agile is not anti-process. For example, take the familiar case of bringing in an enhancement to a product in mid-iteration rather than completing the work originally scheduled for that iteration. To do this effectively and transparently, the agile project manager must create a process for bringing in new, unplanned work. This process must also include recording what tasks were moved out of the iteration to make room for the new work so that the whole team, including the customer, can see and understand not only what changes occurred, but what the costs of those changes were.

To be an agile project manager is to be introspective. A good agile project manager should review and question all of the organization’s existing and developing processes. Is the process appropriate in an agile environment? Does this process help or hinder the team’s efforts to deliver working software? In addition, iteration reviews (retrospectives) give the entire team the opportunity to evaluate any changes they have made to their processes; the team keeps the ones that work and drops the ones that don’t.

Working Software & Documentation

Working software is the goal of every software project. Traditional approaches, such as waterfall and spiral methodologies, rely on the concept that the requirements of the product can be precisely defined before implementation begins. Agile development practices differ in that all software project activities, from requirements to installing production-ready code, are delivered in small time chunks called iterations. An iteration can range from one week to four weeks. The only fully defined requirements are the ones that the development team is working on in a particular iteration.

Agile teams and agile project managers are not opposed to documentation; rather, agile is focused on just enough documentation, just in time to create working software. On agile teams, requirements are developed only when they are ready to be used (just in time), which often results in a smaller set of architectural diagrams, use cases, and functional specifications. The documents that are created and maintained are only those that are necessary for development (just enough). If a document has outlived its usefulness, it is jettisoned by the team. Producing documentation is appropriate as long as it supports the working software.

Collaboration & Contract Negotiation

All software projects have some type of contract, whether implied or explicit.  Implied contracts are used most often for internal software teams; explicit contracts are used for things like hiring an outside software team for a temporary project. The one thing that both of these contract types have in common is a date.  Most project managers are familiar with the three sides of the constraint triangle: scope, time, and quality. If time (completion date) is fixed and high quality a priority, the only area for compromise is scope. Negotiating with the customer or product owner on scope is a key component of agile project management. Only the product owner knows the importance of a feature. Only the product owner can make decisions on the relative position of features and which features must be delivered first. Only the product owner can decide that rework of an existing feature is more important than new feature development. The fact that the product owner is part of the team and can see the work as it is completed allows agile teams deliver value earlier than they could using traditional software methodologies.

Responding to Change & Following a Plan

As anyone who has built a house can attest, having a detailed set of blueprints is only the beginning. Compromises and changes are expected and inevitable prior to final delivery. The same holds true in software. Just as a homeowner would not give the blueprints to a builder and never visit the construction site, product owners for software projects shouldn’t just hand the development team a list of requirements and then never see the interim product.

Agile projects allow the product owner to visualize the progress on his project as code begins to work. The product owner is empowered in agile projects to finalize details as work progresses. Returning to our building analogy, during construction, the homeowners pick out fixtures, choose cabinet colors, and sometimes move walls as they begin to see their home emerge. Similarly, the agile product owner fills in the details of his own requirements (or changes his mind about his requirements) as he begins to glimpse the working software. If the product owner decides there needs to be a change in something already developed and that change is more important than new undeveloped features, the project team makes that change. Agile teams, like home builders, respond to change.

An Agile Coexistence

Just as yin cannot exist without yang, the elements that agile practitioners value (working software, collaboration, change, and interactions) do not exist without their corresponding yang (documentation, contracts, plans, and process). These mutually inclusive agile principles also follow the laws of yin and yang. Agile principles are opposing: there must be a plan but the plan will change. Agile principles are mutually rooted: the contract, whether implied or explicit, will require negotiation, so invite the customer to collaborate with the team. Agile principles mutually transform: the team needs some sort of blueprint of what to build but only as much as makes sense and is reasonable to maintain. Finally, Agile principles wax and wane: all software teams need processes and tools to know their boundaries but individuals interacting daily build the best software.

Ready, Fire, Aim: A Rebuttal

By Tom Steele

One popular criticism of the early agile software development movement is often summed up by the phrase Ready, Fire, Aim. The phrase’s intent is to depict agile approaches like Scrum and XP as foolish—something so obviously inconsistent with conventional wisdom that it could not possibly work. At its core, it suggests that lengthy planning (aiming) must come before getting started (firing). Anything else could never work and should be avoided.

Those of us who have successfully adopted Scrum know that rapid and continuous planning throughout the life of a project is much better than any lengthy upfront planning effort. Scrum, through its release and iteration burndown charts, provides the necessary information to properly steer projects toward successful outcomes.

Nonetheless, you may still encounter this anti-agile sentiment from people or organizations reluctant to try Scrum. I would like to share two illustrations that show why Ready, Fire, Aim can sometimes be a good thing.

Ready, Fire, Aim Really Works

Ready, Fire, Aim is a play on Ready, Aim, Fire, a phrase commonly used in conjunction with firearms. Since firearms are used extensively by the military, the first counter story I want to share comes from the US military.

General Norman Schwarzkopf commanded US forces in the Persian Gulf during Operation Desert Shield and Operation Desert Storm. He is credited with taking advantage of technology advancements in weaponry to aide his success during the Gulf War. One such advancement involved putting soldiers on top of buildings in Iraq. These soldiers would remain hidden during daylight hours. At night missiles would be fired from several miles away. After the missiles had been fired, the soldiers on the rooftops would use lasers to guide (aim) them to their targets—truly a Ready, Fire, Aim operation.

A Scrum team is similar to the soldiers on the buildings, constantly guiding their projects to the desired targets.

Confucius Says

My second story illustration is a simple passage from a fortune cookie: You can’t aim a duck to death.

The Scrum/agile interpretation of this phrase is that you will never complete any project (kill the duck) if you never actually get started (aim endlessly). Numerous projects fail before getting started; too much time and money is expended at the onset. This can be especially true in large enterprises where there is a tendency to spend far too long defining and planning projects and never getting them started. The passage also nicely complements the Scrum mantra The art of the possible.

That doesn’t mean that we shouldn’t aim at all. After all, it is also said that a well-aimed spear is worth three. Even (and especially) in an agile setting, everything must be kept in balance. It’s entirely possible for a project to start prematurely and fail as a result. Discussing this possibility with those who are predisposed to mistrust agile demonstrates an appreciation for the motivations of plan-driven project managers. Maintaining the crucial balance between aiming and firing is why we ultimately tailor agile approaches to individual circumstances—why we strive to be as agile as possible.

Conclusion

The next time you are in a situation where you sense uneasiness towards agile or Scrum, consider using these stories as arguments for an agile approach. Introduce Ready, Fire, Aim as a common argument against agile, then share these stories to help illustrate your understanding of their concerns. Though simple and anecdotal, they may cause a skeptic to reconsider any bias against agile software development approaches like Scrum.

Scrum Games: Participatory Activities that Illustrate Scrum Principles and Practices

By Michael de la Maza

Three years ago I learned how to fly a plane. Before I got into the cockpit, I read books and magazines and watched videos on flying. I spoke to pilots about their experiences. I attended aero club meetings. But nothing prepared me for the vertigo and nausea I felt on my first flight or the terror I experienced when night flying.

Like flying, Scrum cannot be learned solely from a book or from a presentation. It must be experienced. Great Scrum trainers and coaches lead their teams through a wide mix of activities that illustrate Scrum practices and principles to give their teams the opportunity to learn by doing.

One of the key Scrum principles is teamwork: the team cannot be a collection of individuals each pursuing their own interests. This concept is, unfortunately, foreign to many work environments. In contrast, a Scrum team coordinates its activities during various meetings, including the daily scrum and the planning meeting, and through the use of many artifacts, such as the burndown chart.

The ESP (extrasensory perception) game is a very simple game that I have found to be very effective in highlighting the importance of teamwork and in sparking discussions about its value.

ESP Game

The ESP game should be played after the team has gone through a Scrum planning exercise and is familiar with sprints. I have found that at this stage there are many doubts about the necessity and benefits of the various Scrum meetings.  I often find that the team wants to skip or modify a meeting.  The ESP game illustrates the key point that if the team does not explicitly invest in teamwork and communication, it will suffer. The game can also be played during the retrospective meeting by teams that have already implemented Scrum to spur discussion about teamwork and communication.

The ESP game is played as follows:

1. The participants are divided into pairs. If the group has an odd number of people then the trainer or coach should play.
2. Each person is given a set of five to fifteen cards. All sets of cards should be the same. These cards can be standard playing cards, planning poker cards, or index cards created for this game.
3. Each person in each pair selects one card and slides it into the middle. Once both cards are in the middle they are turned over. The players can only show one card at a time.
4. If the two cards match then each player gets a point.
5. The game continues until all cards are exhausted.
6. When all cards match, the game is over. If any cards did not match, then the game is repeated.

During the game, the players are not allowed to communicate verbally or non-verbally. They can only communicate through the cards. The players are not allowed to write on the cards or mark them.

Once all pairs of players have finished (i.e. their cards match for the entire deck), then the pairs can be grouped together to form sets of four people and the ESP game can be repeated. The players receive a point only if all four cards match. Smaller groups can continue to be grouped until all of the players are in one large group.

Note that while there may be many logical ways to sort the cards (in numerical order, in alphabetical order, etc.), the greatest challenge is in agreeing on the order without any sort of meta discussion. If, in the first round, one player sorts the cards in high to low order and the other player sorts them in low to high order, neither player will know whether to repeat the original order or to switch orders in the second round. Typically, one player will eventually follow the order selected by the other player. When the pairs are then grouped together the leader/follower behavior must change because each pair has a leader and, unless the order happens to match, one of them must follow.

Discussion

When the activity is completed, invite the participants to engage in a discussion. Here are some questions that often spark conversation:

1. What did you learn?
2. How much simpler would the ESP game be if you could speak with the other player?
3. In your current work environment do you ever feel that you are playing the ESP game? If so, why?
   - What Scrum meetings and artifacts ensure that you will not fall into the trap of coordinating your work effort by playing the ESP game?
   - What might happen if you eliminate these Scrum meetings and artifacts?
4. In your current environment...
   - How do people coordinate their work?
   - Is coordination a first-class object?
   - How often do coordination problems occur?
   - Is teamwork highly valued?
   - Is the team in sync?
   - How are promises and expectations managed?
   - How does the team respond to coordination failures?
5. How can your team improve its teamwork?

Scrum games such as the ESP game serve to illustrate the value of Scrum principles and practices. I encourage you to use them when introducing a traditional team to Scrum. Even high performance Scrum teams enjoy playing these games during the sprint retrospective!

Team Dysfunctions and Scrum

By Plamen R. Balkanski

Scrum implementations, especially in their early days, are expected to, and almost always do, reveal hidden problems and issues within the Scrum team. This article explores ways to overcome some of these all-too-common team dysfunctions.

A Beautiful Beginning

Pat is the ScrumMaster on her organization’s first-ever Scrum team. So far, all team members seem to be interested and are attending all the meetings. Pat has managed to secure a regular meeting room with whiteboards for the daily standups and has also been able to book an appropriately equipped room for reviews and planning meetings. Everyone seems to have caught the spirit of index cards and blu-tac. Overall, Pat feels very encouraged by the energetic culture emerging around her.

The only part that seems a bit off is the team retrospective. She can’t put her finger on the problem; things just seem a little weird. No big issues are being raised during retrospectives, but Pat dismisses it as normal.

Another iteration goes by. This iteration was a disappointment. Only 5 of the team’s 12 planned points were achieved. As a result, the review didn’t go too well . It’s now time for another retrospective. Pat is curious as to whether the iteration’s poor outcome will spark some discussion about the sudden slowdown in velocity.

The retrospective seems to be running smoothly when suddenly Tom, a senior developer, speaks up: “Here’s what really happened. Chris [a test engineer] wouldn’t let the rest of the team do any testing. As a result the team ended up with half of the stories in the final stages of testing just because test engineers would not trust the rest of the team members to provide adequate testing.”

Surprised by the fact that he is being blamed, Chris replies, “No one else is qualified to do ‘proper testing.’ Besides that, this whole Scrum process practically ignores testing. It’s no surprise that quality is going down.”

At this point, Pat interjects. She explains that blaming is not allowed. She accentuates the positives of identifying a problem that the team now needs to focus on resolving. She agrees to research solutions to these impediments. The rest of the retrospective is uneventful.

Back at her desk, Pat begins to work on solving this problem. She sees this as a technical issue: testing needs to be automated to reduce the workload of testers. She starts reading about test automation and distributes various useful webcasts and studies about it. She even changes the Scrum training to frame it specifically for test engineers. They seem to understand more and more about cross-functional teams and the need of automation. The problem must be solved, right?

Beneath the Surface

Wrong. Let’s step outside of our scenario and analyze what’s happened so far. Though Pat may have solved some of the surface problems, the real issue probably runs much deeper. She has two likely problems: lack of trust and fear of conflict. The test engineers do not trust the rest of the team; perhaps the developers don’t trust the testers, either. Generally speaking, lack of trust is usually caused by an unwillingness to be vulnerable. In these cases, team members are not open with one another and are afraid to talk about their mistakes and weaknesses. At the same time, the fact that the team’s previous retrospectives seemed to be running a little too well suggests that the team might be afraid of conflict. As a result of these two problems, the team is not engaging in open debates and is instead resorting to indirect discussions and shielded comments. Eventually, though, the issues will reach a point where they bubble out of control, causing far bigger problems than if the conflict had arisen earlier, or even better had been resolved in a team debate.

The Calm Before The Storm

During the next few iterations, things seem to be running more smoothly. The testers are no longer questioning automated testing and seem to be spending time finding an appropriate tool to use. Pat still has slight concerns about the way the team reaches quick agreement during planning, although she can easily justify this with the fact that the team is just getting more and more used to Scrum. The team is edging close to completing the list of stories in the backlog, and Pat is ready to focus on the release.

On what seems certain to be the last planning meeting before the release, Pat asks the team to start discussing final steps to produce a deliverable product. Suddenly, people seem a bit uncomfortable. Most unexpectedly Jane, another test engineer, states out of the blue, “The team may think that this product is ready for release, but I’m not convinced that enough testing has been done.”

Chris quickly concurs, “I agree. I will not accept responsibility for this product. I’ve never done less testing in my career nor have I ever seen such a weird way to develop something.”

Peter, a web developer responds, “Obviously, the test engineers still do not trust the rest of the team. How can more testing be done when only two team members are testing?”

Pat leaves the meeting disappointed and very concerned because what seemed to be a maturing Scrum team suddenly doesn’t act like a team at all. She spends the rest of the day reading about teamwork and various ways to improve it. She is beginning to realize that without sorting out underlying problems it will be difficult to improve practices and productivity.

Let’s step back and look at what’s happening. The Scrum team in our story appears to be functioning smoothly but are really hiding their true concerns from each other. A team that does not engage in debate, or in other words, a team that lacks healthy conflict, often also lacks commitment.  Because team members are not airing their opinions in an open discussion, they rarely, if ever, commit to a decision, even though they may demonstrate agreement in meetings. Unfortunately when this is the case, it triggers an even bigger problem: avoidance of accountability. When team members are not committed to a well understood plan of action, they often fail to call their peers on actions and behaviors that seem counterproductive to the good of the team.

Did You See It Coming?

The next morning things seem to become even worse. During the daily standup, Pete, a senior developer, shows obvious impatience while Chris is talking. He even interrupts him to make a point about team members not following practices that he believes are a must. Tom also joins in by ignoring the usual order and stating that he feels it has become more difficult for him to do “proper” development. Being a “jack of all trades” makes it impossible for him to develop expertise. Jane follows to confirm what is obvious to the rest: she doesn’t enjoy working “this way” and she doesn’t see any career progression opportunities with Scrum.
Pat feels betrayed. It seems like the hundreds of hours spent on convincing people and setting up the basics have been for nothing. The team hasn’t been maturing; it hasn’t even formed. Team members were living in artificial harmony by avoiding conflict. Now they feel disengaged and demonstrate no commitment. When a team fails to hold one another accountable, they demonstrate the most damaging dysfunction: inattention to results.

Pat is in an awkward situation because, though she firmly believes Scrum is not the reason for these problems, Scrum has exposed the dysfunctions. Everyone else is convinced that pre-Scrum, no dysfunctions existed. Post-Scrum, the team looks like it’s falling apart. How can Pat change this? How can she resurrect the team and prove to senior management that Scrum is worth the effort?

Can Somebody Please Explain!

I am convinced there is no easy answer to these questions; however I also believe that by following a few simple rules a lot can be done to save a dysfunctional team like Pat’s. While many sources suggest that ScrumMasters always should escalate cases like this to management, I tend to disagree. What if middle management doesn’t want to assist? What if they blame Scrum/you for the problem? What if you don’t want to lose the battle?
I should warn you that this is not something that can change overnight. If your team is experiencing these types of dysfunctions, overcoming them will require patience, good coaching, facilitation skills and then more patience. It will probably be many days, if not weeks, until you see some change. It might take as long as six-to-nine months until you start feeling optimistic about your team.

Are you willing to be vulnerable?

It all starts with trust. Let’s start there. Ask yourself these questions:

• Are you willing to be vulnerable? 
• Do you act like you are?
• Are you communicating enough to make the team aware that you are ready to make yourself vulnerable?

Talk to the team as a whole or individually. You can try a group exercise where you ask everyone to share details they otherwise would not want to. Many examples exist, but common starting points include: What is your biggest strength and greatest weakness? What was your biggest challenge in school? You also need to find a way to get the team together outside of normal work environment. This may range from organizing a night out for the whole team or attending an offsite event. Do what is appropriate for your budget. Whatever you choose, try to do the same activity at least once a month.

How will you know if you have succeeded in building trust?

• You start hearing team members answering honestly, “I don’t know.”
• Team members happily share information and offer help

Plain Talking

Politics can keep some teams from ever truly forming. I know that politics are influencing my team when people choose their words and actions based on how they want others to react rather than on what they really think. Another sign that teams are politically motivated is when attention is paid to the speaker’s rank rather than dialogue content. Politics kill progress; therefore, you need to stop political behavior immediately.

Is there a lot of whispering in the team? Do team members who express their opinions met with a negative reaction? If so, you probably have some politics interfering with your progress. Challenge each  team member to think and act as if they hold a position two levels higher in the hierarchy. Encourage honest comments regardless of how ruthless they may sound. Print out posters explaining why politics is bad; put them on the walls around your team or, if allowed, around the whole building. Protect and support your people so that they can speak openly with anyone in the company. Encourage healthy debate by asking open questions, such as: What other options do we have? What would happen if we go with this solution?

How will you know if you have succeeded in eliminating politics?

• The whispering is gone
• You can join a team discussion and no one changes the topic

What’s that Smell?

Agreement is good but be careful how you reach it. If you often feel that the team agrees too easily, if decisions are taken too quickly and meetings go too quietly, then perhaps not everything is as good as it looks. Such “easy” decisions are bad for the team because team members who feel they have not been heard will not feel fully involved.

The best thing you can do in this case is to be there as facilitator and ask the questions required to spark a healthy debate. Ask about any weakness you see; question solutions; act as the devil’s advocate.  When a debate is going in the wrong direction, try to bring back the business goal and focus the team on the responsibility and effort required to achieve a great solution. Avoid digging into too much detail – this is where you will usually lose most of your time.

How will you know if you have succeeded in eliminating agreements that smell?

• You hear team members say, "I may not agree with your ideas but I understand them and can support them."

Group or Team?

According to a popular definition, a team is a small group of people with complementary skills and abilities who are committed to a common goal and approach for which they hold each other accountable. Presumably if a group of people doesn’t meet these criteria it remains just a group of people.
Do you often notice team members not particularly interested in team decisions? Have you seen team members only interested in their propositions and not willing to discuss or support others’ solutions? Do you often hear, “This is not my area. You need to speak to X”? If so, you might be dealing with a group as opposed to a team.

A friend was telling me a story about his son. One day, after a football game, his father asked him who won. The boy answered, “I scored two goals!” His father asked again, “OK. Who won the game?” The boys then replied, “Well, the team lost 2-7, but I scored two goals. Isn’t that the important bit?”

Are members of your Scrum team more interested in their own results than in the team’s? This problem could be caused by your organization's implementation of traditional performance review process, or it could be because team members fail to see benefits in achieving a team goal.

To counteract this tendency, set team goals and make sure everyone in the team is motivated to meet these goals. Sprint targets are good goals to meet but are not always enough. Think about other goals your team could reach. Set performance objectives and individual goals that are aligned with those team goals. If this seems difficult, begin by reading about the review process for agile teams. Note that making some of these changes may be an uphill battle; you may have to enlist senior management support to win. Fight anyway. It’s the best way to avoid ambiguous goals and the resulting inattention to results behavior. Team members will still have goals to work towards but now these goals will not get in the way of team’s targets.

How will you know if you have succeeded in creating a team?

• When the sprint-targets-met rate increases significantly
• When team members start using “we” more than “I”

Fight the Good Fight

We have looked at a few common scenarios, identified team dysfunctions, and discussed ways to resolve them in a Scrum environment. Naturally, you will need to read a lot more than this one article in order to succeed but I hope I’ve given you some ideas to get you started. Remember that the battle to keep your team functional is one that you will have to keep winning over and over again. In the end, though, it’s worth the fight.

References

The Five Dysfunctions of a Team