Archive for the ‘agile’ Category

Agile Project Management with Scrum

Saturday, August 18th, 2007

I just finished reading Agile Project Management with Scrum by Ken Schwaber. It was an easy read with entertaining war stories, but when it comes to the Scrum methodology itself I find myself a bit torn.

On the one hand, it seems like an entirely reasonable and sane way to manage a software project with constantly changing requirements while producing a minimal amount of overhead in the form of paperwork.

On the other hand, it seems that you can’t have a software development methodology without high-priced consultants to show you how to do it. Honestly, though, Scrum is simple enough that I can’t see why you’d need one…

Unless, of course, they invent their own jargon, in which case it might sound pretty complicated. It might even sound so complicated and different from what you’re doing now that you might decide that a consultant sounds like a pretty good idea after all. Hmmm…

Let me save you the money. Here’s a description of Scrum using the jargon:

  1. At the beginning of a Sprint, the team meets with the Product Owner and the Scrum Master to update the Product Backlog
  2. The team creates a Sprint Backlog by selecting the items in the Product Backlog that it will turn into sashimi1 during the Sprint
  3. Each morning, the team holds a Scrum to coordinate the tasks it will work on
  4. At the end of the Sprint, the team holds a review meeting where it demonstrates the work accomplished
  5. All meetings are time-boxed
  6. Once a cycle is completed, it begins again, updating the Product Backlog for a new Sprint

And here’s a description of Scrum in English:

  1. Every 30 days, the team meets with the Product Manager and Team Lead to update a prioritized list of features and tasks
  2. The team decides decides how many of the top priorities it can handle in the next 30 days, and commits to finishing them completely
  3. Each morning, the team holds a short meeting to discuss current status of the tasks on the list and address any issues that arise
  4. At the end of the 30 days, the team demonstrates the work accomplished to the stakeholders
  5. All meetings are limited to a fixed time (e.g., 15 minutes for the daily status meeting) in order to keep the work moving forward
  6. Once a cycle is completed, it begins again, updating the list of features and tasks to reflect new prorities and choosing those to be accomplished in the next 30 days

That said, it’s still worth reading. The stories of teams using Scrum in the real world are fun to listen to, and you might even learn something. Particularly when it comes to Software Engineering, it’s easy enough to get caught up in a lot of abstract theory about the software lifecycle (or raw fish, or whatever) that it’s very helpful to see how it’s actually put into practice.

I have to say, though, that when it comes to consulting, Schwaber almost lets the cat out of the bag. In Chapter 5, The Product Owner. He tells a story about working with a company where both team and management were pretty skeptical of Scrum, so he decided to keep it low-key:

… I told them that we used a prioritized list of things that they wanted done to drive development cycles of one month. Every month, we’d show them completed functionality, we’d review the list of what to do next, and we’d figure out what the team could do next… Scrum seemed simple, easy to understand, and [...] very straightforward.

Of course, if you put it that way, how are you going to make any money? Certified ScrumMaster? Sounds good. Certified Guy-Who-Keeps-the-Prioritized-List? Not so much.

Bottom line: if you want to know about Scrum, read about it on the web, then try it. If you’re like me, you’ll read the material available on the web and figure that it seems way too simple — there must be more to it, and decide that you need to purchase a book or two to really understand the methodology.

Well, yes and no. If you like reading (and I do), and if it makes you feel better (and it did), go ahead and get the book. It’s short read (fewer than 150 pages), it’s pretty entertaining, you’ll probably learn something, and it might even fire you up, thinking “hey, yeah, this could work!” On the other hand, if you’ve read the available materials on the web, you’ve pretty much nailed it. The only way you’re going to get any better at it is by doing it.

1At least, I think that’s what sashimi means; the term is used before it’s defined, and it doesn’t appear in the book’s glossary. From searching the web, it appears that it might be the name of an actual Japanese project management methodology. Or possibly just raw fish.