My introduction to Agile/Scrum

Last time I mentioned I had looked at Agile/XP or Extreme Programming a few years ago and although I was keenly interested in its approach to software development, I couldn't get past the hurdles in introducing it into an existing group of developers. Too much of a culture shift, and I didn't see how it would immediately help with coordination with other teams such as the user interface design group, QA, Program Management, and so on.

And so my interest in Agile stayed pretty much that. Once in a while I'd hear about other Agile approaches but my mental model was locked into the ideas around XP and so I would wander on to other technology topics. However, time passed and the realization that the old-style "waterfall" model of software development (the "if only enough time is spent at each stage, all will be well" philosophy) was interfering with our ability to react faster to market and internal demands.

So I started my research again into Agile practices to see what had changed, or what else was available that might help. Not too long into the reading and learning phase, I happened upon the Agile process that has come to be known as Scrum. Odd name, I thought. Not quite as hip sounding as "XP". But for whatever fortuitous reason, I lingered a bit longer and read up on Scrum and its approach to Agile.

Boy, am I glad I did.

I got so enamoured with the holistic yet straightforward approach of Scrum to software development that I attended a Certified Scrum Master course taught by CC-Pace in Fairfax VA. It was a great experience to say the least. Small class, lots of interaction, many different experiences with software development and even a few Agilists (XP'ers). There was a great deal of role playing and working through software development scenarios. At the end, after passing a test certification was granted. Now, being a certified Scrum Master doesn't by any means state you are a master of Scrum. That will take years of study and application to learn the nuances of such a simple approach to software development. Instead, it means that you are certified to play the role of a member of the team designated as the ScrumMaster - in essence, the person who guides the team in all aspects of Scrum. However, the ScrumMaster is not actually a member of the team doing the actual work. And this is a key point in understanding Scrum.

Unlike XP, Scrum positions itself as a "work management process" rather than a "software development process". It can be used on non-software efforts including managing a business, managing services, and so on. It's a way to organize a team of cross-functional people to "deliver priortized business value every 30 days". Wow, sounds like a mouthful.

Actually, Scrum is straightforward and that was a key reason I liked it. It's basic principle is items of work are completed in a priority order (determine by a Product Owner) by a team of people (the Team) every 30 days. The 30 days can be changed under local circumstances to 15 days, but 30 days has been viewed as normal practice by results from the 15 years that Scrum has been in use. Here's how it works:

On day 1 of the cycle (called a Sprint), the Team meets with the Product Owner and the Scrum Master to go over a prioritized backlog of items (called the Product Backlog). These are essentially the work items that need to be done without regard to difficulty to implement or complete them. The Product Owner applies whatever business reasons they need to in order to come with the priority. The Team then goes down the list one-by-one asking questions about each item.

Once an item is understand at a reasonable level, the Team conducts a group estimate of the effort needed to complete the item. The estimate is done by voting on a weight (something developers do all of the time when they say this is small, medium, large). Votes are taken in succession until the team coalesces around a number that they can agree on. This then becomes the number or weight of that item. This process continues until the Team estimates more work than they can likely complete in 30 days. This set of work forms the backlog items for the Sprint. Interestingly, the meeting itself has a time-box of 4 hours to keep it from becoming interminable. Afterwards, the Team leaves to develop a set of tasks for each item and estimates each of those as remaining-hours-of-work. Again, this step is time-boxed to 4 hours.

On day 2, the work actually begins.

Next time, I'll continue with the look into how Scrum works.

Technorati Profile

Posted by Mark M. Baker at 03:17 PM  Permalink