PEARL XXIII : Guidelines for Successful and Effective Retrospectives

PEARL XXIII : Retrospectives are widely regarded as the most indispensable of people-focused agile techniques. Inspection and adaptation lie at the very heart of agility, and retrospectives focus on inspecting and adapting the most valuable asset in a software organization, the team itself. Without pursuing improvement as retrospectives require, true agility is simply not achievable. This section deals with guidelines for Successful and effective Retrospectives.

Performance can be neither improved nor maintained without exercise. Simply conducting a meeting isn’t enough to be successful, however. Attention must be paid to ensuring teams plan improvements. If a plan to improve is not part of the outcome, it wasn’t actually a Sprint Retrospective.

When done well, retrospectives are often the most beneficial ceremony a team practices. When done poorly, retrospectives can be wasteful and grueling to attend.

Without deliberately maintaining and improving performance, systems trend toward entropy and degrade over time. This is as true of software development teams as it is of professional athletes and expensive sports cars. That’s why Scrum prescribes the Sprint Retrospective, a regularly occurring event focused on the health and performance of the Scrum Team itself. Sprint Retrospectives are meetings in which Scrum Teams reflect on themselves and their work, producing an actionable plan for improving. Sprint Retrospectives are the final event in each Sprint, marking the end of each Sprint cycle. The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
The purpose of the Sprint Retrospective is to:

  • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  • Identify and order the major items that went well and potential improvements; and,
  • Create a plan for implementing improvements to the way the Scrum Team does its work.Sprint Retrospectives are used by teams to deliberately improve. Effective Sprint Retrospectives are an important ingredient in helping good teams become great and great teams sustain themselves.

Why Retrospectives Matter

Retrospectives are widely regarded as the most indispensable of people-focused agile techniques. Inspection and adaptation lie at the very heart of agility, and retrospectives focus on inspecting and adapting the most valuable asset in a software organization, the team itself. Without pursuing improvement as retrospectives require, true agility is simply not achievable.

Performance can be neither improved nor maintained without exercise. Simply conducting a meeting isn’t enough to be successful, however. Attention must be paid to ensuring teams plan improvements. If a plan to improve is not part of the outcome, it wasn’t actually a Sprint Retrospective. When done well, retrospectives are often the most beneficial ceremony a team practices. When done poorly, retrospectives can be wasteful and grueling to attend.

Anatomy of a Healthy Sprint Retrospective

Scrum says little about the internal structure of Sprint Retrospectives. Rather than prescribing how the Sprint Retrospective is conducted, Scrum specifies the output of the Sprint Retrospective: improvements the Scrum Team will enact for the next Sprint.

This flexibility has birthed a wide array of tools and techniques specifically designed to conduct retrospectives. Several popular practices are described later in this article, but regardless of the specific technique used, good Sprint Retrospectives have these characteristics:

  • The entire team is engaged
  • Discussion focuses on the team rather than individuals
  • The team’s Definition of Done is visited and hopefully expanded
  • A list of actionable commitments is created
  • The results of the previous Sprint Retrospective are visited
  • The discussion is relevant for all attendees

The entire Scrum Team attends each Sprint Retrospective. Usually, this means the Product Owner and Development Team attend as participants while the Scrum Master facilitates the meeting. In some cases, Scrum Teams invite other participants to the meeting. This can be especially helpful when working closely with customers or other stakeholders. Regardless of who attends, the environment for Sprint Retrospectives must be safe for all participants. This means attendees must be honest and transparent while treating others with respect. Passions can ignite in retrospectives as issues of performance and improvement are discussed; skilled facilitators ensure discussions stay positive and professional, focusing on improvement of the team as a whole. This is not an opportunity for personal criticism or attack. Increasing the Definition of Done Development Teams in Scrum use a Definition of Done to note what must be true about their work before it is considered complete. For example, a Development Team may decide that each feature it implements must have at least one passing automated acceptance test. Or the team’s Definition of Done may state that all code must be peer reviewed.

A Development Team’s Definition of Done is meant to expand over time. A newly formed team will invariably have a less stringent and smaller Definition of Done than a more mature team with a shared history of improving. Expanding a team’s Definition of Done lies at the very core of Kaizen, a Japanese term meaning a mindful and constant focus on improvement. While a team may initially require only that code build before being checked in, over time they should evolve more exacting standards like the need for unit tests to accompany new code. With each Sprint, Development Teams hopefully learn something that informs the expansion of the Definition of Done. The Sprint Retrospective is the perfect forum for discussing what was observed and learned during the Sprint and what changes might be made to the Definition of Done as a result. Because not every Product Owner has interest or involvement in internal Development Team practices, some Scrum Teams divide the Sprint Retrospective into two different phases:

  1. Focus on the entire Scrum Team
  2. Focus on the Development Team

Making Actionable Commitments

Although discussion may diverge and converge during the meeting, no Sprint Retrospective is successful if it doesn’t result in commitments by the team. It is not enough to simply reflect on what happened during the Sprint. The Scrum Team makes actionable commitments for what it will:

  1. Keep doing
  2. Start doing
  3. Stop doing

The word “actionable” is significant. Actionable commitments have clear steps to completion and acceptance criteria, just like a good requirement. An actionable commitment is clearly articulated and understood by the team. When teams first start performing retrospectives, they often find it easier to identify problems than plan what to do about them. Accordingly, the commitments published by the team may look like these:

  • Work in smaller batches
  • Make requirements easier to read
  • Write more unit tests
  • Be more accurate when estimating

These are not commitments; they are either goals or perhaps thinly veiled complaints. These are certainly issues that teams may wish to discuss during the Sprint Retrospective, but a list of actionable commitments looks more like this:

  • Check in code at least twice per day: before lunch and before going home
  • Express new Product Backlog items as User Stories and include acceptance criteria
  • Create a failing automated test that proves a defect exists before fixing it
  • Use Planning Poker during Product Backlog grooming sessions

Commitments made in the previous Sprint Retrospective are visited in each new Sprint Retrospective. This is necessary for retrospectives to retain their meaning and value. Few things are as frustrating as being on a team that continually commits to improving itself without making tangible progress toward doing so. For the Sprint Retrospective to be valuable team members must be more than present, they must be invested. Collaborating to create actionable commitments engages attendees and invests them in the success of the team.

Keeping it Relevant

Sprint Retrospectives are fundamentally a technique used to reveal the practices and behaviors of the Scrum Team to itself. When a self-organizing system becomes self-aware, it self-corrects and deliberately improves when given the tools to do so.

