Lessons from Week One of a Small Team's Scrum

Balancing time between development and client fulfillment is one of the biggest challenges in a small, technology-driven firm. After coming on-board at New Media Campaigns earlier this month it became apparent that the development team had grown to a size necessitating better coordination of efforts. Having recently spent time at Microsoft where Scrum is the preferred weapon of project management choice I suggested we use it and tweak as we go. One week into our first sprint and already we have learned a great deal.

Never heard of Scrum? Scrum is a process for managing complex projects that doesn't involve complicated rules and practices. At its core Scrum emphasizes working in short, focused 'sprints'. Going into these 3-4 week intervals of work the Product Owner and Team decide what items to take off of the "Product Backlog", a prioritized list of items which have not been built, and onto the "Sprint Backlog". The Sprint Backlog is a lot like a work agreement between a general contractor and a subcontractor. Once on the Sprint Backlog the Team has committed to completing that task in a "shippable state" by the end date of the sprint. No new features go onto the sprint backlog once the sprint begins. The scrum ship has sailed. During the sprint daily 'stand-up' meetings lasting no longer than 15 minutes report progress and bubble up potential road blocks. After the sprint has ended the Team and Product Owner review the process, alter where necessary, and repeat. For more detail there are many great sources on the web.

My key take-aways from the week 1 of our first Scrum Sprint are:

#1 - Scrum's Simplicity Makes it Easy to Get Started

Two weeks ago all members of my team had 'heard' of "Scrum" but did not know what it was. After an introductory memo and a 30-minute meeting everyone had a good enough understanding of Scrum to get on-board and moving. We compiled the Product Backlog last week and decided on a shorter 3-week sprint for our first time through. This week we have been off to the races, holding daily stand-ups, and tracking progress against the backlog.

#2 - Google Docs is Great for Product and Sprint Backlogs

There are many software products out there that help facilitate the Scrum process. Most of them are expensive. Luckily all you really need is a spreadsheet. Ideally one that is centrally accessible. Google Docs' Spreadsheet app is all the software a small Scrum team needs to get going. Best of all: it's free. The development team is always looking at the live product and sprint backlogs and can be updating them collaboratively.

#3 - Burndown Charts are Really Useful with Small Teams

The burndown chart is a simple visualization of how much work remains in the sprint. Going into a sprint the Team 'costs', or estimates, how long each work item takes. Each day progress on work items is recorded which enables us to plot how much work remains against how much work would 'ideally' remain. Below is the New Media Campaigns burndown chart for this sprint taken right out of Google Docs. Using a burndown chart with a small team increases the pressure of making individual, daily progress and enables the team to rally around being on schedule. Frankly it's really rewarding to make the "Actual" line fall below the "Expected" line. As you can see right now we're a few hours behind!

Scrum in a small business with a small team is a different beast than Scrum at a place like Microsoft. Self-organization is a fundamental tenant of the process and as we become adjusted to the process we will learn a lot along the way. I would love to hear how other small dev businesses and dev teams have tweaked Scrum in the comments! As this sprint finishes up and we continue to Scrum I'll be writing about our challenges, insights, and experiences in the posts ahead.