A list summarizing Scrum

 Revised May 6, 2012.

***
The list below is not self-explanatory, but it covers the key ideas one has to know and execute on to do Scrum professionally.  Of course, becoming proficient at doing them at the highest level (at the rugby World Cup level) is a lifetime's work.  Rugby is a simple game with simple rules, but to reach the highest level of play is very difficult.

This list could be used as a starting point for defining 'agile' or 'scrum' in your firm. I am suggesting such a definition could drive useful conversations.  And it fits on one page (a key criterion).

A list that summarizes what Scrum is:

Roles:
Product Owner
ScrumMaster
Implementor ('Dev Team' role)

Events:
Sprint - 4 weeks or less.
Sprint Planning Meeting
Daily Scrum
Sprint Review
Sprint Retrospective

Scrum Artifacts:
Product Backlog
Product Backlog Items
Sprint Backlog
Working Product
Increment (of working product)
[Sprint Burndown chart]
[Release Burndown chart]
Definition of Done
[Public Impediment List]

Key Ideas:
Scrum is a process framework
Deliver business value faster
The Product Owner is maximizing the value delivered by the Team
Inspect & Adapt
Transparency
Self-organizing
7 plus/minus 2
Build iteratively and incrementally
Working product at the end of each Sprint
Potentially shippable product increment
Need for feedback
Always learning
Always adapting to good and bad change
Usefulness of high quality
Scrum hates technical debt
Knowing work remaining in a Sprint (daily)
Knowing work remaining in a Release (every Sprint)
Protecting the implementers from disruptions
Protecting the implementers from the Death March
The ScrumMaster drives the removal of impediments
Must add other practices (e.g., engineering practices) to Scrum to do work
Scrum does not include agile release planning (but you probably need it)
Scrum is consistent with the Agile Manifesto and Agile Principles
The Team should be having more fun (and be more creative)
Sprint Planning Meeting, parts 1 & 2.
The Product Owner orders the work in the PB; the implementers decide how much they can do in a Sprint.
Sprint Goal
Sprint "commitment"
The 3 Daily Scrum questions
Purpose of Daily Scrum: self-management
Demo working product & get feedback
Servant leadership
Chickens can help
Just-enough, just-in-time, documentation


***

Your comments please.

Here is the file: http://agileconsortium.pbworks.com/w/page/53405031/List%20summarizing%20Scrum

Agile's broad adoption and mediocrity - what to do

Ken Judy has an excellent, although blunt, blog post here:
http://judykat.com/ken-judy/agilescrumlean-broad-adoption-mediocrity-faul/

His main point maybe is that we do not have enough truly professional scrum (or agile) implementations.

And why? Because we have implemented too broadly too fast.  Is probably the main reason, in his opinion.

Some good insights.  Read them.

***

Here are my related thoughts.

The potential of a team using Scrum is enormous. And I don't think any team, ever, reaches their full potential.  In any sport, including what we call Scrum.

It is fair to say that most teams barely scratch the surface of their potential.  They get a 20% improvement when they could easily have gotten 100%.  And eventually get 5x - 10x.

Why?  Some root causes...

1. Reliance on "Scrum": Too many teams have a 'sit back' attitude and expect Scrum magically to do all the work. And it is amazing what Scrum alone can do.  But it really takes an active, purposeful, spirited team to get real success.

2. Better Product Owner. Scrum will not magically make George (a really smart guy in your firm) a good product owner.  In fact, all Scrum does is make us assign him that title, and then gives us lots of ways to observe, if we will, that he sucks at the job. Hopefully, someone sees the problem and fixes it.  It really really helps to have a really really good PO.

3. No real Team. The people don't feel they are a real Team. And no one knows how to form a real team. (Lots of explicit and tacit knowledge in doing that.  We will talk about that later.)

4. Not attacking impediments. One of the most powerful things in Scrum is that single-piece flow of attacking one impediment at a time.  The Scrum team is not aggressive enough in doing this. Or the company does not support it meaningfully.

5. Better Engineering Practices. When switching to agile, a team needs to move to more agile engineering practices. No, not for the silly reason that agile is in the name. Because the agile engineering practices are more effective. Probably more effective even if doing waterfall, but certainly when doing agile. SCM, automated build, CI, automated UT, automated functional tests, faster regression testing, etc, etc.

6. Scrum-Butt and Unprofessional Scrum.  Do you think the NY Giants should have fired all their coaches in Sept 2011?  Me neither.  Yet, somehow, many people magically expect that all a team needs is one 2-day course, and then they can play Scrum professionally.  Remember that at the beginning of September, every player on the Giants team has been playing football for years. At what you and I would call a professional level (college is virtually professional in many way). They are not beginners in the sport, and they need further coaching. Further training.

And we think people who are beginners at Scrum need only a 2 day course?  C'mon. They need a lot more. Now, of course it has to be reasonable compared to the value. If you need help with that math, I can help.

Related, but a bit different, is how beginners (or beginning firms) are so sure they are smarter than the Scrum community, which now has many centuries of experience with Scrum.  So, they change Scrum ('we are special,' they sometimes say). They do Scrum, but people on more than one team. They do Scrum, but they do the Daily Scrum twice a week. They do Scrum, but they don't have working software at the end of every Sprint.  Etc. Etc.

***
There are other reasons.  Many more.

We need more teams playing Scrum professionally, and showing others how it really ought to be done.
 

Six Myths of Product Development

Here is an article about: Six Myths of Product Development.  By Stafan Thomke and Donald Reinertsen.

Here are the fallacies in one list:

1. High utilization of resources will improve performance.
2. Processing the work in large batches improves he economics of the process.
3. Our plan is great; we just need to stick to it.
4. The sooner the project is started, the sooner it will be finished.
5. The more features we put into a product, the more customers will like it.
6. We will be more successful if we get it right the first time.

Recommended.  Read the article.