Practice Sprints

synoppsys: At the beginning of December 2007, our team engaged in 2 practice sprints (in 2 week iterations) within the Scrum project management framework with mixed success.

The two mini-projects were:
1) a new home page for one of the sites we support;
2) a “spike” on Ruby as applied to another one of our applications that needs to be rewritten.

Summary of our Sprint Retrospective:

What went well?

• Introduced peer accountability.
• Kept us focused.
• Added structure to the process.
• Gave us short-term goals.
• Daily meetings provided opportunity to quickly check status.
• Good for team-building.

What didn’t go so well?

• Did not do burndown charts.
• Took on lots more than agreed-upon.
• Did not write in stories.
• Kept track of actual hours, rather than estimated hours.
• Felt bad in daily meetings if we did not accomplish anything the day before.
• Couldn’t analyze tasks (which were being tracked in Outlook).
• Spikes are uncomfortable if you’re working by yourself.

What will we do next time?

• Write in user stories.
• Estimate product backlog in story points.
• Prioritize stories.
• Estimate sprint backlog in hours.
• Do burndown charts.
• Try Sharepoint with backlogs in Excel.
• Do more research on Scrum.

Since these practice sprints, we have completed a few more sprints. Each time, we are becoming more comfortable with the approach, improving our processes and becoming more productive.

Four Must-Read Books on Agile/Scrum

synoppsys: If you are beginning to explore the principles of agile software development (Scrum in particular), start by reading these classic books on the topic.

I have learned the most about agile software development and scrum from these books. I would highly recommend them.

Agile Software Development with Scrum by Ken Schwaber and Mike Beedle, 2001.

User Stories Applied: For Agile Software Development by Mike Cohn, 2004.

Agile Estimating and Planning by Mike Cohn, 2005.

Scrum and XP from the Trenches by Henrik Kniberg, 2007.

The best graphical representation of Scrum that I have come across is located here.

Scrum: Agile Project Management

synoppsys: Our team is experimenting with Scrum, an Agile project management approach.

Scrum is a project management framework which is aligned with principles of Agile Software Development. The key values, as outlined in the Agile Manifesto, are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Important characteristics of this approach are:

• The customer is a participating member of the development team.
• We expect changes as the project proceeds and we respond quickly and flexibly.
• We deliver features iteratively and incrementally: we start with features that have the most impact on the most people.
• We strive to produce visible deliverables (prototype, graphic design, requirements document, functioning web site, etc.) in a short period of time (2 to 4 weeks).
• We define our success in terms of working features that meet customer needs.
• We pursue the simplest, while most effective, designs.

Our team has completed 3 sprints. Future posts will detail Scrum and summarize our experiences.

Redesign: The New 4 Letter Word

synoppsys: An “iteration” may be a more appropriate description of web site projects than a “redesign.”

Like any bad habit, removing a word from one’s vocabulary is challenging, especially a word that has been so close to one’s heart. For the past year, I have probably repeated this sentence 1,000 times: “this web site needs a redesign.” Our project queue is full of web site “redesigns.” When I started to hear customers use the word in our conversations, I became concerned. This word promises much more than we can deliver.

Think a moment about what “redesign” implies. Let’s be the customer for a second. Is this what they are hearing? “Our web team is going to redesign your web site, because it really sucks. We can’t salvage anything. So by the end of the quarter, your current ugly site will be totally trashed and replaced with a site that is a hundred times better, with lots of flashy widgets, content you’ll never have to maintain, and millions of visitors.”

Now let’s try out the word “iteration.”

“Our web team thinks that your web site is pretty good, but there are a few things that we think can be improved in a short amount of time. Let’s pick the top couple of items that will benefit the most members of your audience, and then we’ll revisit your site in the future.”

Doesn’t an iteration sound a lot more manageable and realistic than a redesign?

I’ve been reading a lot about Agile Software Development recently. At its core is the concept of repeatedly slicing projects (sashimi) into “increments of functionality” (see Schwaber and Beedle’s Agile Software Development with Scrum (2002)).

I’ll write more about Agile in future posts but for now, I’m busy. Our project queue is full of web site iterations.