Microsoft   |   patterns & practices   |   Developer Network   |   Enterprise Library   |   Acceptance Testing Guide   |   Personal Site

Scrum at Macro and Micro Levels - Grigori Melnik: Thoughts on Agile Software Engineering and Beyond - Site Home - MSDN Blogs

Scrum at Macro and Micro Levels

Scrum at Macro and Micro Levels

  • Comments 1

Scrum has come of age. Not only it is entering the mainstream of modern software development, but it is, IMHO, the most popular/successful agile method for project management today. It was not the case a few years ago, when XP dominated the agile world. Ken Schwaber reconfirmed this with some stats on Scrum penetration, the number of Certified Scrum Masters, Certified Practicing Scrum Masters, etc.

Historically, when agile methods were in the early adolescence period, one of the main criticisms was that agile methods did not scale. At the Canadian Agile Workshop dedicated to the very issue of scaling agile methods (2003, http://www.agilenetwork.ca/ws2003/ ), Martin Fowler argued strongly against scaling up while Ken Schwaber described his experiences working with Scrum on large projects (100+ team members) and several techniques he had successfully used. One of the techniques was the Scrum of Scrums (in a large team of teams, one representative of each comprising team regularly (Schwaber recommends daily; in practice, it tends to be 2-3 times/week) participates in a scrum of scrums meeting, that is conducted similarly to the regular scrum). Mike Cohn gives a nice description and various techniques on how to run Scrum of Scrums meetings effectively (http://www.mountaingoatsoftware.com/article/35).

In his Agile 2007 talk, Schwaber goes beyond the issue of scaling Scrum. He addresses the matter of how to roll out Scrum adoption enterprise-wide. Schwaber emphasizes the fact that there is no “enterprise” version of Scrum. It is a simple empirical framework for managing the development and deployment of (complex) products/systems. There is, however, Scrum used throughout the enterprise. Schwaber describes the “etc.” project - the Enterprise Transition project, not for development and maintaining of products/systems, but rather for optimization of the enterprise’s overall productivity, quality, value and competitiveness. The idea is to apply Scrum to transition the enterprise to Scrum. The lean principle of ruthless elimination of waste is fundamental. Similarly to a development project, a team (in charge of transition) composes a project backlog (Transition product backlog) with items requiring improvement. These could be fed from the impediments identified by current individual development projects. 30-day sprints are conducted to communicate Scrum values and the impact, establish and meet preconditions that must be met before a project can use Scrum, identify which projects to use Scrum next, identify Scrum masters, provide training,  define Scrum metrics and mechanisms for their collection, assess compensation policies that encourage teamwork, and so on. Clearly, such transition project is a major undertaking. Schwaber estimates that it would take 6 months to roll-out, 3-5 years to make it stick and then continuous improvement.

Fundamentally, for Scrum to be successful, a change in thought process is necessary.  Those who get Scrum seem to take and apply it beyond their immediate teams – some to a macro level (Scrum of Scrums) and some to a micro level (personal work management and self-improvement). The examples of such adoptions are not hard to find at patterns & practices. The new approach to portfolio management and execution is one of them (will post a separate entry on this). The other two are Peter Provost’s efficient computer repaves (http://www.peterprovost.org/archive/2007/07/16/23053.aspx) and J.D.Meier’s improvement/learning sprints (http://blogs.msdn.com/jmeier/archive/2007/03/09/30-day-improvement-sprints.aspx). Similarly, I execute the MoveFromCanada project with my family in a Scrum-like fashion (actually, it’s also an example of a distributed Scrum). Essentially it all comes down to 1) maintaining and learning from the prioritized backlog; 2) having clear acceptance criteria and knowing your status; 3) using discipline and good practices to be able to respond positively to change.

With the new portfolio management and execution methodology, it appears that we’ve focused on addressing the first of these for now (building a prioritized backlog). Acceptance criteria and how we are going to respond positively to change is not as apparent now. Still, I am enthused.

What all these examples demonstrate is that Scrum ideas can be applied at macro and micro levels,  inevitably penetrating other aspects of our work and life (beyond software engineering). The reality contradicts Craig Larman’s prediction that we all would need to die first before the agile ideas become the mainstream. Agile is already there, and as far as I can tell I am still alive. So is my team!

Comments
  • My former colleague Tom is always addressing some very interesting issues. Today he decided to broach

Page 1 of 1 (1 items)
Leave a Comment
  • Please add 7 and 7 and type the answer here:
  • Post