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.