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.

Advertisements

PEARL XIII: Effective Visual Management with Information Radiators

PEARL XIII: 

Effective visual management with Information Radiators

Information Radiators

Information Radiators, also known as Big Visible Charts, are useful quite simply because they provide an effective way to communicate project status, issues, or metrics without a great deal of effort from the team. The premise is that these displays make critical, changing information about a project accessible to anyone with enough ambition to walk over to the team area and take a look.

“An Information radiator is a display posted in a place where people can see it as they work or walk by. It shows readers information they care about without having to ask anyone a question. This means more communication with fewer interruptions.”

Information Radiators are

  • Is large and easily visible to the casual, interested observer
  • Is understood at a glance
  • Changes periodically, so that it is worth visiting
  • Is easily kept up to date

“Information Radiator” is a popular term invented by Alistair Cockburn that is used to describe any artifact that conveys project information and is publicly displayed in the workspace or surroundings. Information radiators are very popular in the Agile world, and they are an essential component of visual management. Most Agile teams recognize the value of information radiators and implement them to some degree in their processes.

Information radiators take on many different shapes and sizes. Traditional implementations range from hand-drawn posters of burndown charts to coloured sticky notes on a whiteboard.

Many development teams create elaborate information radiators using electronic devices like traffic lights or glowing orbs to indicate build status. Most teams, including many at Atlassian, roll their own electronic wallboards to pull real-time data from development tools for display on large monitors over the team workspace.

Visual control is a business management technique employed in many places where information is communicated by using visual signals instead of texts or other written instructions. The design is deliberate in allowing quick recognition of the information being communicated, in order to increase efficiency and clarity. These signals can be of many forms, from different coloured clothing for different teams, to focusing measures upon the size of the problem and not the size of the activity, tokanban, obeya and heijunka boxes and many other diverse examples. In The Toyota Way, it is also known as mieruka.

The three most popular information radiators are

  • Task Boards,
  • Big Visible Charts (which includes burn downs and family) and
  • Continuous Integration build health indicators (including lava lamps and stolen street lights).

Task Boards

MockedTaskBoard

MockedTaskBoard

The most important information radiator in visual management is the Task Board. (In Scrum, Agilists sometimes call task boards as Scrum boards). The task board has the mission of visually representing the work that is being done by the team. They are the most complex and versatile artifact: a physical task board is a “living” entity that has to be manually maintained. Tasks boards are being undervalued by most agile teams today. This might be because there has not been a lot of focus on their potential, or perhaps there are simply not many examples around on what makes a great task board. In any case, it’s time to take task boards to the next level.

In its most basic form, a task board can be drawn on a whiteboard or even a section of wall. Using electrical tape or a dry erase pen, the board is divided into three columns labeled “To Do”, “In Progress” and “Done”. Sticky notes or index cards, one for each task the team is working on, are placed in the columns reflecting the current status of the tasks.

Many variants exist. Different layouts can be used, for instance by rows instead of columns (although the latter is much more common). The number and headings of the columns can vary, further columns are often used for instance to represent an activity, such as “In Test”.

The task board is updated frequently, most commonly during the daily meeting, based on the team’s progress since the last update. The board is commonly “reset” at the beginning of each iteration to reflect the iteration plan.

Expected Benefits
  • The task board is an “information radiator” – it ensures efficient diffusion of informations relevant to the whole team
  • The task board serves as a focal point for the daily meeting, keeping it focused on progress and obstacles
  • The simplicity and flexibility of the task board and its elementary materials (sticky notes, sticky dots etc.) allow the team to represent any relevant information: colors can be used to distinguish features from bug fixes, sticky orientation can be used to convey special cases such as blocked tasks, sticky dots can be used to record the number of days a task spends “In Progress”…
Common Pitfalls
  • Many teams new to Agile rush to adopt an electronic simulation (“virtual task board”) without first getting significant experience with a physical task board, even though virtual boards are much less flexible and poorer in affordances
  • Even geographically distributed teams for whom a virtual task board is a necessity can benefit from using physical task boards locally and replicating the information in an electronic tool
Origins

Sticky notes or index cards had been used for visual management of project scheduling well before Scrum and Extreme Programming brought these “low tech” approaches and their benefits back into the spotlight. However, the precise format of the task board described here did not become a de facto standard until the mid-2000’s.

  • 2003: the five-column task board format is described by Mike Cohn on his Web site; at the time, as this photo gallery collected by Bill Wake shows, very diverse variants still abound
  • 2007: the simplified three-column task board format (“To Do”, “In Progress”, “Done”) becomes, around that time, more popular and more standard than the original five-column version

