I am always looking for a way to effectively describe our business strategies, and from time to time I have come across different presentations that resemble the operational premise we are built on.  Scrum is an approach to building that closely resembles what we have been doing instinctively at the Advantage Co for the past thirty six years.

Below is an attempt to present Scrum as thoroughly as possible.  Keep in mind that I did not write most of the text below, it is simply cobbled together from various reference works [especially Wikipedia, Tobias Mayer, Margaret Rouse, ScrumMethodology.com and Scrum.org].

---

Scrum began its life as one of the new Agile approaches to building software.  These days it is considered an approach that can be used to improve the world of work in a more general sense, and indeed, to change the way individuals think and interact with one another in work situations.  The full potential of Scrum has yet to be explored.

The term Scrum comes from a paper entitled The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka.  In rugby, a scrum is a way of restarting the game, either after an accidental infringement or when the ball has gone out of play.  The practice of Scrum in the software world includes regular short daily meetings where the team members all get together to communicate progress.  Because of the similarity of pausing play (work), and having the players (team members) group together this meeting is commonly known as the Daily Scrum.  Jeff Sutherland, John Scumniotales and Jeff McKenna are credited with introducing the term Scrum into the world of software development in 1993 whilst working at Easel Corporation, a Massachusetts software tools company.  Ken Schwaber wrote the original Scrum white paper, SCRUM Development Process which was presented at the OOPSLA conference in 1995.

In a nutshell, Scrum is a simple approach to the management of complex problems, providing a framework to support innovation and allow self-organizing teams to deliver high quality results in short time-frames.

Scrum is a state of mind; it is a way of thinking that unleashes the creative spirit while remaining firmly grounded in some solid and long-respected theoretical principles, including empiricism, emergence, and self-organization.

Empiricism refers to the continuous inspect/adapt process that allows both workers and managers to make decisions in real time, based on actual data, and as a result respond quickly to ever-changing conditions in the surrounding environment, most importantly the marketplace in which the software is sold or distributed.

Emergence results from an empirical approach.  It implies that all solutions to all problems will become clear as we work.  They will not become clear if we simply talk about them.  When we allow solutions to emerge it is always the simplest and the most appropriate solution for the current context that rises to the surface.  Emergence coupled with Empiricism will lead us to the most appropriate and the most flexible (i.e. changeable) solution.

Self-organization refers to the structure of the teams creating the product of work.  Small multidisciplinary teams are empowered to make the important decisions necessary to i) create high quality product and ii) manage their own processes.  The thinking here is that those doing the work know best how to do the work.  These teams work in a highly interactive and generative way, emerging the product through continuous dialog, exploration and iteration.  Self-organization works when there are clear goals and clear boundaries.

In addition to these principles, Scrum relies on two core mechanisms: prioritization and timeboxing.

Prioritization simply means that some things are more important than others.  This is obvious, yet quickly forgotten when the “we need it all now” mindset is entered.  Scrum helps put the focus back on selecting the most important things to do first — and then actually doing them!  Making time to prioritize, and being rigorous about it are essential to the success of Scrum.

Timeboxing is a simple mechanism for handling complexity [often referred to as a sprint].  We can’t figure out the whole system at this time, so let’s take one small problem and in a short space of time, say one week or one month, figure out how to solve that problem.  The results of that will then guide us towards a solution for the next, bigger problem and give us insight into the needs of the system as a whole.

Scrum employs real-time decision-making processes based on actual events and information.  This requires well-trained and specialized teams capable of self-management, communication and decision-making.  The teams in the organization work together while constantly focusing on their common interests.

How does Scrum Work?
Building complex products or programs for customers is an inherently difficult task.  Scrum provides structure to allow teams to deal with that difficulty.  However, the fundamental process is incredibly simple, and at its core is governed by 3 primary roles.

1. Product Owners determine what needs to be built in the next 30 days or less.  The Product Owner is the main voice of the customer, establishing a compelling vision and using a process of continuous prioritization to get there.
2. Development Teams build what is needed in 30 days (or less), and then demonstrate what they have built.  Based on this demonstration, the Product Owner determines what to build next.  The Development Team is a self-organized, cross-functional, empowered group who do the work.  Every workday the team members meet around a visual metrics board (e.g. task board) to align with one-another and request and offer support.  At the end of each sprint the completed work is reviewed by stakeholders and consumers, and adaptations suggested.  Following the review the team members reflect on their process, seeking ways to improve and making commitments to change.  Every Sprint produces an improved product or service and a better, happier team.
3. Scrum Masters ensure this process happens as smoothly as possible, and continually help improve the process, the team and the product being created.  The Scrum Master is a servant leader to the team and a change agent within the wider organization.