For retrospectives to be useful, they must be meaningful to the participants. If the focus isn’t on something valued by the participants, benefits will simply not be realized. The team must be allowed to consider and improve in areas it believes are important. Further, if a facilitator or dominant personality is driving the retrospective to a specific conclusion, the team avoids taking responsibility for itself and its work. Topics visited should be relevant for all levels of expertise. For example, there is little value in visiting the fine points of advanced Test-Driven Development (TDD) scenario if some team members aren’t even familiar with unit tests. The real value may be in deciding to increase the number of tests the team is writing, in getting some training, or in having a team member confident in TDD coach others.
Keep the focus on the Scrum Team, not the individual, and not the broader organization. Focusing holistically allows the team to genuinely see itself as a self-organizing unit, rather than as a loose confederation of individuals. Addressing issues of individual performance is not appropriate during a team retrospective. Not only is personal feedback most appropriately given in private, individual behaviors are not something the team can change together.
Having the team focus on one individual during a Sprint Retrospective is recipe for disaster and may result in irreparable harm to team member’s trust of each other. For retrospectives to be meaningful, they should focus on issues the team can control. Criticizing a company-wide vacation policy may be gratifying for the complainer looking for a sympathetic ear, but does little to help the team improve. Attention must be paid to those issues the team can affect itself, like the reaction it may choose to a particular policy.

Varying the Techniques

There are numerous techniques for conducting retrospectives. Trying different constructions of the Sprint Retrospective meeting keeps things fresh and interesting. As the primary facilitators for the Scrum Teams, Scrum Masters should at least be familiar with some of the more popular techniques.

There are books about retrospectives and blog articles aplenty to help people get the most from their practice. Some of the most popular are briefly described here.

In the most basic of Sprint Retrospective’s a facilitator simply asks basic questions of the team and facilitates discussion. The facilitator or Scrum Master may use various brainstorming techniques to get the team to answer:

  1. What went well in this Sprint?
  2. What happened in this Sprint that could use improvement?
  3. What will we commit to doing in the Sprint?

One simple technique to derive these answers has each team member write 2-3 answers to these questions on sticky notes during a 3-5 minute period of silence. Once created, the suggestions are grouped on a wall for all to see before being voted upon. A list of actionable commitments can thereby be derived from the collective wisdom of the team. Most other Sprint Retrospective techniques are variations on this theme and may focus on only one question or stage of this process. In any case, the outcomes are most important and any good technique supports this basic model.

Reviewing Previous Commitments

In addition to looking ahead to the next Sprint, each Sprint Retrospective should include a review of commitments made in the previous Sprint and a discussion about the team’s success in meeting those commitments. If this discussion isn’t part of each Sprint Retrospective, attendees soon learn their commitments don’t matter, and they’ll stop meeting them.

Further, the right place to review Sprint Retrospective commitments is throughout the Sprint, not just at the end. Once commitments for improvement are made, posting them publicly can help ensure they are considered on a daily basis. Some teams value posting commitments made during Sprint Retrospectives on the wall in a public area as a reminder to everyone what they should be focusing on improving each day.

There are many other techniques for conducting parts or the whole of the Sprint Retrospective. The names of many techniques are listed below and each is worthy of detailed discussion. All of the following are well documented online and in various publications.

Techniques for Sprint Retrospectives
Fishbowl

A fishbowl conversation is a form of dialog that can be used when discussing topics within large groups. Fishbowl conversations are usually used in participatory events like Open Space Technology and Unconferences. The advantage of Fishbowl is that it allows the entire group to participate in a conversation. Several people can join the discussion.Four to five chairs are arranged in an inner circle. This is the fishbowl. The remaining chairs are arranged in concentric circles outside the fishbowl. A few participants are selected to fill the fishbowl, while the rest of the group sit on the chairs outside the fishbowl. In an open fishbowl, one chair is left empty. In a closed fishbowl, all chairs are filled. The moderator introduces the topic and the participants start discussing the topic. The audience outside the fishbowl listen in on the discussion.In an open fishbowl, any member of the audience can, at any time, occupy the empty chair and join the fishbowl. When this happens, an existing member of the fishbowl must voluntarily leave the fishbowl and free a chair. The discussion continues with participants frequently entering and leaving the fishbowl.

Depending on how large your audience is you can have many audience members spend some time in the fishbowl and take part in the discussion. When time runs out, the fishbowl is closed and the moderator summarizes the discussion.An immediate variation of this is to have only two chairs in the central group. When someone in the audience wants to join the two-way conversation, they come forward and tap the shoulder of the person they want to replace, at some point when they are not talking. The tapped speaker must then return to the outer circles, being replaced by the new speaker, who carries on the conversation in their place.In a closed fishbowl, the initial participants speak for some time. When time runs out, they leave the fishbowl and a new group from the audience enters the fishbowl. This continues until many audience members have spent some time in the fishbowl. Once the final group has concluded, the moderator closes the fishbowl and summarizes the discussion 

Mad Sad Glad

  1. Divide the board into three areas labelled:
    • Mad – frustrations, things that have annoyed the team and/or have wasted a lot of time
    • Sad – disappointments, things that have not worked out as well as was hoped
    • Glad – pleasures, things that have made the team happy
  2. Explain the meanings of the headings to the team and encourage them to place stickies with their ideas for each of them under each heading
  3. Wait until everyone has posted all of their ideas
  4. Have the team group similar ideas together
  5. Discuss each grouping as a team identifying any corrective actions

Starfish

  1. Draw a large circle on a whiteboard and divide it into five equal segments
  2. Label each segment ‘Start’, ‘Stop’, ‘Keep Doing’, ‘More Of’, ‘Less Of’
  3. For each segment pose the following questions to the team:
    • What can we start doing that will speed the team’s progress?
    • What can we stop doing that hinders the team’s progress?
    • What can we keep doing to do that is currently helping the team’s progress?
    • What is currently aiding the team’s progress and we can do more of?
    • What is currently impeding the team’s progress and we can do less of?
  4. Encourage the team to place stickies with ideas in each segment until everyone has posted all of their ideas
  5. Erase the wheel and have the team group similar ideas together. Note that the same idea may have been expressed in opposite segments but these should still be grouped together
  6. Discuss each grouping as a team including any corrective actions

Problem Tree
A great technique to solve some of these is to use a problem solving tree. What you need is some post it notes, markers and a large wall or whiteboard.

  1. Start with an problem you need to solve, that you’ve identified in the retrospective.
  2. Write this on a sticky note, and stick it at the top of the tree.
  3. Now ask what participants what you can do to solve the problem.
  4. For each different idea put a sticky note below the first, at the same level.
  5. For each of these nodes do the same and build up a tree structure similar to an organisation chart.
  6. For each idea you put up, ask if it can be done in a single sprint, and if everyone understands what they need to do. If the answer is no, break it down smaller and make another level in the problem solving tree.
  7. Once you have some lower levels that are well understood and easy to implement in a single sprint, dot vote to see which to tackle in the next sprint. Try to only pick one and get it done, rather than lots that go nowhere.

