Agile Software Development

The adaptation mechanisms built into the Scrum process allow for many modifications and adjustments in the sprint planning procedure. Different variations work for different teams and environments. Here is one of the variations that I find useful:

Preconditions

Product backlog contains a set of user stories sufficient for at least 2-3 sprints, ideally - for the whole current release and more. The team together with the Product Owner and possibly with some stakeholders went through the top stories 2-3 days earlier. As a result for a sprint or two there are enough reasonably small and well understood top priority product backlog items.

Advertisement:

This Saturday I am leaving for the US-based course on Product Management. So I thought it could be a good idea to share my thoughts on the difference between the product management and the Agile Product Owner (Scrum) or Customer (XP) role.

Background

I come from software development. I was an engineer, system analyst, engineer again, senior engineer and chief engineer of the department for a decade. During last several years I was learning and practicing Agile and especially Scrum as a local consultant, evangelist, propagandist and Scrum Master. As permanent readers might remember earlier this year I moved to Product Management hoping to be able to help with the effective prioritization issues and Product Manager position seemed to be the easiest path for playing the Scrum Product Owner role. I indeed became a co-Product Owner for a development team. However, naturally I started spending some time on figuring out the "general Product Management" as well.

I think one of the best aspects of agile development is the ability for a team to frequently learn from their mistakes. It's especially crucial that this happens in a blame free environment. When something goes wrong during an iteration, it's important that no team member is singled out. The entire team accepts responsibility for their failures and successes together. And when a team makes mistakes, they need to learn from them. The key components for in a team's ability to learn from their mistakes are the attitude and interactions of the ScrumMaster.

There are a few things a ScrumMaster must do to help their teams learn from their mistakes. First and foremost, the ScrumMaster cannot be a fixer. When things are broken or not working the team, not the ScrumMaster, must figure out how to fix things. If the ScrumMaster continually steps in to fix the problem, the team never learns how to fix a problem for themselves. This leads back to the old command and control structure of more traditional development approaches. Instead of being a fixer, the ScrumMaster needs to be an enabler.

Bugs used to be something very distracting and unpleasant for the software developers. For management they can be even worth - the effort and time bugs need to be fixed is poorly estimatable. Sometimes these number are complete question marks. This predictability drop is one of the reasons why agile methods advocate striving for bug-free development as possible

Scrum teams don't like bugs just as any other teams. There are multiple approaches to handle bugs from entering into the product backlog and making them wait until the end of the sprint to allocating some "maintenance slots" in the sprint to a more-or-less expected amount of maintenance. The sad truth is in that amount of bugs discovered and amount of time needed to fix them is often not predictable even roughly. Especially for teams that are not yet used to deliver the tested features.

In this tutorial I demonstrate how you can manage your Scrum Product Backlog in a very simple Excel sheet based on a popular free template. Watch this screencast if you want to get started with Scrum. You will see how to get started, how to detail, inject and remove requirements, how to build burndown and velocity charts.

You can download the somewhat lower quality version of the tutorial from Google Video.

In light of the recent news about American Airline's maintenance problems, I sat down and talked with my Dad about aircraft maintenance. You see, my Dad was a maintenance Crew Chief for Pan American Airlines for nearly 30 years and I wanted to understand how things got so bad for American. My Dad explained the inner workings of Pan Am's maintenance program to me. The program dated back to late 1960's and early 1970's and was remarkably agile-sounding. Here's the program in a nutshell.

Scrum is an agile software development process with a high focus on the project management level. It has a concept of a sprint review in the end of the iterations, where the product backlog items taken into sprint (and possibly the whole sprint) are accepted or rejected. It is possible and even recommended to accept or pre-accept some items already during the iteration, but it is not mandatory and is not always possible.

During sprint review Product Owner indeed can reject the content, because the team got him wrong, perceived quality is low, some old features got broken or team simply did not have enough time to finish everything it was hoping to deliver. Then what does the rejection mean? Isn't it a bit too naive to expect the people disappointed by rejection deliver better during the next sprint? Isn't it easier just to add some "fix tasks" to the backlog?

Agile processes advocate not mixing promises with estimations. When doing any kind of promise an agile organization is better to base the promise on the historical performance and be explicit about the degree of confidence. That sounds quite a common sense, but how do you start a new project, if there is no team assigned yet?

Starting the project

The way of starting a project is naturally dependent of your organization realities and charter. Here is a way for starting the Scrum project that works for many organizations.

One of the mandatory artifacts of the Scrum process is a Product Backlog. In its simplest form it is just a flat list of things to do, quite often even without the complexity estimates. Its power comes from the strict order of elements. Customer can call many requirements equally mandatory or must-have, but in the list there is no way to position two items equally high. As a result a team is able to see the clear focus and sense the current expected direction of the project. Product backlog is not static. It changes over time: coarse grained items from the bottom are divided into smaller stories as team comes closer to them, some items are removed and some are added basing on the increased understanding of the area, technology and the market. Still, at any given point of time well maintained product backlog is the primary tool for communicating the current best understanding of the project direction.

Multiple backlogs for a team

Several times I've seen the situation, when there is no single product backlog for a team, but there are several "area backlogs" from which the top part of a real product backlog is dynamically assembled before or even during the sprint planning. Naturally it happens more often in the situations, when one team has to develop several projects simultaneously or many teams do many projects.

Last week while taking the Certified Scrum Product Owner course in Oslo I had a pleasure to have an interview with our trainer Mike Cohn, an author of Agile Estimating and Planning and User Stories Applied. Mike shared his point of view on the value of yet another certified Scrum Alliance course and provided advices for those going to become Scrum Product Owners.