Scrum requires a prioritized set of goals, a commitment for every sprint, and a simple way of measuring progress.  A clear distinction is kept between the “What” (the goal) and the “How” (the pathway).  Scrum requires clear focus, commitment, and complete transparency at all levels.  Scrum embraces certain human-centric values including trust, integrity, courage and respect.  While this is an incredibly simplified view of how Scrum works, it captures the essence of this highly productive approach for team collaboration and product development.

Scrum involves:

1. Initial appointment of a project manager called the “Scrum Master.”
2. Definition and prioritization of tasks to be done.
3. Planning sessions for each task.
4. Daily meetings among teams.
5. Identification and evaluation of potential project risks and process pitfalls.
6. Execution of projects in brief, high-intensity, frequent work sessions.
7. Reviews of progress and evaluations of completed projects.
8. Openness to constructive criticism and ideas for improvement.

Sprint
In the Scrum method of agile software development, work is confined to a regular, repeatable work cycle, known as a sprint or iteration.  In by-the-book Scrum, a sprint is 30 days long, but many teams prefer shorter sprints, such as one-week, two-week, or three-week sprints.  But how long each sprint lasts is something for the team to decide, who must weigh the advantages or disadvantages of a longer or shorter sprint for their specific development environment.  The important thing is that a sprint is a consistent duration.

During each sprint, a team creates a shippable product, no matter how basic that product is.  Working within the boundaries of such an accelerated timeframe, the team would only be able to build the most essential functionality.  However, placing an emphasis on a working product motivates the Product Owner to prioritize a product release’s most essential features, encourages developers to focus on short-term goals, and gives customers a tangible, empirically based view of progress.  Because a release requires many sprints for satisfactory completion, each iteration of work builds on the previous.  This is why Scrum is described as “iterative” and “incremental.”

---

The Agile Manifesto
Scrum is one of the so-called lightweight agile software development methods which evolved in the mid-1990s as a reaction against the heavyweight waterfall-oriented methods, which were characterized by their critics as being heavily regulated, regimented, micromanaged, and overly incremental approaches to development.

Proponents of lightweight agile methods such as Scrum contend that they are returning to development practices that were present early in the history of software development.

In February 2001, 17 software developers met at the Snowbird, Utah resort, to discuss lightweight development methods.  They published the Manifesto for Agile Software Development to define the approach now known as agile software development.  Some of the manifesto’s authors formed the Agile Alliance, a non-profit organization that promotes software development according to the manifesto’s values and principles.

The Agile Manifesto is based on twelve principles:

1. Customer satisfaction by rapid delivery of useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Self-organizing teams
12. Regular adaptation to changing circumstances

Later, Ken Schwaber with others founded the Scrum Alliance and created the Certified Scrum Master programs and its derivatives.  Schwaber left the Scrum Alliance in the fall of 2009, and founded Scrum.org.  There are, however, many specific agile development methods.  Most promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.

Most agile methods break tasks into small increments with minimal planning and do not directly involve long-term planning.  Iterations are short time frames (time boxes) that typically last from one to four weeks.  Each iteration involves a cross-functional team working in all functions: planning, requirements analysis, design, coding, unit testing, and acceptance testing.  At the end of the iteration a working product is demonstrated to stakeholders.  This minimizes overall risk and allows the project to adapt to changes quickly.  An iteration might not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.  Multiple iterations might be required to release a product or new features.

No matter what development disciplines are required, each agile team will contain a customer representative, e.g. Product Owner in Scrum. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration questions.  At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment (ROI) and ensuring alignment with customer needs and company goals.

In agile software development, an information radiator is a (normally large) physical display located prominently in an office, where passers-by can see it.  It presents an up-to-date summary of the status of a software project or other product.

A common characteristic of agile development are daily status meetings or “stand-ups”, e.g. Daily Scrum (Meeting).  In a brief session, team members report to each other what they did the previous day, what they intend to do today, and what their roadblocks are.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called “requirements churn”), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner.  As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.

---