Sailboat Retrospective

SailBoat

  1. Draw a boat on a white board. Include the following details:
    • Sails or engines  – these represent the things that are pushing the team forward towards their goals
    • Anchors – these represent the things that are impeding the team from reaching their goals
  2. Explain the metaphors to the team and encourage them to place stickies with their ideas for each of them on appropriate area of the drawing
  3. Wait until everyone has posted all of their ideas
  4. Have the team group similar ideas together
  5. Discuss each grouping as a team including any corrective actions going forward

Top 5

Use:
Expose the most pressing issues in an initially anonymous manner and determine the most effective actions to resolve them.
Length of time:
Approximately 45 minutes depending on the size of the team.
Short Description:
The facilitator asks participants to bring along their top five issues which are then grouped and in pairs the participants create actions to resolve them them before voting on the top actions which are taken away.
Materials:
Whiteboard or flipchart paper & pens.
Process:

  1. Before the retrospective provide participants with a simple Word document template and ask them to identify their top 5 issues (one per template) and for each issue suggest as many solutions as possible. The template is to ensure participants can be as anonymous as possible.
  2. Collect all the print-outs, spread them on the table and ask the team to group relevant issues.
  3. Ask for a title for each group, create a column for each one on a whiteboard (or flip chart sheets stuck to the wall) and place the associated print outs on the floor below.
  4. Get participants to form pairs (preferably with someone they don’t normally work too closely with) and give them three minutes with each column to come up with as many actions as they can and to write them in the column. Pairs are able to refer to the print outs and previous pairs’ actions for inspiration.
  5. After three minutes pairs move on to another column until all are exhausted.
  6. Go through all the actions so all participants are aware of them all.
  7. Give each participant three votes and ask them to choose their favourite actions (can use votes however they wish e.g. 3 on one action).
  8. Identify the most popular actions and ask for volunteers to own them. Make it clear it will be their responsibility to ensure they get completed before the next retrospective (tip: don’t choose too many actions and definitely no more than one action per participant).
  9. As with all retrospective output Agilists find the best way to ensure they get actioned is to stick them up on the wall somewhere everyone can see.

Other Techniques

  • Journey Lines
  • 6 Thinking Hats
  • Appreciative Retrospective
  • Top 5
  • Plan of action
  • Race Car
  • The Abyss
  • The Perfection Game
  • The Improvement Game
  • Force Field Analysis
  • Four L’s
  • World Café
  • Emotional Seismograph

Two particularly rich resources for facilitators looking to expand their retrospective toolboxes are:

Sprint Retrospectives aren’t the Scrum Master’s playground. Newly minted Scrum Masters are sometimes tempted to vary the techniques wildly from Sprint to Sprint. While variety in retrospectives prevents teams falling into a rut, tempering this with some consistency will yield the best results. Teams focusing on actionable outcomes will see the most value from their retrospectives.

Why Retrospectives Dont Work

Worse than being ineffective or a waste of time, badly run Sprint Retrospectives can be destructive and harmful to the team. For this reason, having a skilled facilitator conduct the meeting is highly recommended, especially when teams are new to the practice.Facilitation is typically the job of the Scrum Master, but for Scrum Masters new to the role, this may not be an area of expertise. It requires more than a working knowledge of Scrum for Sprint Retrospectives to have positive outcomes; it requires facilitation skills and the ability to lead a group away from negative discussion toward positive outcomes.

Common Smells

A common example of a bad retrospective is one that deteriorates into a gripe session. It is much easier to remember that went poorly than to identify things that went well, and a trickle of “improvement suggestions” can easily turn into a torrent of complaints when the facilitator doesn’t redirect this conversation.
Other smells that a Sprint Retrospective isn’t working well include:

  • Considering the retrospective a “post-mortem” or “after-action” report rather than an opportunity to plan for improvement
  • Unengaged attendees
  • Critiquing a single person’s performance
  • No resulting actionable commitments
  • Having no “what we did well” answers; teams need to understand and appreciate their positive as well as negative behaviors and practices

In all of the above situations, it is often easy to trace the root cause of the negativity to a lack of trust and commitment on the part of one or more team members. While there is no silver bullet to address this, Scrum specifically charges the Scrum Master with working toward addressing situations like these.

Although Sprint Retrospectives are powerful and valuable events, they are a commonly discarded element of Scrum. Scrum Teams with recent and regular success tend to rationalize away the need to conduct Sprint Retrospectives. This is rather like a fit person deciding to stop exercising.

The meta-conversation may sound a bit like the following: Six Months after Introducing Scrum
Developer Dave: Quality is up, bugs are down. Morale is high, manual regression cost is low. Since we are doing so well, we don’t need the Sprint Retrospectives to help us improve anymore.
Boss Bob: That sounds reasonable. Cancelling that meeting will save us time that can be spent on adding more features.
Six Months Later
Boss Bob: Quality has dropped and bugs are increasing. Team members are dissatisfied and much of the regression work is being performed manually.
Developer Dave: It’s because of Scrum. We told you that it wasn’t a silver bullet and it obviously doesn’t work.
Boss Bob: True. I’ll find a methodology consultant to implement a new process.Obviously, it wasn’t Scrum that failed here. The organization’s decision to omit a key ingredient of Scrum’s success was the catalyst for failure. Unfortunately this scenario is all too common.

Scrum Teams reaching that most tenuous state of high performance are rare, beautiful, and fragile. Meaningful retrospectives are a significant ingredient in keeping those teams functioning at such high levels. Reflecting upon itself allows the team to self-adjust and achieve even higher levels of performance and product quality. This is the very essence of Kaizen, and core to any real program of improvement.

When retrospectives work, the results are palpable. There is an excitement in the team to try new things. When retrospectives work, these things will inevitable be true:

  • The team achieves measurably higher and higher levels of quality over time
  • Individuals understand their role within the context of the team
  • Actionable commitments are known by all team members

Finally, when Sprint Retrospectives work well, the team grows more focused, productive, and valuable to the organization. Excellent software development teams do not simply appear. They emerge over time and then only by deliberate attention to improvement. Sprint Retrospectives are a key ingredient in that emergence.