What makes a great Task Board
A good task board should be carefully designed with readability and usability in mind, and the project methodology should actively rely on it. This implies that the use of the task board should be standardized and form part of the process. If task boards (and other information radiators) are not an integral part of the project methodology, maintaining them might be perceived as overhead or duplication of work. This results in boards not being updated and becoming out of sync with the work actually being done. An incomplete or stale task board is worthless.

A task board is a living entity and should be kept healthy.

You have a great task board if…

  • Team members never complain about having to use it.
  • The daily standup happens against it.
  • Random people that pass by stop to look at it, expressing interest and curiosity.
  • Your boss has proudly shown it to his boss.
  • You see team members updating it regularly during the day.
  • It passes the hallway usability test: a person who has never seen it before can understand it quickly and without explanations.
  • You catch a senior manager walking the floor and looking at it.
  • It just looks great!

Information Radiators are useful quite simply because they provide an effective way to communicate project status, issues, or metrics without a great deal of effort from the team. The premise is that these displays make critical, changing information about a project accessible to anyone with enough ambition to walk over to the team area and take a look.
Information Radiators are also good ways to remind the team of critical items, such as issues that need to be addressed, items on which the team is currently working, key models for the system on which they are working, and the status of testing.
Depending on the type of information tracked on the Information Radiators, these displays can also help the team to identify problems early. This is especially true if the team is tracking key metrics about their performance where trends in the information will indicate something is out of whack for the team. This type of information includes passing and failing tests, completed functionality, and task progress.

Using Information Radiators

As a team, determine what information would be very helpful to see plastered on a wall in plain sight. The need for an Information Radiator may be identified at the very beginning of a project, or as a result of feedback generated during a retrospective. Ideally, it will communicate information that needs to go to a broad audience, changes on a regular basis, and is relevant for the team.
Decide not only what you want to show, but the best way to convey it. There are a variety of methods to choose from, including a whiteboard and markers, sticky notes, pins, dots, or a combination of all of the above. Anything goes, as long as it is not dependent on a computer and some fancy graphics software. Unless of course you are working with a distributed team; see suggestions for that situation below.
Grab the necessary tools and get to work, but don’t forget to have a little fun with the creation process. Remember to make the Information Radiator easy to read, understand, and update. You want this to be a useful, living display of information, so don’t paint yourself into a corner at the beginning.
Remember to update the information radiator when the information changes. If you are using it to track tasks, you may change it several times a day. If you are using it to track delivery of features, it may be updated once a week or every two weeks.
Check in with the team regularly to find out if the Information Radiator is up to date and still useful. Find out if people outside the team are using it to gather information about the team’s progress without causing an interruption. Find out if there are possible improvements, or if the information radiator is no longer needed. Whatever feedback you receive, act on it.

Traffic lights , lava lamps

Traffic lights , lava lamps

Information radiators can take a variety of forms, from wallboards to lava lamps and traffic lights.

A wallboard is a type of information radiator that displays vital data about the progress of the development team. Similar to a scoreboard at a sporting event, wallboards are large, highly visible and easy to understand for anyone walking by.

Traditional wallboards are made of paper or use sticky notes on a wall. Electronic wallboards are very effective since they update automatically with real-time data ensuring that people check back regularly.

Common information radiators used in Scrum environment includes

  • Product Vision
  • Product Backlog/release plan
  • Iteration Backlog
  • Burn Down and Burn Up charts
  • Impediment List

In lean environment , information radiators are of specialized type which is called as Visual Control . In lean environment, visual controls are used to make it easier to control an activity or process through a variety of visual signals or cues.

The visual control:

  • Conveys its information visually 
  • Mirrors (at least some part of) the process being used by the team
  • Describes the state of the work‐in‐process
  • Is used to control the work‐in‐process
  • Can be viewed by anyone

Visual controls should be present at all levels: business, management, and team. That is, they should help the business see how value is being created as well as assist management and the team in building software as effectively and efficiently as possible.
The visual controls used in Lean‐Agile include

  • Product Vision : Every Agile team should have a product vision. This provides the big picture for the product: what is motivating the development effort, what the current objectives are, and the key  features. We have seen teams who were flailing about, trying to figure out what they were  supposed to be doing, suddenly gain focus when the  Product Champion produced a product vision statement
  • Product Backlog / Release Plan / Lean Portfolio
  • Iteration Backlog – simple team, multiple teams
  • Story Point Burn‐Up Chart
  • Iteration Burn‐Down Chart
  • Business Value Delivered Chart
  • Impediment List