Product Owner
The Scrum product owner is typically a project’s key stakeholder.  Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team. This is key to successfully starting any agile software development project. The agile product owner does this in part through the product backlog, which is a prioritized features list for the product.

The product owner is commonly a lead user of the system or someone from marketing, product management or anyone with a solid understanding of users, the market place, the competition and of future trends for the domain or type of system being developed.

This, of course, varies tremendously based on whether the team is developing commercial software, software for internal use, hardware or some other type of product. The key is that the person in the product owner role needs to have a vision for what is to be built.

Although the agile PO prioritizes the product backlog during the sprint planning meeting, the team selects the amount of work they believe they can do during each sprint, and how many sprints will be required.

Communication is a main function of the product owner. The ability to convey priorities and empathize with team members and stakeholders are vital to steer the project in the right direction. Product owners bridge the communication gap between the team and their stakeholders. As Figure 1 shows, they serve as a proxy stakeholder to the development team and as a project team representative to the overall stakeholder community.

As the face of the team to the stakeholders, the following are some of the communication tasks of the product owner to the team:

1. demonstrates the solution to key stakeholders who were not present in a normal iteration demo
2. announces releases
3. communicates team status
4. organizes milestone reviews
5. educates stakeholders in the development process
6. negotiates priorities, scope, funding, and schedule

Empathy is a key attribute for a product owner to have – the ability to put one’s self in another’s shoes.  A product owner will be conversing with different stakeholders in the project – different people, with a variety of backgrounds, job roles, and objectives.  A product owner needs to be able to see from these different points of view.  To be effective, it would also be wise for a product owner to know the level of detail his audience needs from him.  The development team would need thorough feedback and specifications so they build a product up to expectation, while an executive sponsor may just need summaries of progress.  Providing more information than necessary may lose their interest and waste time.  There is also significant evidence that face-to-face communication around a shared sketching environment is the most effective way to communicate information instead of documentation.  A direct means of communication is then most preferred by seasoned agile product owners.

A product owner’s ability to communicate effectively is also enhanced by being skilled in techniques that identify stakeholder needs, negotiate priorities between stakeholder interests, and collaborate with developers to ensure effective implementation of requirements.

Development Team
The Development Team is responsible for delivering potentially shippable increments (PSIs) of product at the end of each Sprint (the Sprint Goal).  A Team is made up of 3–9 individuals with cross-functional skills who do the actual work (analyze, design, develop, test, technical communication, document, etc.).  The Development Team in Scrum is self-organizing, even though there may be some level of interface with project management offices (PMOs).

Scrum Master
Scrum is facilitated by a Scrum Master, who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables.  The Scrum Master is not a traditional team lead or project manager, but acts as a buffer between the team and any distracting influences.  The Scrum Master ensures that the Scrum process is used as intended . The Scrum Master is the enforcer of the rules of Scrum, often chairs key meetings, and challenges the team to improve.  The role has also been referred to as a servant-leader to reinforce these dual perspectives.

The Scrum Master differs from a project manager in that the latter may have people management responsibilities unrelated to the role of Scrum Master.  The Scrum Master role excludes any such additional people responsibilities.  In fact, there is no role of project manager in Scrum at all, because none is needed.  The traditional responsibilities of a project manager have been divided up and reassigned among the three Scrum roles, and mostly to the Development Team and the Product Owner, rather than to the Scrum Master.  Practicing Scrum with the addition of a project manager indicates a fundamental misunderstanding of Scrum, and typically results in conflicting responsibilities, unclear authority, and sub-optimal results.

The Scrum Process

Sprint
A sprint (or iteration) is the basic unit of development in Scrum.  The sprint is a “timeboxed” effort; that is, it is restricted to a specific duration.  The duration is fixed in advance for each sprint and is normally between one week and one month, although two weeks is typical.

Each sprint is started by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and ended by a sprint review-and-retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.

Scrum emphasizes working product at the end of the Sprint that is really “done”; in the case of software, this means a system that is integrated, fully tested, end-user documented, and potentially shippable.

Sprint planning meeting
At the beginning of the sprint cycle (every 7–30 days), a “Sprint planning meeting” is held:

1. Select what work is to be done
2. Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team
3. Identify and communicate how much of the work is likely to be done during the current sprint
4. Eight-hour time limit [10]
   1. (1st four hours) Entire team: dialog for prioritizing the Product Backlog
   2. (2nd four hours) Development Team: hashing out a plan for the Sprint, resulting in the Sprint Backlog

