What is Scrum?

Scrum is a simple framework for getting work done. Much of the framework assumes you are getting work done with a small stable dedicated team (from 5-9 people). Usually the work is new product development.  Often that work is specifically software development.

The framework of Scrum defines 3 roles: Product Owner, ScrumMaster and the Team role (or Implementer role). 

* The Product Owner owns the Product Backlog and manages the flow of business information into the Team. 
* The ScrumMaster is the impediment-remover-in-chief. 
* The Team (implementor) role represents the implementers, the people who do the "real work."

All 3 roles together form the full Scrum team, aka, the committed 'pigs.'  Scrum assumes there are also 'chickens' (those supporting the project but not committed in the same way).

The framework defines several key meetings.  To over-simplify, they are as follows.

* The Sprint Planning Meeting is where the Scrum Team plans the sprint.  A Sprint is a 1 to 4 week timebox, at the end of which the Scrum Team should have produced working product.
* Each work day the Team has a Daily Scrum, where they sync up about the work remaining to do in the Sprint. 
* At the end of the Sprint, there is a Sprint Review (Demo), where the customers or business stakeholders look at the working product and give feedback (both positive and negative is expected). 
* And finally the Scrum Team meets for a Retrospective, to see how they can work more productively and to remove one good-sized impediment.  All of these meetings are timeboxed.

The simple framework of Scrum does not define what happens before Sprinting (doing Sprints), except to imply that a Vision and a Product Backlog have somehow 'appeared.'  Virtually all Scrum Teams do Release Planning before doing any Sprints, and do Release Plan Refactoring every Sprint.  In Release Planning the Team and others create a Release Plan (probably not too confusing to call it a subset of the Product Backlog). 

The Scrum Team uses many artifacts.  To over-simplify, the main ones are the following. 

* The Product Backlog holds a list of the PBIs (product backlog items) or features to be built.  Often the PBIs are in the form of User Stories ("As a role X, I want to do Y, so that Z.") . 
* In Sprint Planning, the Team creates a Sprint Backlog (essentially a plan for the Sprint.).  This includes the PBIs that the Team has committed to, as well as the Tasks that the Team currently expects to use to get all the PBIs done.
* Most Scrum Teams track work remaining in a Sprint Burndown Chart -- at the Sprint level.  And in a Release Burndown Chart -- at the Release level (very typically a Release takes 2-20 Sprints to complete). 
* The team produces Working Product at the end of each Sprint.  Ken Schwaber's phrase for this is a mouthful: "potentially shippable product increment."  The Working Product is also said to be 'done, done' (rather than 'done, done, done').  The Working Product (eg, new items built in the Sprint) is presented in the Demo in the Sprint Review meeting, which enables far better feedback than using documentation. 
* Finally, the Scrum Team has a public Impediments List.  The ScrumMaster 'owns' and works the Impediment List in much the same way as a Product Owner 'owns' and works the Product Backlog.  

For further information about Scrum, we next recommend the Scrum Guide and The New New Product Development Game article by Takeuchi and Nonaka.

What is Agile?

Agile is perhaps best described as a movement, usually associated with software development, but really, far broader.  In general, people want to be 'more agile', meaning usually more adaptive and responsive to the quick changes in the business world.  We might say: faster in helping the customers.

In the software development community, 17 men defined the Agile Manifesto in 2001.  The Agile Manifesto is a good summary of the basic ideas around agile. At the same time, they also defined 12 Agile Principles. With a few minor changes (substituting 'product' for 'software' and similar), the Manifesto and the Principles are a good summary of what is under the agile umbrella. 

In our opinion, Agile is very similar to Lean, especially Lean product development.

In Agile, the two best known sub-groups are Extreme Programming (the first big thing, aka "XP") and Scrum.  Again, we think that Scrum is just as applicable outside software developement and as inside it.  But Scrum is often thought of as "one of the agile software development methodologies".

How do I begin the Agile Transformation?

Some people ask, how do we start the Agile transformation?

Let us be honest. For most firms, it is a transformation. Meaning: big, important and hard. And it is worth it, but it takes time and energy. A 2-day CSM course is a good start, but only a start.

If your group is 50 people or 500,000 people, we recommend starting with one team.  This is a near universal pattern.

Specifically, one team starts using or doing Scrum.  There are many ways to start them, and most have worked at one time or another.