A backlog is the accumulation of work that has to be done over time. In Lean‐Agile, the product backlog describes that part of the product that is still to be developed. Before the first iteration, it shows every piece of information that is known about the product at that time, represented in terms of features and stories. As each iteration begins, some of these stories move from the product backlog to the iteration backlog. At the end of each iteration, the completed features move off of both backlogs.
During “Iteration 0,” the features in the product backlog are organized to reflect the priorities of the business: higher‐priority features on the left and lower‐priority features on the right.

 

The entire enterprise (business, management, and development teams) also need line of sight to velocity (points/time), which, after the first few stories are done, should begin to represent the velocity of business solutions delivered. This is a clear representation of the value stream (from flow of ideas to completed work) and is mapped to the number of points that teams can sustainably deliver in a release.

We can use two visual controls working as a pair to give management a dashboard‐type view of work . The release burn‐up chart tracks cumulative points delivered with each iteration. This can be broken out or rolled up based on program, stakeholder, and so on. The feature burn‐up chart is created by using the initial high‐level estimate to calculate the percent complete after each iteration and plotting this with all features currently identified in the release plan.
This view gives the enterprise a clear visual control of current priorities, along with what work is actually in process. A Lean enterprise continuously watches out for too many features being worked on at any time—this indicates process problems and potential thrashing.

The Impediment List :  A foundation of both Scrum and Lean‐Agile is that continuous improvement includes continually removing impediments. One of the purposes of the daily meeting is to expose impediments, to make them explicit. The Scrum Master or Agile project manager must maintain a list of current impediments so that progress on resolving them can be visible to all. Entries on this list should include:

  • Date entered on list
  • Description of impediment
  • Severity of impediment (what its impact is)
  • Who it affects
  • Actions being taken to remove it

The impediment list should be maintained on an ongoing basis as impediments are removed, added, or modified in some way.

Kanban Board

In the context of Agile teams where the “Kanban method” of continuous improvement (or some of its concepts) has been followed, the following adaptations are often seen:

  • Such teams deemphasize the use of iterations, effort estimates and velocity as a primary measure of progress;
  • They rely on measures of lead time or cycle time instead of velocity; and in the most visible alteration, they replace the task board with a “kanban board”:
  • Unlike a task board, the kanban board is not “reset” at the beginning of each iteration, its columns represent the different processing states of a “unit of value”, which is generally (but not necessarily) equated with a user story.
  • In addition, each column may have associated with it a “WIP limit” (for “work in process” or “work in progress”): if a given state, for instance “in manual testing”, has a WIP limit of, say, 2, then the team “may not” start testing a third user story if two are already being worked on.
  • Whenever such a situation arises, the priority is to clear current work-in-process, and team members will “swarm” to help those working on the activity that’s blocking flow
Also Known As

The term “kanban” is Japanese  with the sense of a sign, poster or billboard, and derived from roots which literally translate as “visual board”.

Its meaning within the Agile context is borrowed from the Toyota Production System, where it designates a system to control the inventory levels of various parts. It is analogous to (and in fact inspired by) cards placed behind products on supermarket shelves to signal “out of stock” items and trigger a resupply “just in time”.

The Toyota system affords a precise accounting of inventory or “work in process”, and strives for a reduction of inventory levels, considered wasteful and harmful to performance.

The phrase “Kanban method” also refers to an approach to continuous improvement which relies on visualizing the current system of work scheduling, managing “flow” as the primary measure of performance, and whole-system optimization – as a process improvement approach, it does not prescribe any particular practices.

Common Pitfalls

Kanban boards are generally more sophisticated than “mere” task boards. This is not a mistake in and of itself; however, it is not advisable that the kanban board should serve as a pretext to reintroduce a “waterfall”-like, linear sequence of activities structuring the process of software development. This may lead to the creation of information silos or over-specialization among team members.

In particular, teams should be wary of kanban boards not accompanied by WIP limits, not only defined but also enforced with respect to demands from managers, customers or other stakehoders. It is from these limits that the kanban approach derives its effectiveness.

Expected Benefits

In some contexts, measuring lead time rather than velocity, and dispensing with the regular rhythm of iterations, may be the more appropriate choice: for instance, when there is little concern with achieving a specific release date, or when the team’s work is by nature continuous and ongoing, such as enhancement or maintenance, in particular of more than one product.

At the risk of oversimplifying, a “kanban board” setup can be considered first for efforts involving maintenance or ongoing evolution, whereas a “task board” setup may be a more natural first choice in efforts described as “projects”.