Daily Scrum meeting
Each day during the sprint, a project team communication meeting occurs.  This is called a Daily Scrum (meeting) and has specific guidelines:

1. All members of the development team come prepared with the updates for the meeting.
2. The meeting starts precisely on time even if some development team members are missing.
3. The meeting should happen at the same location and same time every day.
4. The meeting length is set (timeboxed) to 15 minutes.
5. All are welcome, but normally only the core roles speak.

During the meeting, each team member answers three questions:

1. What have you done since yesterday?
2. What are you planning to do today?
3. Any impediments/stumbling blocks? Any impediment/stumbling block identified in this meeting is documented by the Scrum Master and worked towards resolution outside of this meeting. No detailed discussions shall happen in this meeting.

End meetings (Sprint Review and Sprint Retrospective)
At the end of a sprint cycle, two meetings are held: the “Sprint Review Meeting” and the “Sprint Retrospective”.

At the Sprint Review Meeting:

1. Review the work that was completed and the planned work that was not completed
2. Present the completed work to the stakeholders (a.k.a. “the demo”)
3. Incomplete work cannot be demonstrated
4. Four-hour time limit

At the Sprint Retrospective:

1. All team members reflect on the past sprint
2. Make continuous process improvements
3. Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
4. Three-hour time limit
5. This meeting is facilitated by the Scrum Master

Extensions

Backlog refinement (grooming)
Backlog refinement is the ongoing process of reviewing product backlog items and checking that they are appropriately prioritized and prepared in a way that makes them clear and executable for teams once they enter sprints via the sprint planning activity.  Product backlog items may be broken into multiple smaller ones, acceptance criteria may be clarified, or new preparatory work such as clarification on client needs or technical spikes may be identified.

Backlog refinement is not a core Scrum practice but has been adopted as a way of managing the quality of backlog items entering a sprint.

Scrum of Scrums
The Scrum of Scrums (meeting) is a technique to scale Scrum up to large development groups (over a dozen people), which allows clusters of teams to discuss their work, focusing especially on areas of overlap and integration.  Each daily scrum within a sub-team ends by designating one member as an “ambassador” to participate in a daily meeting with ambassadors from other teams, called the Scrum of Scrums.  Depending on the context, ambassadors may be technical contributors, or each team’s Scrum Master.

The agenda will be like a Daily Scrum, with the following four questions:[citation needed]

1. What has your team done since we last met?
2. What will your team do before we meet again?
3. Is anything slowing your team down or getting in their way?
4. Are you about to put something in another team’s way?

Resolution of impediments is expected to focus on the challenges of coordination between the teams, and may entail agreeing to interfaces between teams, negotiating responsibility boundaries, etc. The Scrum of Scrums will track these working items via a backlog of its own, where each item contributes to improving between-team coordination.

Product backlog
The product backlog is an ordered list of requirements that is maintained for a product.  It consists of features, bug fixes, non-functional requirements, etc.—whatever needs to be done in order to successfully deliver a viable product.  The product backlog items (PBIs) are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc.

Items added to a backlog are commonly written in story format.  The product backlog is what will be delivered, ordered into the sequence in which it should be delivered.  It is open and editable by anyone, but the Product Owner is ultimately responsible for ordering the items on the backlog for the Development Team to choose.

The product backlog contains the Product Owner’s assessment of business value and the Development Team’s assessment of development effort, which are often, but not always, stated in story points using a rounded Fibonacci sequence.  These estimates help the Product Owner to gauge the timeline and may influence ordering of backlog items; for example, if the “add spellcheck” and “add table support” features have the same business value, the Product Owner may schedule earlier delivery of the one with the lower development effort (because the ROI (Return on Investment) is higher) or the one with higher development effort (because it is more complex or riskier, and they want to retire that risk earlier).

The product backlog and the business value of each backlog item is the responsibility of the Product Owner.  The size (i.e. estimated complexity or effort) of each backlog item is, however, determined by the Development Team, who contributes by sizing items, either in story points or in estimated hours.

There is a common misunderstanding that only user stories are allowed in a Product Backlog.  By contrast, Scrum is neutral on requirement techniques.  As the Scrum Primer states,

• Product Backlog items are articulated in any way that is clear and sustainable. Contrary to popular misunderstanding, the Product Backlog does not contain “user stories”; it simply contains items. Those items can be expressed as user stories, use cases, or any other requirements approach that the group finds useful. But whatever the approach, most items should focus on delivering value to customers.

