Scrum Log Jeff Sutherland

Scrum is an Agile development framework that Jeff Sutherland invented at Easel Corporation in 1993. Jeff worked with Ken Schwaber to formalize Scrum at OOPSLA'95. Together, they extended and enhanced Scrum at many software companies and helped write the Agile Manifesto.

Saturday, January 30, 2010

Excel Spreadsheet for Hyperproductive Scrum Teams - very cool!

Scrum Metrics for Hyperproductive Teams: How They Fly Like Fighter Aircraft

Jeff Sutherland and Scott Downey
Agile 2010 Submission

Scrum teams use lightweight metrics like story points, the burndown chart, and team velocity. The inventor of Scrum was a fighter pilot and used the burndown chart to help teams land a sprint properly. Recent work with hyperproductive teams shows they are like modern jet fighters in two ways. They have engines that produce velocity—alignment of the team, and team spirit. And they carefully measures aspects of performance to make slight adjustments in flight. Failing to constantly adjust the flight of the team can result in a hyperproductive crash into waterfall performance.

One hour discussion of a comprehensive, yet minimal set of team metrics used in an environment where hyperproductive teams are the norm, along with an Excel spreadsheet that can be used by any Scrum team to improve performance. Velocity, story completion by priority, work in progress, story acceptance rate by product owner, unplanned work, and trending accuracy of estimates all appear to be essential to determine the altitude, velocity, angle of attack, and attitude of a hyperproductive team. Slight adjustment of these parameters on a daily basis keeps the team on target. Half hour questions and discussion on using the Excel spreadsheet to improve team performance.

How you can download Scott Downey's extremely cool Excel Spreadsheet for your Scrum team:

Go to the Agile 2010 speaker web site:

Click on login and sign up for a free account. You can then login and access:

Please give us a few positive comments in a review so Agile 2010 will get this submission on the agenda for the conference. You can download the spreadsheet at the link above.

Sunday, January 24, 2010

Role of the Manager in Scrum

Pete Deemer, our Business Manager at the Scrum Training Institute, has written an excellent article on the role of the manager in Scrum.


    Like me, you probably get asked the following question quite often: "What's the role of a manager in Scrum? I'm a manager, and since I'm not mentioned in the definition of the Scrum roles, and the team is self-organizing, does that mean I'm supposed to just... disappear?" 
    I recently wrote a short guide to answering this question. A couple other CST's have stumbled upon it in the last few weeks and emailed me to say they found it quite useful, and I wanted to share it with the full group as well. If you have any feedback or suggestions, I'd love to hear. You can download the guide at: Manager 2.0: The Role of the Manager in Scrum
    Pete Deemer

Agile 2010 Abstract Posted: Hitting the Wall!

Hitting the Wall: What to Do When High Performing Scrum Overwhelms Operations

ll-at-once Scrum implementations require total commitment to change, high level management participation and aggressive removal of impediments. In July of 2009, Pegasystems (NASDAQ:PEGA) deployed 27 Scrum teams in the U.S. and India in less than two months and global continuous integration became a top priority impediment. To avoid “hitting the wall” before the first major Scrum release of their enterprise software applications, a Scrum SWAT team engineered a continuous integration environment for hundreds of software developers on two continents within a few weeks.

* Understand strategy for widespread deployment of Scrum in an enterprise
* See impact of Scrum team productivity on operations and infrastructure
* Learn how to identify top priority engineering impediments
* Be able to rapidly deploy continuous integration in a complex enterprise software environment

Create a free account at and you can download and review a draft of this paper.

Wednesday, January 13, 2010

Iterative vs. Incremental Development

Drawing by Jeff Patton

What is iterative and what is incremental development? Even the experts are confusing themselves when describing it. Perhaps our language is an inadequate reflection of reality.

Jeff Patton thinks software should be built the way an artist works. The artist "iterates" on the whole thing and the potential of the whole picture is visible in every iteration from the initial sketch to the final painting. The complete work comes gradually into focus. Patton calls this "iterative" development.

However, this is exactly what Mills and Brooks call "incremental" development. They advocate growing software like a plant. This is a similar metaphor to the way an artist's sketch "grows."

Harlan Mills of IBM first published this concept in “Debugging Techniques in Large Systems” Prentice Hall, 1971. (Any software system should be grown by incremental development.)

Fred Brooks popularized the concept in “No Silver Bullet: Essence and Accidents of Software Engineering” first published in IEEE Computer, April 1987 with the final version published in the anniversary edition of “The Mythical Man Month.”

So Patton has the right idea, but his use of the term iterative development is wrong. Incremental development is iterating on the whole thing (each iteration is a minimal useable feature set that is potentially shippable).

Patton slams the common practice of building one feature completely in an iteration, then a second feature in a subsequent iteration. He calls this incremental development (wrong!). He is out of step with the terminology used by computer scientists over many decades.

Key to the Mills/Brooks concept of incremental development is the idea that every iteration is usable in some way (potentially shippable software). The first Scrum shipped all increments at the end of each iteration and they were used by internal consultants “in anger” to execute on revenue generating customer projects. It was only “potentially shippable” because the Product Owner (Don Roedner) was not ready to release it to the general market.

Patton is not clear on what we meant by potentially shippable software which is that every iteration is useable.  “Potentially shippable” was first described by Ken Schwaber in his OOPSLA 1995 paper on Scrum after observing the first Scrum team. This first paper on Scrum is republished in “The Scrum Papers.” Perhaps Ken and I could have been clearer on what “potential shippable software” means.

So Scrum is both interative and incremental development when done properly. Each iteration delivers a fully functional increment, just as a plant works at every stage of growth. If it does this every iteration is “potentially shippable" and in the ideal case is shipped to a set of end users who use it to get real work done and provide feedback.