SCRUM Project Planning

Twitter Summary: An advocacy post for using SCRUM for your project management needs.

My affection for SCRUM as a project management tool emerged from my dislike in writing project status reports. SCRUM is a project management process that has its roots in Japanese new product development. It focuses on increasing the speed of delivery and functionality.  The advantage of using SCRUM is that it creates a single common vocabulary throughout the company. Thus, when the delivery of a project is discussed everyone is using the same language and tools to communicate priorities, progress, rate of progress, roadblocks, and amount of work remaining. There is so much good information about SCRUM available, I will use my blog post just to highlight the interesting side effects that I have seen.

I have used SCRUM-like techniques to track projects and deliverables in most of the organizations I have worked in the past 10 years.  Yet most of the projects still had many elements of the Waterfall development model that I learned and used in college and used while developing medical and avionics applications. These ad-hoc project management practices mostly worked, but there were occasional lapses in deliverables that caused the usual scrambling to determine why some pieces were late and why we the delays weren’t know about sooner. It wasn’t until my last startup, that we adopted the full SCRUM process at the encouragement of our advisors.

The biggest change in adopting the full SCRUM process was the use of the “Information Radiators” which were either simple white boards with sticky notes to indicate: Product Backlog, Sprint Backlog, Blocks List, or lined paper with a graph that showed the Burndown Chart of how many activities were remaining to be done.

The beauty of using SCRUM and all its information radiators meant that I no longer had to write a project status report. Everybody in the company was educated in SCRUM and how it worked. Anyone could walk into the project room, review all the information radiators and know exactly where we were in the project, how the current sprint was progressing, and what amount of work was remaining before we could call the sprint “Done”.   We took advantage of being a small single office team and just posted everything using the available wall space. (Our implementation would not work well for a team member working remotely, but web based toolkits are available that make remote SCRUM project management a possibility.)

After several sprints of product delivery we realized each of the information radiators had a special role in helping improve the process for the next sprint. If we neglected to update the burndown chart, it was because we were slipping. If we neglected to update the product backlog, it was because our priorities were changing. If we neglected to update the sprint activities, it was because something was incompletely understood and we didn’t know what it meant to be “Done”. Any time we neglected an information radiator, it was usually because whatever information that element was trying to communicate was failing and we didn’t want to write it down.

The keys to our successful adoption of SCRUM were:

  • Require everyone involved either directly or tangentially to read the book. Agile Software Development with SCRUM
  • Leave the SCRUM on a page [pdf] littered around the SCRUM area so that people can be reminded of all the critical components and roles of SCRUM.
  • Get your SCRUM Master trained by a 3rd party to get used to working with the flow of the project.
  • Use the Information Radiators as they provide a constant status and reminder to the whole team as to how the project is progressing.
  • Make sure that the Sprint Review Meeting is held and that there is time spent focusing on how to make the next Sprint better. This was critical in helping us get better at delivering, and building a stronger product every sprint.

I have yet to find a better project management technique for developing products for the web. In running  a project using SCRUM, the activities bear a strong resemblance to what is done with Openspace Technology to run meetings. In using both techniques to communicate and plan, we were able to create an environment where the team members were participants, actors, and communicators in helping evolve the project and the company.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>