Scrum advocates that the role of Product Owner be assigned.  The Product Owner is responsible for maximizing the value of the product and the work of the Development Team.  The Product Owner gathers input, takes feedback and is lobbied by many people, but it will ultimately make the call on what gets built. They are also solely responsible for the management of the backlog.

The product backlog is used to:

1. Capture requests for modifying a product.  This can include adding new features, replacing old features, removing features and fixing issues
2. Ensure the delivery team is given work which maximizes the business benefit to the owner of the product

Typically, the product owner and the SCRUM team come together and write down everything that needs to be prioritized and this becomes content for the first sprint, which is a block of time meant for focused work on selected items that can be accommodated within a timeframe.  The SCRUM product backlog is permitted to evolve as new information surfaces about the product and its customers, and so new work are tackled for next sprints.

Managing the product backlog between product owner and scrum team
A backlog, in its simplest form, is merely a list of items to be worked on.  Having well established rules about how work is added, removed and ordered helps the whole team make better decisions about how to change the product.

The product owner prioritizes which of the product backlog are most needed.  The team then chooses which items can be completed in the coming sprint.  On the SCRUM board, the team moves items from the product backlog to the sprint backlog, which is the list of items they will build.  Conceptually, it is ideal for the team to only select what they think they can accomplish from the top of the list, but it is not unusual to see in practice that teams are able to take lower priority items from the list along with the top ones selected.  This normally happens because there is time left within the sprint to accommodate more work.  Items at the top of the backlog, the items that are going to be worked on first, should be broken down into stories that are suitable for the delivery team to work on.  The further down the backlog goes, the less refined the items should be.  As Schwaber and Beedle put it “The lower the priority, the less detail, until you can barely make out the backlog item.”

As the team works through the backlog, it needs to be assumed that “changes in the world can happen”—the team can learn about new market opportunities to take advantage of, competitor threats that arise, and feedback from customers that can change the way the product was meant to work.  All of these new ideas tend to trigger the team to adapt the backlog to incorporate new knowledge.  This is part of the fundamental mindset of an agile team.  The world changes, the backlog is never finished.

A Scrum task board

Sprint backlog
The sprint backlog is the list of work the Development Team must address during the next sprint.  The list is derived by selecting product backlog items from the top of the product backlog until the Development Team feels it has enough work to fill the sprint.  This is done by the Development Team asking “Can we also do this?” and adding product backlog items to the sprint backlog.  The Development Team should keep in mind its past performance assessing its capacity for the new sprint, and use this as a guide line of how much “effort” they can complete.

The product backlog items are broken down into tasks by the Development Team.  Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed according to the set priority and the Development Team member skills.  This promotes self-organization of the Development Team, and developer buy-in.

The sprint backlog is the property of the Development Team, and all included estimates are provided by the Development Team.  Often an accompanying task board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.

Once a Sprint Backlog is committed, no additional functionality can be added to the Sprint backlog except by the team.  Once a Sprint has been delivered, the Product Backlog is analyzed and reprioritized if necessary, and the next set of functionality is selected for the next Sprint.

Product Increment
The increment (or potentially shippable increment, PSI) is the sum of all the Product Backlog items completed during a sprint and all previous sprints.  At the end of a sprint, the Increment must be done according to the Scrum Team’s criteria called Definition of Done (DoD).  The increment must be in a usable condition regardless of whether the Product Owner decides to actually release it.

Burndown chart
A sample burn down chart for a completed iteration, showing remaining effort and tasks for each of the 21 work days of the 1-month iteration.

The sprint burndown chart is a publicly displayed chart showing remaining work in the sprint backlog.  Updated every day, it gives a simple view of the sprint progress.  It also provides quick visualizations for reference.

Whiteboarding
To illustrate each stage of work, teams working in the same space often use post-it notes or a large whiteboard.  In the case of decentralized teams, stage-illustration software such as Assembla, TargetProcess, JIRA or Agilo for Scrum.

In their simplest, the tasks are categorized into the work stages:

1. Unstarted
2. Ongoing
3. Completed

If desired, though, the teams can add more stages of work (such as “defined”, “designed”, “tested” or “delivered”).  These additional phases can be of assistance if a certain part of the work becomes a bottleneck and the limiting values of the unfinished work cannot be raised.  A more specific task division also makes it possible for employees to specialize in a certain phase of work.