In our experience, the best way to start them is for all of the Team (about 5-7 dedicated people) to take the CSM course, with a 2-day workshop covering Release Planning, where they plan the project to start the next 'Monday.'  It is also helpful to have an Agile Coach for them, full-time for some period after they start (2 months is a common pattern).  It is not required to do it this way, but it does lead to the most success most often. We find.

After 2-4 sprints, the team will notice an improvement.  If they are doing Scrum well, it will start to be a meaningful improvement.  Success builds success.  Very rarely, a good team attacks a set of work that is impossible or at least too difficult for them. Even in those cases, Scrum helps by identifying the problem much sooner.

Normally, the team notices fairly quickly an improvement of 20-100%. We think it is fair to attribute this improvement to Scrum. Of course it also took time and money from the firm to remove impediments, it took imagination from the team to identify the best impediments to fix, it took innovative thinking and hard work to build the product successfully. And many other things. But we think it is fair to say that Scrum was the main driver of success. Usually, before Scrum the Team was not getting better.

The next question is how to expand the Agile-Scrum implementation in the firm.  One question under this is whether to have "top down" or "bottom up".  The best answer is 'yes', or both.

We do want you to ask: Is it better to broaden or to deepen Agile-Scrum?

Suffice to say here that broadening or deepening the Scrum implementation is very valuable work, but also a lot of work, with many facets.

Scrum starts to expose all the impediments in the organization. It is very common for a firm to blame Scrum for revealing those impediments.

You must add something to Scrum to make it work. Specifically, one of the first things to add or improve are typically the XP (Extreme Programming) technical engineering practices.  Or the equivalent for your type of work.

There are many many other issues in the agile journey.  These have been and will be discussed at our blog, Agile & Business. And they are discussed in books, articles and other resources listed on our Resources page.

What are your recommendations?

So, some typical recommendations for getting started.

Establish the idea that we want to try Agile-Scrum.

Do Scrum training for the pilot team (a CSM course). Include a one or two day workshop that covers Release Planning and Sprint Planning.

Hire an experienced Agile Coach to work with the pilot team.

After three months, have the Product Owner and Scrum Master and perhaps some business stakeholders take a Intermediate CSPO course, with a workshop.

The one other key thing is to establish a public impediment list, and work the impediments items, one at a time, in priority order.

....These are key recommendations for a typical situation where you are able to do the right thing from the start. Often life is more complex.

Why Scrum Works:

There are many reasons that Scrum works, although not all of these are obvious. Nor do they all work every time.

There are also many ways of explaining these reasons. Here are some of my favorite ways to explain why:

* The bad news does not get better with age.
* We have to slow down to go faster.
* Timeboxes
* Empirical Process Control
* Self-managing teams
* The PO uses the Pareto Rule (80-20)
* Complex Adaptive Systems
* Adaptive Planning (eg, as one concrete thing: release plan refactoring)

Why Agile Works:

Agile is all about delivering more business value in a given time period (time box). Agile is a way of getting a lot more business value out of your investment in products or projects.  Agile is both wonderfully simple and perplexingly involved (in part because people, who are complex, are involved).

Agile recognizes that software is developed by people in a team (what a wonderfully original but necessary insight) and not developed by a process or by tools.  Nor much by individuals anymore. So, it treats people right, recognizing their greatness and their weaknesses.  It recognizes that creativity and learning will make the project successful.  And these common-sense insights are keys to its sucess.

Does Agile have to be implemented perfectly?  No. It is simple to implement, in a way.  But the value received is generally in proportion to the rigor and effort in implementing Agile.  For all clients we have worked with, Agile involves some major organizational changes.  Get a coach; get the best coach you can find and afford.

In our opinion, Scrum is the place to start with Agile.  It puts in place a method for the business and technology sides to collaborate.  It provides a way to focus on achieving business value.  It establishes methods to control the work.  It releases a substantial (higher) portion of the team's energy and allows the team to evolve toward better work practices (e.g., better engineering practices) at a pace that makes sense for the team and the project, and makes sense in the context of your organization.

Where does Lean fit in?

Jeff Sutherland and we view Scrum as a simple implementation of Lean for new product development.   We think further lean ideas and practices can be added to Scrum with profit.

We do think that for most firms and situations, Scrum can be digested and implemented quickly.  So, we believe that teams should implement Scrum first, and then add more to it. Always, Scrum is not implemented perfectly in the first few months. It takes years to attain mastery at doing Scrum, even though it is very simple. You know this, of course, from any sport or any artisitic activity. The basics are simple, but mastery takes 10,000 hours of hard work.