Common Pitfalls

  • A retrospective is intended to reveal facts or feelings which have measurable effects on the team’s performance, and to construct ideas for improvement based on these observations. It will not be useful if it devolves into a verbal joust, or a whining session.
  • On the other hand, an effective retrospective requires that each participant feel comfortable speaking up. The facilitator is responsible for creating the conditions of mutual trust; this may require taking into accounts such factors as hierarchical relationships, the presence of a manager for instance may inhibit discussion of performance issues.
  • Being an all-hands meeting, a retrospective comes at a significant cost in person-hours. Poor execution, either from the usual causes of bad meetings (lack of preparation, tardiness, inattention) or from causes specific to this format (lack of trust and safety, taboo topics), will result in the practice being discredited, even though a vast majority of the Agile community views it as valuable.
  • An effective retrospective will normally result in decisions, leading to action items; it’s a mistake to have too few (there is always room for improvement) or too many (it would be impractical to address “all” issues in the next iteration). One or two improvement ideas per iteration retrospective may well be enough.
  • Identical issues coming up at each retrospective, without measurable improvement over time, may signal that the retrospective has become an empty ritual.

Milestone Retrospective

Once a project has been underway for some time, or at the end of the project (in that case, especially when the team is likely to work together again), all of the team’s permanent members (not just the developers) invests from one to three days in a detailed analysis of the project’s significant events.

Advertisements

PEARL I : SCRUM : An Introduction on Origin,Evolution,Definition,Adoption and Future

PEARL I : SCRUM : An Introduction on Origin,Evolution,Definition,Adoption and Future

Origin

The first software development Scrum was created at Easel Corporation  in 1993 based on extensive research on successful projects worldwide, a deep analysis of the computer science literature, close collaboration with leading productivity experts, and decades of experience with advanced software technologies. Jeff Sutherland was the Chief Engineer for the Object Studio team that defined roles, hired the first Product Owner and ScrumMaster, developed the first Product Backlog and Sprint Backlog and built the first portfolio of products created with Scrum. They built the first object-oriented design and analysis tool that  incorporated round-trip engineering in the initial SCRUM. A second SCRUM  implemented the first product to completely automate object-relational mapping in an  enterprise development environment. Jeff was assisted by two world-class developers, Jeff  McKenna, now an extreme programming (XP) consultant, and John Scumniotales, now a  development leader for object-oriented design tools at Rational Corporation.

There were some key factors that influenced the introduction of SCRUM at Easel Corporation. The book “Wicked Problems, Righteous Solutions” (DeGrace and Stahl 1990) reviewed the reasons why the waterfall approach to software development does not work for software development today. Requirements are not fully understood before the  project begins. The user knows what they want only after they see an initial version of the  software. Requirements change during the software construction process. And new tools  and technologies make implementation strategies unpredictable. DeGrace and Stahl  reviewed “All-at-Once” models of software development which uniquely fit object oriented implementation of software.
In 1995, Jeff introduced the Scrum team to Ken Schwaber, CEO of Advanced Development Methods. Ken agreed that Scrum was a better way to build software and they worked together to formalize the Scrum development process at OOPSLA’95 . In the same year, Sutherland provided support for development of eXtreme Programming by giving Kent Beck all background information on the creation of Scrum and the results of two years of product development with the Scrum process from 1993-95. XP engineering practices evolved along with Scrum and the two leading Agile development processes work well together. Scrum and XP are the most widely used Agile processes worldwide and their creators are signatories of the Agile Manifesto.

One of the influences that sparked the creation of the Scrum Agile development process was a Harvard Business Review paper on Japanese new product  development by Takeuchi and Nonaka  . A key  component of their presentation was a chart showing product development separated into silo’s (Type A),  phases slightly overlapped (Type B), and all phases of  development overlapping (Type C). The Authors viewed  Type A product development as implemented at NASA as  an outmoded relay race process. Fuji-Xerox abandoned the  NASA approach for Type B which they called “Sashimi”  because slices of work overlapped with collaboration  between phases. Type C was implemented at Canon and  Honda. Takeuchi and Nonaka envisioned Types B and C as  a Rugby approach where multiple phases of product  development are done simultaneously. Scrum is a Rugby  formation and they viewed an “all-at-once” process as  similar to a Rugby team moving down the field passing the  ball back and forth

Jeff Sutherland got the name “Scrum” from the famous article “The New New Product Development Game,” which was published by Takeuchi and Nonaka in the Harvard Business Review in 1986. This article describes how companies like Honda, Cannon, Fuji-Xerox produced world class results using a scalable, team based approach to all at once product development. It also emphasizes the importance of empowered self organizing teams and outlines managements role in the development process.

On the first page of the article they write: “Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead companies

in Japan and the United States are using a holistic method – as in rugby, the ball gets passed within the team as it moves as a unit up the field.

The Evolution

Evolution occurs in dynamic response to environmental demands.

After discussing the notion of various types of Scrum  with Certified ScrumMasters in Scrum Alliance workshops  and with development teams at Microsoft, Yahoo, Ariba,  Adobe, GE Healthcare, and other companies, it appeared  that the chart in article can be applied to a higher level of  thinking about three types of Scrum—going beyond the  thinking of Takeuchi and Nonaka

In a Type A Scrum, all development occurs in an increment within the time box of Scrum iteration called a Sprint. A side effect of this approach is downtime between iterations when reorganizing for the next Sprint. Nevertheless, well executed Sprints can double productivity and repeatedly deliver projects on time, within budget, with functionality precisely targeted to end-user demands.
By adding product definition tasks for the next Sprint into the current Sprint, a Type B Sprint allows work to flow smoothly from Sprint to Sprint. Product backlog requirements for the next Sprint are developed in the current Sprint. This has enabled some development organizations to deliver more working product than sales, marketing, or customers can absorb. The development bottleneck is eliminated and the company can adopt new strategies and create new products that were previously impossible to deliver.
Type C Sprint can be envisioned as overlapping Sprints by running software releases through the same Scrum team at the same time. This requires experienced Scrum teams, well designed product architecture, and automation of Product and Sprint backlogs. Throughput can be enhanced to deliver dozens of new releases of enterprise software annually. Competitors can be overwhelmed and market dominance achieved.

Type C Scrum increases speed of development,  aligns individual and corporate objectives, creates a  culture driven by performance, supports shareholder  value creation, achieves stable and consistent  communication of performance at all levels, and enhances  individual development and quality of life

To deal with simultaneous weekly and monthly  Sprints, along with quarterly major releases, a MetaScrum  was formed at PatientKeeper led by the lead Product  Owner. This is a weekly meeting that typical takes 1.5  hours and includes the CEO and other senior  management, as well as leadership from marketing,  development, quality assurance, installation, and support.
Takeuchi and Nonaka observed that collapsing phases of product development improved innovation, throughput, time to market, and product acceptance. As market pressures have evolved and changed, it is possible to collapse Scrum Sprints to create a dramatic increase in business opportunity.