There are no set limiting values for unfinished work.  Instead, each team has to define them individually by trial and error; a value too small results in workers standing idle for lack of work, whereas values too high tend to accumulate large amounts of unfinished work, which in turn hinders completion times.  A rule of thumb worth bearing in mind is that no team member should have more than two simultaneous selected tasks, and that on the other hand not all team members should have two tasks simultaneously.

The major differences between Scrum and Kanban are derived from the fact that, in Scrum, work is divided into sprints that last a certain amount of time, whereas in Kanban the workflow is continuous.  This is visible in work stage tables, which in Scrum are emptied after each sprint.  In Kanban all tasks are marked on the same table.  Scrum focuses on teams with multifaceted know-how, whereas Kanban makes specialized, functional teams possible.

Tooling
Like other agile methods, Scrum can be implemented through a wide range of tools.  Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the sprint backlog.  There are also open-source and proprietary packages dedicated to management of products under the Scrum process.  Other organizations implement Scrum without the use of any tools, and maintain their artifacts in hard-copy forms such as paper, whiteboards, and sticky notes.

---

Limitations
Hybridization of Scrum is common as Scrum does not cover the whole product development lifecycle; therefore, organizations find the need to add in additional processes to create a more comprehensive implementation.  For example, at the start of the project, organizations commonly add process guidance on requirements gathering and prioritization, initial high-level design, and budget and schedule forecasting.  However, the Scrum framework does not explicitly allow for extension points of such a kind; consequently, achieving a more comprehensive software life cycle requires extending the framework rather than instantiating it.

1. Agile Practices
   Agile development is supported by a bundle of concrete practices suggested by the agile methods, covering areas like requirements, design, modeling, coding, testing, project management, process, quality, etc.
2. Common Agile Pitfalls
   Teams implementing Agile often face difficulties transitioning from more traditional methods such as Waterfall development.  Below are problems often faced by teams implementing Agile processes:
3. Adding stories to a sprint in progress
   Adding stories to a sprint in progress is detrimental to the flow established by Agile.  From Ilan Goldstein’s Sprint issues – when sprints turn into crawls, “‘Isn’t the ability to change course on the fly what Scrum is all about?’  Well not quite.  Scrum certainly provides provision to change product backlog priorities mid-project however this needs to occur between sprints and not during them.”
4. If there is an issue which arises which requires additions to a sprint, Ilan’s recommendation is to perform an abnormal sprint termination.  This does not mean that a user story cannot expand.  Teams must deal with new information which may result in additional tasks for a user story.  If the new information prevents the user story from being production ready during the sprint, then it should be carried over into the following sprint.  However, during the next sprint planning, the user story should be prioritized in comparison to all remaining user stories.  The information found requiring new tasks may have altered the priority of the user story.
5. Product Owner Role is not properly filled
   The Product owner is responsible for representing the business in the development activity.  In The Elements of Scrum the Product owner “… is usually the most demanding role on a scrum team.”
6. A common mistake is to have the product owner role filled by someone from the development team.  According to Johanna Rothman this is a mistake, “When the business is unaccountable, the agile ecosystem breaks down.”  Having the development team fill this role results in the team making its own decisions on prioritization without real feedback from the business.  Additionally, business issues are either attempted to be solved internally or there are delays as the team must reach outside the core group for input. These issues can result in finger pointing and divert from the collaborative process directed by Agile.
7. Teams not focused
   The Agile Process requires teams who are focused on the project to meet the project’s commitments.  It is expected during a sprint, for a resource who has the capacity, to take-up a task potentially outside of their subject area.  If team members have multiple projects it will be difficult for any spare capacity to be available to help complete the sprint.  “While having information developers working on multiple scrum teams is not ideal, it can be done with some proper planning and judicious evaluation of which meetings you should attend.”
8. Excessive Preparation/Planning
   Teams may fall into the trap of spending too much time preparing or planning.  This is a common trap for teams less familiar with the Agile process where the teams feel obligated to have a complete understanding of all user stories or a detailed design.  Teams should leverage the ability for Sprints to act as a method discovery and moving forward with the information they do know.  As more information is gained it should be applied to the next Sprint.
