What is Scrum?

Scrum is a framework for getting work done. Much of the framework relates to getting work done in a team. 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 Team (or Implementer).  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 role represents the implementors, the people who do the "real work." All 3 roles together form the full team of 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 sprint is planned.  The Sprint is a 1 to 4 week timebox.  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 look at the working software and give feedback (both positive and negative is expected).  And finally the full Scrum Team meets for a Retrospective, to see how they can work more productively and to remove a 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 Sprinting, 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 an X, I want to do Y, so that Z.") .  In Sprint Planning, the Team creates a Sprint Backlog (essentially a plan for the Sprint.).  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.  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 of 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 to the quick changes in the business world. 

In the software development community, 17 men originated the Agile Manifesto in 2001.  The Agile Manifesto is a good summary of the basic ideas around agile.  With a few minor changes (substituting 'product' for 'software' and similar), the Manifesto and the Principles are a good summary of what falls under the agile banner. 

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

In Agile Software Development, 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 Journey?

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

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 with 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 them to take the CSM course, with a 2-day workshop covering Release Planning, where they plan the project to start on 'Monday.'  It is also helpful to have an Agile Coach for them, full-time for some period.  It is not required to do it this way, but it does lead to the most success.

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.

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. 

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.

 

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 2-day workshop that covers Release Planning and Sprint Planning.

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

After a month, have the Product Owner take a Intermediate CSPO course, with a BV Engineering workshop.

The one other key thing is to establish a public impediment list, and work the 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.

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
* Emprical Process Control
* Self-managing teams
* The PO uses the Pareto Rule
* Complex Adaptive Systems
* Adaptive Planning (eg, release plan refactoring)

 

Why Agile Works:

Agile is all about delivering business value. Agile is a way of getting a lot more business value out of your dollar invested in projects.  Agile is both wonderfully simple and perplexingly 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.  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 implicitly 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 IT sides to collaborate.  It provides  a way to focus on achieving business value.  It controls the project.  It releases a substantial portion of the team's energy and allows the team to evolve toward better Agile practices (eg, 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 implmentation 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.