Sutherland and Schwaber evolved  Scrum through trial and error at a number of companies during the  s – NewsPage, IDX Systems, Fidelity Investments, and PatientKeeper.  The Daily Scrum, the burndowns and  the Sprint Backlog were added, and  planning Sprints were dropped. !e  importance of self-managing, cross functional teams became apparent and a bedrock to Scrum.

Schwaber also collaborated with process control scientists at DuPont to tie Scrum to first principles in industrial process control theory, learning that the reason Scrum worked was
that it was empirical.

“In , the Agile Manifesto was formed,” says Schwaber. “!e signatories gathered in SnowBird because they felt their approach to software development had  something in common that was far better and more people-oriented than the  emerging favored process of the day, Rational Unified Process. !e principles  of the manifesto are the common touch
points that we agreed upon.”
Today, Schwaber notices that the term “Agile” is often used in a careless way.“Many people think that there are Agile processes. There aren’t. There are processes that conform to the Agile  Manifesto principles, such as Scrum and  Extreme Programming. However, the  word Agile is often used as a description  for ‘we aren’t using waterfall.’ That is not what Agile means!”
In Schwaber’s mind, Scrum and Agile  started emerging for two reasons: The Agile Manifesto was a rallying point for dissatisfaction and a new  approach. The emergence of new IDEs  that were as powerful as SmallTalk, like VisualStudio and Eclipse, were the technological enablers.

Scrum has streamlined software development — and professionals from around the world are starting to see the value of using Scrum. Of all the possible Agile frameworks used by companies, 66 percent are Scrum or Scrum variants.

Scrum has the power to transform project management across every industry, every business, and even across life in general. By using Scrum, teams become more Agile, discovering how to react more quickly and respond more accurately to the inevitable change that comes in the teams way. And by staying focused, collaborating, and communicating, you can accomplish what truly needs to be done — successfully.

Most important, Scrum is not unproven hype. It’s a solid and successful Agile framework that’s been applied to a variety of projects and teams. Universities use Scrum to deliver valued projects to clients. Militaries have relied on Scrum to prepare ships for deployment. In the automotive world, Team Wikispeed is using Scrum to build a fast, affordable, ultra-efficient, safe commuter car that should sell for less than $20,000.

So whether you’re working on the next smartphone app, managing logistics for a store, or planning a charity event, you should take a closer look at using Scrum. And Scrum Alliance can give you the proven framework, best implementation practices, and supportive guidance you need to achieve success.

The most profitable software product ever created (Google Adwords ) is powered by Scrum and the most productive large project with over a million lines of code (SirsiDynix and Starsoft) used a distributed, outsourced, Scrum implementation. CMMI Level 5 companies cut costs in half with Scrum while simultaneously improving quality, customer satisfaction, and the developer experience (Systematic Software Engineering). At the same time, Scrum remains the process of choice in small entrepreneurial companies where it has it roots.

Scrum Theory
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that  knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.  Three pillars uphold every implementation of empirical process control: transparency,  inspection, and adaptation.

Transparency
Significant aspects of the process must be visible to those responsible for the outcome.
Transparency requires those aspects be defined by a common standard so observers share a  common understanding of what is being seen.
For example:

  • A common language referring to the process must be shared by all participants; and,
  • Those performing the work and those accepting the work product must share a common definition of “Done”

Inspection
Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect  undesirable variances. Their inspection should not be so frequent that inspection gets in the way  of the work. Inspections are most beneficial when diligently performed by skilled inspectors at  the point of work.
Adaptation
If an inspector determines that one or more aspects of a process deviate outside acceptable  limits, and that the resulting product will be unacceptable, the process or the material being  processed must be adjusted. An adjustment must be made as soon as possible to minimize  further deviation.
Scrum prescribes four formal events for inspection and adaptation, as described in the Scrum

  •  Sprint Planning
  •  Daily Scrum
  •  Sprint Review
  •  Sprint Retrospective

Definition

Scrum is based on small set of values, principles, and practices called collectively the Scrum Framework. Organizations using scrum shall use the scrum framework entirely perhaps not through the entire organization at once, but certainly within the initial teams that use scrum

Core Scrum — Values and roles

Values from the Agile Manifesto

Scrum is the best known of the Agile frameworks. It is the source of much of the thinking behind the values and principles of the Agile Manifesto, which forms a common basis for all of these approaches.

The Agile Manifesto values apply directly to Scrum:

  • Individuals and interactions over processes and tools. Scrum, like all the Agile frameworks and methods, relies directly on trust in teams, the individuals in the teams, and the way they interact. Teams figure out what is to be done, teams figure out how to do it, and teams do it. Teams identify what’s getting in their way, and they take the responsibility to resolve all the difficulties that are within their scope. Teams work with other parts of the organization to resolve the concerns that are outside their control. This is critical. Trying to do Scrum but undermining this primary focus on team responsibility and autonomy will generally lead to trouble.
  • Working software over comprehensive documentation. Scrum requires a working, finished increment of the product as the primary result of every sprint. Certainly there will be analysis work, design work, and testing work, all of which may need to be documented. But it is having a result (working software) that allows the organization to guide the project to success. This is critical. Scrum teams must produce a product increment in every sprint.
  • Customer collaboration over contract negotiation. The Scrum product owner is the Scrum team’s prime point of contact with the eventual end users of the product. The product owner is a member of the team and works collaboratively with the team to determine what needs to be done. In this collaboration, the product owner selects the most valuable next things to do, ensuring that the product has the highest possible value at every point in time. This is critical. The product owner needs to build a rich collaboration with the team.
  • Responding to change over following a plan. Everything about Scrum is designed to make sure that everyone has the information they need to make good decisions about the project. The project’s progress is represented by a real, running product increment. The backlog of things to be done is available for all to see. Progress, both overall and sprint by sprint, is clearly visible. Problems and concerns are discussed openly and dealt with immediately. This is critical. Scrum works well for teams that openly inspect what’s going on and adapt their actions to the reality. It works poorly for those who do not.

Scrum values

All work performed in Scrum needs a firm foundation of values for the team’s process and principles. With its emphasis on teamwork and continuous improvement, Scrum both creates those values and relies on them. The values are focus, courage, openness, commitment, and respect. From the team’s perspective, the values offer the following guides:

  • Focus. Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.
  • Courage. Because we are not alone, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
  • Openness. As we work together, we practice expressing how we’re doing and what’s in our way. We learn that it is good to express concerns so that they can be addressed.
  • Commitment. Because we have great control over our own destiny, we become more committed to success.
  • Respect. As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect.