9. Problem-Solving in the Daily Scrum
   The Daily Scrum is meant to be a focused, timely meeting with all team members to disseminate information.  If problem-solving occurs it often can only involve certain team members and potentially is not the best use of the entire team’s time.  If during the Scrum the team starts diving into problem-solving, it should be tabled until a sub-team can discuss immediately after the Daily Scrum completes.
10. Assigning Tasks
    One of the benefits of Agile is it empowers the team to make choices as they are the closest to the problem.  Additionally, choices are to be made as close to implementation as possible compared to a traditional waterfall approach allowing more timely information to be used in the decision. If team members are assigned tasks by others or too early in the process then the benefits of localized and timely decision making can be lost.
11. Another tendency is for assignors to box team members into certain roles.  Team members themselves can choose to take on tasks which stretch their abilities and provide cross-training opportunities.
12. ScrumMaster as a contributor
    Another common pitfall is for the ScrumMaster to act as a contributor.  While not prohibited by the Agile Methodology, the ScrumMaster needs to ensure they have the capacity to act in the role of ScrumMaster first and not working on tasks for the project.  A ScrumMaster’s role is to facilitate the Scrum process.  “Facilitating meetings such as a daily scrum, sprint planning, sprint reviews and sprint retrospectives is part of this.  A technical contributor’s role is to work with the other team members to figure out how to get the work done and to do it.”
13. Having the ScrumMaster also multitasking may result in too many context switches to be productive.  Additionally, as a ScrumMaster is to remove roadblocks for the team, the benefit gained by individual tasks moving forward may not outweigh any roadblocks which are deferred due to lack of capacity.
14. Attempting to take on too much in a sprint
    A common misconception is Agile allows continuous change, however a Sprint backlog is an agreement of what work can be completed during the Sprint.  Additionally having too much Work-In-Progress(WIP) can result in inefficiencies due “to avoid the penalties of wasted time, effort and resources.”
15. A possible issue is the team being pressured into taking on additional work.  “An important point to reiterate here is that it’s the team that selects how much work they can do in the coming sprint.  The product owner does not get to say, ‘We have four sprints left so you need to do one-fourth of everything I need.’  We can hope the team does that much (or more), but it’s up to the team to determine how much they can do in the sprint.”
16. Fixed time, resources, scope and quality
    Agile fixes time (Sprint duration) and resources while the scope and quality remain variable.  The customer or product owner often pushes for a fixed scope for a Sprint.  However, teams should be reluctant to commit to locked time, resources and scope (commonly known as the project management triangle).  Efforts which attempt to add scope to the fixed time and resources of Agile may result in decreased quality.
17. Applications Outside of Software Development
    Agile methods have been extensively used for development of software products and some of them use certain characteristics of software, such as object technologies.  However, these techniques can be applied to the development of non-software products, such as computers, motor vehicles, medical devices, food, clothing, and music.

---

Organizational Change

With Scrum, the management hierarchies of organizations tend to get leveled and development teams have a more immediate and direct contact with customers.  The work environment becomes less command-and-control and more collaborative.  Regular, open dialog is encouraged over extensive documentation, and negotiated agreement is preferred to formal and impersonal contracts of work.

The qualities of openness, honesty and courage are fostered at all levels, and individual gain becomes secondary to collective advancement. A Scrum environment is a supportive one, where people at all levels show respect and trust for one another. Decisions are made by consensus, rather than imposed from above and all knowledge is shared in a fearless and transparent way.

Scrum goes against the grain for most companies in the software industry, where a phased approach coupled with a high degree of micro-management, and an insistence on defined processes and extensive documentation have been the norm for over thirty years.  Many companies rely on fear and money as the key motivators for their workers.  This approach has shown short-term success but more and more companies are beginning to understand that it is not a good long term strategy.  Nevertheless, the concept of changing to something as radical as Scrum strikes terror into many executive and middle-management hearts.

Scrum is still at the early-adopter stage.  It will take many years for the majority of companies to recognize the benefits of creating more trustful and compassionate workplaces.  Without such change many software companies will likely sink under the sheer weight of their heavy processes, and overstaffed workforces.  Others – those who dare to embrace the lean, lightweight, agile approach of Scrum – stand a greater chance of surviving and prospering.  For those who turn to Scrum, and fully embrace it, a reversion back to the old way of working becomes unthinkable.  A paradigm shift is occurring in the workplace, and Scrum is an important part of that shift.

