SCRUM + Nine

---

In a paper supported by Microsoft and NC State University, we learn about SCRUM practices by three teams, and about nine practices that these teams applied as agumentation to SCRUM. The great thing about this paper is that it is well supported by metrics and a mountain of cited references, so not as "populist" as others

To begin, the Microsoft authors describe SCRUM this way:

The Scrum methodology is an agile software development process that works as a project management wrapper around existing engineering practices to iteratively and incrementally develop software.

I like that description: "project management wrapper", since, unlike XP and other agile methodologies, SCRUM is almost exclusively a set of loosely coupled PM practices.

That said, we read on to learn about three teams, A, B, and C. We learn that story points live! Microsoftees like them (and so does Jeff Sutherland):

The Microsoft teams felt the use of Planning Poker enabled their team to have relatively low estimation error from the beginning of the project. Figure 1 [below] depicts the estimation error for Team A (the middle line) relative to the cone of uncertainty (the outer lines). The cone of uncertainty is a concept introduced by [Barry] Boehm and made prominent more recently by [Steve] McConnell  based upon the idea that uncertainty decreases significantly as one obtains new knowledge as the project progresses.Team A’s estimation accuracy was relatively low starting from the first iteration. The team attributes their accuracy to the use of the Planning Poker practice.

And, what about the other 8 practices? The ones cited are:

1. Continuous integration (CI) with Visual Studio (a Microsoft product)
2. Unit TDD using using the NUnit or JUnit frameworks
3. Quality gates, defined as 1 or 0 on predefined 'done' criteria
4. Source control, again with Visual Studio
5. Code coverage by test scripts followed the Microsoft Engineering Excellence recommendation of having 80% unit test coverage
6. Peer reviews
7. Static analysis of team metrics
8. Documentation in XML

And what conclusion is drawn?

The three teams were compared to a benchmark, 10 defects/line of code. Two of the three teams did substantially better than the benchmark (2 and 5) and one team did substantially worse (21). The latter team is reported (in the paper) to have scrimped on testing. Thus, we get this wise conclusion:

These results further back up our assertion on the importance of the engineering practices followed with Scrum (in this case more extensive testing) rather than the Scrum process itself.

Wow! That's a biggie: design-development-test practices matter more than the PM wrapper! We should all bear this in mind as we go about debating wrappers.

And, one more, about representation and availability in another situation:

...our results are only valid in the context of these three teams and the results may not generalize beyond these three teams.

And, last, what about errors in cause and effect?

There could have been factors regarding expertise in the code base, which could have also contributed to these results. But considering the magnitude of improvement 250%, there would still have to be an improvement associated with Scrum even after taking into account any improvement due to experience acquisition.

And, need I mention this gem?

---

Bookmark this on Delicious