If an organization will let Scrum do its work, everyone involved will discover the benefits and will begin to understand why Scrum both engenders and relies upon these values.

The Scrum framework

Scrum is a framework for building a product.

Scrum is also a team process that begins when stakeholders need a product. The Scrum team includes three roles: the product owner, the ScrumMaster, and the members of the development team. These roles are further described below. The product is built incrementally over a series of short time periods called sprints. A sprint is a fixed time period, up to four weeks long but with a preference toward shorter intervals. During each sprint, the Scrum team builds and delivers a product increment. Each increment is a recognizable, visibly improved, operating subset of the product, meeting understood acceptance criteria and built to a level of quality referred to as the Definition of Done.

Scrum includes three essential artifacts: the product backlog, the sprint backlog, and the product increment. The product backlog is the list of ideas for the product, in the order we expect to build them. The sprint backlog is the detailed plan for development during the next sprint. The product increment, a required result of every sprint, is an integrated version of the product, kept at high enough quality to be shippable if the product owner chooses to ship it.

In addition, Scrum requires transparency within the team and with the stakeholders. Therefore the Scrum team produces visible displays of plans and progress.

Scrum also includes five activities or meetings. These are the backlog refinement, sprint planning, daily scrum, sprint review, and sprint retrospective.

SCRUM project planning uses lightweight techniques such as Burndown  Charts, as opposed to PERT charts. A PERT chart is only as good as the assumptions  inherent in the critical path represented on the chart. In agile development, the critical  path usually changes daily, rendering any given PERT chart obsolete within 24 hours.  The solution is using a technique to calculate the velocity of development. The neural  networks in the brains of team members are used on a daily basis to calculate the critical  path. This allows the plan to be recalculated and the velocity of “burndown” of work to  be computed. Team efforts to accelerate or decelerate the velocity of burndown allow a  team to “fly” the project into a fixed delivery date.

SCRUM is  the only agile methodology that has been formalized and published as an organizational  pattern for software development (Beedle, Devos et al. 1999). The process assumes that  requirements will change during the period between initial specification and delivery of a  product. It supports Humphrey’s Requirements Uncertainty Principle which states that for  a new software system, the requirements will not be completely known until after the  users have used it. SCRUM allows for Ziv’s Uncertainty Principle in software  engineering – uncertainty is inherent and inevitable in software development processes  and products (Ziv and Richardson 1997). And it support Wegner’s Lemma which states  that it is not possible to completely specify an interactive system (Wegner 1995). Most  software systems built today are object-oriented implementations which depend on  environmental inputs to determine process outputs, i.e. interactive systems.

Scrum roles

Product owner

The product owner has responsibility for deciding what work will be done. This is the single individual who is responsible for bringing forward the most valuable product possible by the desired date. The product owner does this by managing the flow of work to the team, selecting and refining items from the product backlog. The product owner maintains the product backlog and ensures that everyone knows what is on it and what the priorities are. The product owner may be supported by other individuals but must be a single person.

Certainly the product owner is not solely responsible for everything. The entire Scrum team is responsible for being as productive as possible, for improving its practices, for asking the right questions, for helping the product owner.

Nonetheless, the product owner, in Scrum, is in a unique position. The product owner is typically the individual closest to the “business side” of the project. The product owner is charged by the organization to “get this product out” and is the person who is expected to do the best possible job of satisfying all the stakeholders. The product owner does this by managing the product backlog and by ensuring that the backlog, and progress against it, is kept visible.

The product owner, by choosing what the development team should do next and what to defer, makes the scope-versus-schedule decisions that should lead to the best possible product.

Development team member

The development team is made up of the professionals who do the work of delivering the product increment. Scrum requires that the development team be a cross-functional group of people who, as a group, have all the necessary skills to deliver each increment of the product.

The development team members are expected to be available to the project full time, not splitting their time over numerous projects. They have the responsibility of self-organizing to accomplish each sprint goal, producing each new product increment according to each sprint plan.

The product owner makes an ordered list of what needs to be done; the development team members forecast how much they can do in one sprint, and they decide how they are going to do it.

ScrumMaster

The ScrumMaster is a “servant leader” who helps the rest of the Scrum team follow the process. The ScrumMaster must have a good understanding of the Scrum framework and the ability to train others in its subtleties.

The ScrumMaster helps the product owner understand how to create and maintain the product backlog. He or she works with the entire Scrum team to evolve the Definition of Done. The ScrumMaster also works with the development team to find and implement the technical practices needed to get to Done at the end of each sprint.

Another responsibility of the ScrumMaster is to remove impediments to the team’s progress. These impediments may be external to the team (such as a lack of support from another team) or internal (such as the product owner not knowing how to properly prepare the product backlog). That said, the ScrumMaster fosters self-organization, meaning that the team itself should remove issues wherever possible.

The ScrumMaster may facilitate meetings and always acts as a coach for the Scrum team, helping it execute the Scrum process. He or she helps team members work together and learn the Scrum framework, and protects them from both internal and external distractions. The ScrumMaster keeps the Scrum team on track, productive, and growing in ability.

Ultimately, the ScrumMaster is responsible for ensuring that Scrum is understood and in place, inside the team and outside. He or she helps people outside the team understand the process and the kinds of interactions with the team that are helpful (and those that are not). The ScrumMaster helps everyone improve to make the Scrum team more productive and valuable.

Artifact: Product backlog

The product backlog is crucial tool that enables the scrum team to achieve fast, flexible, value delivery flow in the presence of uncertainty.

The product backlog is an essential artifact in Scrum. It is an ordered list of ideas for the product, kept in the order in which the team expects to do them. It is the single source from which all requirements flow. This means that all the work the development team does comes from the product backlog. Every feature idea, enhancement, bug fix, documentation requirement — every bit of work the team does — is derived from a product backlog item. Each item on the product backlog includes a description and an estimate of the team capacity required to produce it.

Scrum Overview

The product backlog may begin as a large list or a short one. It may be vague or detailed. Typically, it begins short and vague and becomes longer and more concrete as time goes on. Product backlog items slated for implementation soon will be clarified, better defined, and split into smaller chunks as part of the product backlog refinement activity.

The Product Owner is accountable for maintaining the product backlog, although he or she may — and should — have help in producing it and keeping it up to date. Individual product backlog items may originate from the Product Owner, from team members, or from other stakeholders.

Activity: Product backlog refinement