Agile development paradigms can be used in other areas of life such as raising children.  Its success in child development might be founded on some basic management principles; communication, adaptation and awareness.  Bruce Feiler has shown that the basic Agile Development paradigms can be applied to household management and raising children.  In his TED Talk, “Agile programming — for your family,” these paradigms brought significant changes to his household environment, such as the kids doing dishes, taking out the trash, and decreasing his children’s emotional outbreaks which inadvertently increased their emotional stability.  In some ways, agile development is more than a bunch of software development rules; but it can be something more simple and broad, like a problem solving guide.

---

Terminology
The following terms are often used in a Scrum process.

Scrum Team  Product Owner, Scrum Master and Development Team
Product Owner  The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders, and ensuring the value of the work the Development Team does.
Scrum Master  The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits.
Development Team  A cross-functional group of people responsible for delivering potentially shippable increments of Product at the end of every Sprint.
Sprint burn down chart  Daily progress for a Sprint over the sprint’s length.
Release burn down chart  Sprint level progress of completed product backlog items in the Product Backlog.
Product backlog (PBL)  A prioritized list of high-level requirements.
Sprint backlog (SBL)  A prioritized list of tasks to be completed during the sprint.
Sprint  A time period (typically 1–4 weeks) in which development occurs on a set of backlog items that the team has committed to. Also commonly referred to as a Time-box or iteration.
Spike  A time boxed period used to research a concept and/or create a simple prototype.  Spikes can either be planned to take place in between sprints or, for larger teams, a spike might be accepted as one of many sprint delivery objectives.  Spikes are often introduced before the delivery of large or complex product backlog items in order to secure budget, expand knowledge, and/or produce a proof of concept.  The duration and objective(s) of a spike will be agreed between the Product Owner and Delivery Team before the start.  Unlike sprint commitments, spikes may or may not deliver tangible, shippable, valuable functionality.  For example, the objective of a spike might be to successfully reach a decision on a course of action. The spike is over when the time is up, not necessarily when the objective has been delivered.
Tracer Bullet  The tracer bullet is a spike with the current architecture, current technology set, current set of best practices which results in production quality code.  It might just be a very narrow implementation of the functionality but is not throw away code.  It is of production quality and the rest of the iterations can build on this code.  The name has military origins as ammunition that makes the path of the weapon visible, allowing for corrections.  Often these implementations are a ‘quick shot’ through all layers of an application, such as connecting a single form’s input field to the back-end, to prove the layers will connect as expected.
Tasks  Work items added to the sprint backlog at the beginning of a sprint and broken down into hours Each task should not exceed 12 hours (or two days), but it’s common for teams to insist that a task take no more than a day to finish.
Definition of Done (DoD)  The exit-criteria to determine whether a product backlog item is complete.  In many cases the DoD requires that all regression tests should be successful.  The definition of “done” may vary from one Scrum team to another, but must be consistent within one team.
Velocity  The total effort a team is capable of in a sprint.  The number is derived by evaluating the work (typically in user story points) completed from the last sprint’s backlog items.  The collection of historical velocity data is a guideline for assisting the team in understanding how much work they can do in a future sprint.
Impediment  Anything that prevents a team member from performing work as efficiently as possible.
Sashimi  A term used to describe one or more user stories, indicating that they are thin slices of a product feature or capability.
Abnormal Termination  The Product Owner can cancel a Sprint if necessary.  The Product Owner may do so with input from the team, Scrum Master or management.  For instance, management may wish to cancel a sprint if external circumstances negate the value of the sprint goal.  If a sprint is abnormally terminated, the next step is to conduct a new Sprint planning meeting, where the reason for the termination is reviewed.
ScrumBut  A ScrumBut (or Scrum But) is an exception to the “pure” Scrum methodology, where a team has changed the methodology to adapt it to their own needs.
Scrum-ban  Scrum-ban is a software production model based on Scrum and Kanban.  Scrum-ban is especially suited for maintenance projects or (system) projects with frequent and unexpected work items or programming errors.  In such cases the time-limited sprints of the Scrum model are of no appreciable use, but Scrum’s daily meetings and other practices can be applied, depending on the team and the situation at hand.  Visualization of the work stages and limitations for simultaneous unfinished work and defects are familiar from the Kanban model.  Using these methods, the team’s workflow is directed in a way that allows for minimum completion time for each work item or programming error, and on the other hand ensures each team member is constantly employed.

---