Scrum project management: The Commune between the Cathedral and the Bazaar

Scum is a framework that has been used to manage complex adaptive problems. Scrum is particularly popular in software development and in digital media projects. Characteristic to Scum is its iterative and agile approach in contrast to classic more rigid frameworks that use sequential project phases.

Central to Scrum are the Sprints, a predefined timescale of one month or less. During a Sprint a new usable increment of the product gets developed. Each Sprint has a clear goal so that all the team members know what needs to be build. The short timespan of a Sprint makes the overall project quite flexible and adaptive to arising complexities.

Overview of the Scum process
Source: http://en.wikipedia.org/wiki/File:Scrum_process.svg CC license

This requires the teams to be flexible and self organising. Teams are multidisciplinary and have all the competencies to complete the project. Besides designers and developers, each team has a Product Owner who is responsible for maintaining the Product Backlog (a list of all product features and requirements) and a Scrum Master who makes sure the process is going smoothly and ensures the development team has everything they need to perform their tasks.

The Performing Scrum Team – by Marcel van Hove CC license

Scrum as a hybrid Bazaar

In “The Cathedral & the Bazaar” Eric Raymond discusses the open-source software development style ‘Bazaar’ versus the ‘cathedral’ style that is common in the world of proprietary software. We would argue that Scrum embodies some important characteristics of the Bazaar style within a cathedral framework.

Just as the Bazaar model Scrum works as a self-correcting system. The short timespan of the Scrum sprints entail rapid prototyping and allow for the important characteristic of the Bazaar model: “Release early and update often” (Raymond, 7). But unlike the Bazaar model the individual software iterations are usually not made public. Thus, avoiding the risk of losing users patience due to buggy software versions.

However, Scrum does not embody the important quality of the open source Bazaar style that users should be treated as co-developers. Therefore, the famous proposition of Linux and the Bazaar style in general: “Given enough eyeballs, all bugs are shallow” (Raymond, 8) does not apply to the Scrum method. Where hundreds of users could work on an open-source project, Scrum teams are usually limited to nine developers (Schwaber and Sutherland, 6). In Scrum, large Development Teams generate too much complexity and requires too much coordination.

Finally, due to the central role of the Product Owner Scrum has more control over the final product. In open source the community decides what to implement, with no one in control of the overall development, projects could be forked when opinions collide. Thus, we should see Scrum more as a commune that preaches openness and equality on the surface, while enforcing a strict regime that applies to all actors.

Apparatuses of self-regulation

The Scrum methodology offers teams tools that help them to plan the project, such as Backlogs to give an overview of what still needs to be done, Planning Poker to create time estimates and Burn Down Charts to see what tasks are completed and to see if the team is still on schedule.

Vilém Flusser argues in the essay “The Apparatus” that tools in the classical sense (like hammers, scissors and needles) are extensions of human capacities and help to give new forms to (natural) things. As Flusser argues they ‘inform’, like the needle and the scissors help the shoemaker to make shoes (Flusser, 22).

The tools offered by the Scrum methodology extend our capacities in the sense that they help us to generate forecasts and give insight in the progress of the project. But what do they inform? Perhaps it is more suitable to ask ‘who’ do they inform. These tools are used to produce mindsets for self regulation. From a cybernetic point of view Scrum teams act like self regulating systems, adjusting pace, direction and definition of the project without outside influence.

Typical Burn Down Chart
Source: http://www.flickr.com/photos/josephj/4255725669 CC license

The Product Backlog serves as a roadmap, guiding the team through a set of requirements to finish the project. These requirements are called ‘user stories’ and should be seen as possible sites of entropy that need to be regulated. Regulation is done in two ways, primarily by prioritizing the user stories, secondly by awarding effort points to each user story. Making them manageable allowing the Burn Down Chart to give an overview of the pace of the work.

Typical Back Log of a sprint
Source: http://kept.co.za/group/images/stories/scrum%20todo%20board.jpg CC license

Conclusion

Scum is an agile framework that through short sprints and its non hierarchical team structure offers a Bazaar like development process.  Scrum by design is a self-correcting system and therefore not as open as the open-source Bazaar style.  So we should see Scrum as a commune that preaches openness and equality on the surface, while enforcing a strict regime that applies to all team members. This manifests itself in the strict Scrum events and tools which produces mindsets for self regulation. Although flexible, Scrum does not allow for projects to fork, the Product Owner has some control over the final result and is often driven by commercial interests.

References

Flusser, Vilém. “The Apparatus.” Towards a Philosophy of Photography. London: Reaktion, 2000. N. pag. Print.

Raymond, Eric S. The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. O’Reilly, 2008. Print.

Schwaber, Ken, and Jeff Sutherland. The Scrum Guide The Definitive Guide to Scrum: The
Rules of the Game. Scrum.org, 2011.

Takeuchi, Hirotaka, and Ikujiro Nonaka. “The new new product development game.” Harvard business review 64.1 1986: 137-146. Print.

Further reading

Sutherland, Jeff. “Agile development: Lessons learned from the first scrum.” Cutter Agile Project Management Advisory Service: Executive Update 5.20. 2004: 1-4. Print.