Since product backlog items are often large and general in nature, and since ideas come and go and priorities change, product backlog refinement is an ongoing activity throughout a Scrum project. This activity includes but is not limited to:

  • Keeping the product backlog ordered
  • Removing or demoting items that no longer seem important
  • Adding or promoting items that arise or become more important
  • Splitting items into smaller items
  • Merging items into larger items
  • Estimating items

One key benefit of the product backlog refinement activity is that it helps prepare for upcoming sprints. Considerations include but are not limited to:

  • Whether each item entering the sprint truly represents an increment of “business value”
  • Whether the development team needs to be able to build each item within just a single sprint
  • Whether everyone on the team has a clear understanding of the purpose of each item

Depending on the nature of the product, other skills and inputs may be necessary. In every case, product backlog refinement is best considered as an activity for all team members, not just for the Product Owner.

Activity: Sprint planning

Each sprint begins with a time-boxed meeting called the sprint planning meeting. In this meeting the Scrum team collaborates to select and understand the work to be done in the upcoming sprint.

The entire team attends the sprint planning meeting. Working from the ordered product backlog, the Product Owner and the development team members discuss each item and come to a shared understanding of that item and what is required to complete it according to the current Definition of Done. All Scrum meetings are time-boxed. The recommended time for the sprint planning meeting is two hours or less per week of sprint duration. Because the meeting is time-boxed, the success of the sprint planning meeting is highly dependent upon the quality of the product backlog going in. This is why product backlog refinement is an important Scrum activity.

Scrum moves control from a central scheduling dispatching authority to individual teams doing the work.

In Scrum, the sprint planning meeting is described as having two parts:

  1. Determine what work will be completed in the sprint
  2. Determine how the work will be accomplished

In the first part of the meeting, the Product Owner presents ordered product backlog items to the development team, and the whole Scrum team collaborates to understand the work.

The number of product backlog items to undertake in the sprint is solely up to the development team. To decide how many items to undertake, the development team considers the current state of the product increment, the past performance of the team, the team’s current capacity, and the ordered product backlog. The development team alone decides how much work to take on. Neither the Product Owner nor any other agency can push more work onto the development team.

Often, but not always, the sprint has a goal. Having a sprint goal is a strong practice that helps everyone focus more on the essence of what needs to be done and less on small details that may not truly be important for the final product.

In the second part of the meeting, the development team collaborates to decide how to produce the next product increment in accordance with the current Definition of Done. The team does sufficient design and planning to be confident of completing the work during the sprint. Work to be done in the early days is broken down into small units of one day or less. Work to be done later may be left in larger units to be decomposed later.

Deciding how to do the work is the responsibility of the development team, just as deciding what to do is the responsibility of the Product Owner.

The Product Owner needs to be readily available to the team even if he or she does not attend this part of the meeting. However, the Product Owner may remain to answer questions and resolve misunderstandings.

Sprint planning concludes with the Scrum team reaching a common understanding of the quantity and complexity of what is to be accomplished during the sprint and with a rational expectation of being able to complete it. The development team forecasts the amount of work it will complete and commits to accomplishing it.

To summarize, in the sprint planning meeting the development team:

  • Considers and discusses product backlog items with the Product Owner
  • Ensures that all team members understand those items
  • Selects a number of items to achieve
  • Creates a sufficiently detailed plan to ensure that achievement

The resulting list of things to do is the sprint backlog.

Artifact: Sprint backlog

The sprint backlog is the list of refined product backlog items chosen for development in the current sprint, together with the team’s plan for accomplishing that work. It reflects the team’s forecast of what work can be completed.

With the sprint backlog in place, the sprint begins, and the development team develops the new product increment defined by the sprint backlog.

Development

During the sprint, the development team self-organizes to produce the defined product increment. Self-organizing means that the development team determines how to produce and then does produce the product increment, in accordance with organizational standards, according to the Definition of Done.

Artifact: Product increment

The most important Scrum artifact is the product increment. Every sprint produces a product increment that must be of high enough quality to be given to users. The product increment must meet the Scrum team’s current Definition of Done, and each component of it must be acceptable to the Product Owner.

Additional indicators of visible progress

Scrum requires transparency within the team and outside the team. While the product increment is the most important way of creating transparency, the Scrum team will create any other artifacts that are needed to make sure that the status of the project is understood. Such artifacts commonly include burn charts and task boards.

Definition of Done

When the product increment is delivered, it needs to be “done” according to a shared understanding of what “done” means. This definition is different for every Scrum team, and as the team matures the Definition of Done will expand and become more stringent.

The Definition of Done must always include the notion that the product increment be of high enough quality to be shippable: The Product Owner could choose to release it immediately. The product increment includes the functionality of all previous product increments and is fully tested so that all completed product backlog items continue to work together.

Activity: Daily Scrum

The self-organizing development team uses the daily Scrum meeting to ensure that it is on track for attaining the sprint goal. The meeting takes place at the same time and place, every day. Each development team member gives three pieces of information:

  • What I have accomplished since our last daily Scrum
  • What I plan to accomplish between now and our next daily Scrum
  • What (if anything) is impeding my progress

There may be brief, clarifying questions and answers, but there is no discussion of any of these topics during the daily Scrum itself. However, many teams meet right after the daily Scrum to work on any issues that have come up.

The daily Scrum is not a report to management, nor to the Product Owner, nor to the ScrumMaster. It is a communication meeting within the development team that ensures that team members are all on the same page. Only the Scrum team members, including ScrumMaster and Product Owner, speak during this meeting (although other interested parties may come and listen). Based on what comes up in the meeting, the development team reorganizes the work as needed to accomplish the sprint goal.

The daily Scrum is a key element of Scrum, leading to transparency, trust, and better performance. It provides rapid recognition of problems and builds the team’s self-organization and self-reliance. All Scrum meetings are timeboxed; the recommended timebox for the daily Scrum is no more than 15 minutes.

Activity: Sprint review

At the end of the sprint, the Scrum team and stakeholders review the sprint’s output. The recommended timebox for the sprint review is one hour per week of sprint duration.

The central point of discussion is the product increment completed during the sprint. It is generally both wise and helpful for the stakeholders to attend this meeting, since they are directly interested in the product. This is an informal meeting to look at where the team is and to collaborate on how it might go forward. Everyone has input at the sprint review. Naturally, the Product Owner makes the final decisions about what happens next, updating the product backlog as appropriate.

Every teams will find its own way to handle the sprint review. A demonstration of the product increment is a common procedure. Groups also often discuss what they observed during the sprint and what product ideas came to mind. They discuss the state of the product backlog and talk about possible completion dates and what might be achieved by those dates.

