Here it is. One sentence for management:
Scrum is Lean Production for Product Development.
I admit, this is an oversimplification, but it will get us started.
Looking at it more deeply, Scrum is…
- Getting things done – Before a task (a piece of functionality which is valuabe to the customer) is started, the Customer (through the “Product Owner”) and the Supplier (the “Team”) agree on clear goals to be achieved in a relatively short period of time. They also agree on the definition of “done”. And the end of that period, the Product Owner verifies that the agreed functionality has been realized.
- Business Value (ROI) driven – The Product Owner prioritizes functionality according to Business Value. High value items are done first. Low value items are done later. The Product Owner may even decide that Low Value Items aren’t worth the cost.
-Iterative, incremental progress – An iteration (or “Sprint”) has a short, fixed length. After each sprint, the customer inspects the status of work completed. Only work which is done may be presented to the customer.
-Fixed Time, Fixed Budget, Fixed Quality, Fixed Scope – The parameters for each iteration are defined in advance.
-Commitment driven – Product Owner and Team agree on Scope for each Sprint. Both take responsibility for the results.
-Taking what you can eat – The Team commits to all the functionality it can produce by the end of the Sprint, no more, no less. The pressure is moderate but sustainable.
-Transparent – At the end of the iteration, committed functionality must be done. This is examined and confirmed by the Product Owner. Along the way, the Project Leader (“Scrum-Master”) verifies that Team members are on track and removes hindrances as they arise.
-Self-Improving – After each Sprint, the Team reviews how it works, identifies improvements, and agrees which one to implement.
-Self-Organizing – People actually responsible for doing work understand their work best. They are best able to plan and execute their work. (If you don’t believe this, then come to a Scrum workshop. It’s easy to demonstrate).
-Efficient – impediments to success are identified quickly so they can be eliminated quickly.
-Lean – The Team realizes functionality, the Product Owner manages the workload. Other interested parties (e.g. Management, Steering Committees, the Customer’s customers, and other “Chickens”) are involved, but prevented from disrupting progress.
-Beautiful – Beauty is painful, but priceless. Ask anyone who’s achieved it.
Some of you may have raised your eyebrows when you read “Scrum is fixed scope”. Scrum is Agile, isn’t it? But that’s just the point.
To be precise, each Sprint is fixed scope. Under Scrum, we take a big complex project and deliver it in little slices. (Remember integrals in college?) Each slice is achievable. After each slice, the Product Owners measures the progress and verifies that the Project is on track. If not, s/he can apply corrective measures to be achieve the company’s goals.
Yes, it can happen that a Sprint does not meet its goals. This is a warning – a canary in the coal mine – that the project is not moving forward as planned. It may be that the team was too ambitious and accepted too much, but it may also be that the project has taken on too much Scope or that the Scope is unrealistic.
Every month, Scrum gives the product owner the chance to adjust to reality. Change Scope, push a release forward or backward, increase planned time or budget, or remove other hindrances to progress. Of course if the project looks really hopeless, the Product Owner might reassign the team to a more promising project.
And this is what agility is all about – keeping the company in sync with reality.
P.S. There are still places open for our Scrumbreakfast on Wedensday… Sign up now!









If I had to pick two arguments I’d got for “Commitment driven”: The people that deliver have to commit in person to the task and “Fixed Time”. The time aspect is magic, bacause everybody knows the main parts of the time table (the sprints) by heart. This keeps them from changeing the plan “in flight”.
I’d add a third argument – Business Value Driven.
The product owner manages a queue of functionality to be realized. Every entry in the backlog represents potential value to him.
This is very different from allocating people’s time. Knowledge workers can allocate their time better, but only the product owner is in a position to think about business value.