Origins
  • 2001: Mary Poppendieck’s article, “Lean Programming”, draws attention to the structural parallels between Agile and the ideas known as Lean or the “Toyota Production System”
  • 2003: expanding on their earlier work on Lean Programming, Mary and Tom Poppendieck’s book “Lean Software Development” describes the Agile task board as a “software kanban system”
  • 2007: the first few experience reports from teams using the specific set of alterations known as “kanban” (no iterations, no estimates, continuous task boards with WIP limits) are published, including reports from Corbis (David Anderson) and BueTech (Arlo Belshee)
  • 2007: the “kanbandev” mailing list is formed to provide a venue for discussion of kanban-inspired Agile planning practices
  • 2009: two entities dedicated to exploring the kanban approach are formed, one addressing business concerns, the LSSC and a more informal one aimed at giving the community more visibility: the Limited WIP Society
Flow of Work

After visualizing the work, you will be able to watch how it moves across the board. Kanban teams call this observing the Flow of Work. When there are bottlenecks in the process, or blocking issues that prevent work from being completed, you start to see it play out on the board.

Stop Starting and Start Finishing!

Kanban’s primary mechanism for improving the flow of work is the Work-in-Process Limit. You basically set a policy for the team, saying that we’ll limit how much work is started, but not finished, at any one time. When the board starts to fill up with too much unfinished work, team members re-direct their attention and collaborate to help get some of the work finally finished, before starting any more new work.

On a Kanban board, you visualize the flow of work. You can visualize how the work is flowing during the sprint through the very fast iterations of design, develop, and test that happen within each sprint.  Or, you can let the flow of work be governed by the kanban board and replace the sprint container with a regular deployment cadence instead. It’s a minor difference on the surface, but it can have a major impact.

With the sprint approach, you spend time at the beginning of every sprint trying to estimate and plan a batch of work for the entire sprint. Then you work on it and push hard to have the entire batch completed, tested and deployed by the end of the sprint.

When you’re focusing on flow and using Kanban, you could still deploy completed code every two weeks. But instead of going through the whole cycle of planning, estimating and moving a batch of work through to completion, you can move work through the system without batching two weeks of work at a time. Planning and estimating, designing, building and testing can happen for each individual item as it reaches the top of the priority list in the backlog. When there’s capacity on the Kanban board for more work (WIP limits are being honored, and people are available to do more work), they pull the next item to work on. When the two-week cadence comes around, you simply deliver whatever is ready to deliver.  This encourages members of the team to take each item all the way through to completion individually, instead of focusing on having a two-week batch of work completed at one time. You ensure that each item is Done. With a capital D. “Done-Done”, some people call it. And you get it to “Done-Done” before pulling the next item available for you to work on.

The Agile practice of iterative delivery is a huge improvement over old waterfall or stage-gate project management methods. Focusing on Flow using Kanban can sometimes be even more efficient, resulting in shorter lead times and higher productivity. It can lessen the feeling of always “starting and stopping” without abandoning the value of having a regular cadence to work toward.

Parking Lot Chart

“Parking Lot Chart” is used to provide a top-level digested summary of project status (not to be confused with a “Parking Lot List,” a tool facilitators use to capture unresolved issues). It is first described in Feature Driven Development (FDD) [Palmer02], and is widely used in agile projects today. It is sometimes also called a “Project Dashboard”.

Niko-niko Calendar

The team installs a calendar one one of the room’s walls. The format of the calendar allows each team member to record, at the end of every workday, a graphic evaluation of their mood during that day. This can be either a hand-drawn “emoticon”, or a colored sticker, following a simple color code, for instance: blue for a bad day, red for neutral, yellow for a good day.

Over time, the niko-niko calendar reveals patterns of change in the moods of the team, or of individual members.

Also Known As

The Japanese word “niko” means “smile”; following a common pattern of word doubling in Japanese, “niko-niko” has a meaning closer to “smiley”.

The term “mood board” is also seen. It is an information radiator.

Expected Benefits

The value of this practice lies in making somewhat objective an important element of team performance – motivation or well-being – which is generally seen as entirely subjective and thus impossible to measure and track.

This may be seen as an illustration of the Gilb Measurability Principle: “anything you need to quantify can be measured in some way that is superior to not measuring it at all.”

In other words, a measurement does not have to be perfect or even very precise, as long as your intent is to get a quantitative handle on something that was previously purely qualitative; the important thing is to take that first step toward quantifying.

Common Pitfalls

As with other activities, such as retrospectives, where team members are asked to report subjective feelings, self-censorship is always a risk. This could be the case, for instance, if team members who report poor days are blamed for “whining”, by management or by team mates.

Origins
  • 2001: among the visualizations described in Norm Kerth’s “Project Retrospectives”, the “Energy Seismograph” can perhaps be seen as a forerunner of the niko-niko calendar
  • 2006: niko-niko calendars are first described by Akinori Sakata in this Web article