The sprint review gives everyone present an overview of the current product increment; therefore, it is common to update the product backlog as part of the sprint review.

Activity: Sprint retrospective

The Scrum team improves its own process, always remaining within the Scrum framework. Therefore, at the end of each sprint, the Scrum team meets for the sprint retrospective. The purpose is to review how things went in terms of the process, relationships among people, and the tools. The team identifies what went well and what didn’t go so well, and it identifies potential improvements. The recommended timebox for the sprint retrospective is one hour per week of sprint duration.

Rinse, repeat

This Scrum cycle repeats for every sprint.

To sum up, the Scrum team’s members (the Product Owner, the development team, and the ScrumMaster) collaborate to create a series of product increments during short, time-boxed intervals called sprints. Each increment meets the Product Owner’s acceptance criteria and the team’s shared Definition of Done. The team works from a product backlog. During each sprint, the team begins with sprint planning to produce the sprint backlog, which is a plan for the sprint. The team self-organizes to handle the development, using daily Scrum meetings to coordinate and to ensure that they are producing the best possible product increment. The team performs product backlog refinement to prepare for the next sprint’s planning meeting. It ends the sprint with the sprint review and sprint retrospective, reviewing the product and the process.

Adoption and Future

“Scrum and Agile are similar to Lean Thinking. Scrum is a new way of doing business, but there won’t be that many that reap all of its benefits – such as productivity,  quality, engaged people, and maximized return on investment. American automobile companies were immersed  in running their operations top-down, using the principles of Scientific Management to try to plan everything.
Even while Toyota began to reach their market by using flexible lean techniques, they were unable to adapt. The change in perceptions, culture, and habits was too great.  Many places that are trying to shift from the predictive  approaches of waterfall and command and control are  having the same problems. The change in thinking is  particularly hard. The improved engineering practices  to support the change are also hard. Ken Schwaber predicted that only  those organizations with compelling reason to change  and management with insight and courage will succeed.”
“John Chambers, the CEO of Cisco, put his organization through such a change over the last four years and commented that it was the hardest thing he had ever  done.

“I predict that only 15–25 % of all organizations attempting to use Scrum throughout the enterprise will  succeed in making the change and reaping the benefits. As a result, they will out-compete those who weren’t  able to change and become dominant players in their markets”

In February and March of 2013, Scrum Alliance,  ProjectManagement.com and  ProjectsAtWork surveyed their  readership on use, knowledge  and views of Scrum.  The extensive survey of nearly 500 participants included  in-depth interviews and a literature review.  Participants from more than 70 countries responded to the  survey, with the United States leading at 35% and India second at 12%. The United Kingdom,Canada and Australia accounted  for 4% each, with Germany at  3% and South Korea, Mexico,Belgium, Brazil, Malaysia and New Zealand comprising 2%.

The majority of the participants are from the IT industry (41%),but a good representation camefrom Finance (12%), Government(6%), Healthcare (6%) and Telecommunications (5%), indicating the growing interest in Scrum outside IT. 53% of the participants were from organizations with 1,000 or fewer employees, yet 44% were with companies with annual revenues of $50M to $1B+. 28% were from organizations with ISO 9001 certification, but nearly half (48%) did not have any.

Key Findings
• While 41% of organizations are jumping into Agile waters without requiring a specific certification of their employees, 54% either agree or strongly agree that a certification such as the Certified Scrum Professional (CSP) improves their chances of sustained success.
• Culture is king in the Agile world—and according to a majority of respondents, organizations must create cultures that encourage collaboration in order to deliver value to their customers. This includes fostering self-organized teams and active support from management. Scrum facilitates all of these success factors.
• Scrum is the overwhelmingly preferred Agile method, used by 40% of respondents.The second-most popular method is Kanban, often using many elements of Scrum,a noteworthy trend as organizations seek to find for themselves what works for their specific domains and needs.
How Often and Why They Use Scrum
• In terms of current Agile approaches, Scrum leads the way: 40% of those sampled claimed to be adherents. It was followed by Kanban (15%) and Lean (11%). 19% of the participants used Scrum for up to a quarter of their projects that fall outside of IT, the
majority (38%) of which are in R&D, operations or production.
• 60% of the survey participants used Scrum regularly. 39% used Scrum more broadly throughout their business as one of their project management practices, while 16% used it exclusively for software development projects. 46% of the participants are deploying and managing Scrum projects within a Project Management Office (PMO), and 24% feel that managing and deploying Scrum projects this way is effective and successful.
• In terms of business priorities for Scrum projects, 41% feel that fulfilling customer needs is highest, while meeting budget, time and scope constraints as well as engaging in projects that drive innovation and market share followed with 36%. In terms of providing customer satisfaction while using Scrum, 27% feel having active senior management support is vital,  and 22% say a clear set of business goals for what gets achieved is necessary. That is why over half felt that cultural influences such as an open and collaborative environment—and empowered/self-organizing Scrum teams—are vital for facilitating Scrum; that can only be achieved through active support of management and clear business vision.

Scrum Adoption Factors
• The common belief that the vast majority of organizations adopting and integrating Scrum come from a Waterfall-like background was supported by the survey. 24% use Scrum for some projects while using Waterfall for the rest. 13% use Scrum exclusively, while 31% indicate no use of Waterfall. 23% felt it was a difficult transition from a Waterfall-based method to Scrum. Another perception, stated by 25% of respondents, was that there were no clearly identified metrics to identify and measure the successful delivery of Scrum projects.

Scrum will continue to grow because it is poised for the “Age  of the Customer.”What lies at the  heart of Agile is the  obsessive focus on  service to the  customer—the  mainstay of almost  any business.

Scrum will continue to expand outside of software development. Another adoption of Agile
outside of software development  presents itself in the article “Agile  Reinvents Retail,” published by  John Hitchcock of SandHill.com  on September 2012. The story  describes how a California retail  outlet called Oddyssea used Agile development principles to deploy  its retail operations

Another recent and famous  example of Scrum outside  of software development is  embodied in a sports car called  Wikispeed. Built by Joe Justice, a software engineer by trade, and  a team who entered the 2008  X-Prize competition, Wikispeed  was deployed using Scrum and  crowdsourcing. The team was able  to place tenth in a crowded and  highly competitive environment.
This was done by getting a working  prototype in three months for a  car that can go from 0 to 60 mph  in less than five seconds, weighs  just 1,404 pounds, has a top speed  of 149 mph and gets more than  100 mpg—all using Agile practices  and techniques.

Scrum is well suited for complex problems, where routine cookie cutter solutions does not apply.  In complex domains the ability to probe, explore, sense,inspect, adapt,and respond is critical.