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.

User Stories are a not mandatory, but very recommended part of Scrum and eXtreme Programming methods. Most of people acquainted with agile software development feel comfortable with the requirements written in the form of "As a [user role] I want to [goal], so that [reason]". Less people are acquainted with epics and themes usage.

Terms

Epics are just huge stories for capturing relatively low priority requirements that are often too complex to estimate right away and that are going to be detailed later. An epic for a car could be "As an environment conscious driver I want to be able to use both gas and hydrogene". A theme on the other hand is a set of stories grouped around some functional area, user group or anything else that makes sense for the product owner. Themes are often confused with epics, because quite often the epic is split down into exactly one theme. A theme for a car could be a set of stories grouped around the building the hydrogen engine.

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.

Many Finnish companies have a tradition of periodically selling the old stuff to its employees on the internal auctions. If you are lucky, you can get a decent computer, printer or fax for a couple of euros. Several years ago the company I was working for (CIM Wireless) has been bought by a bigger one. We were going to move to the new company premises and therefore had a particularly big auction where they were selling pretty much everything older, than a year. At that time I needed a new kettle and got one right from the company kitchen for as little as five or ten euros. I didn't put much thinking in, I just needed a new kettle - it didn't really matter which one.

When quality matters

It happened, however, that such a commodity as an electric kettle could be of so high quality that it makes you notice it. We didn't examine the device or measure its performance, but we couldn't miss such features as boiling water fast or ability to turn off automatically, when was empty. It might sound amazing, but we were actually surprised by the fact that it just worked very well. Plus it looked nice. We even recommended this model to a couple of friends - something you rarely do about kettles.

Pair programming is one of the most known Extreme Programming practices. In essence it means creating the code in pairs trying to get multiple perspectives on the code created. One of the participants, called driver, types the code and thinks about the low level details. Another one, called navigator, thinks about what the typed code is for. The participants periodically switch roles. The definition of "low level" depends on the skills of the concrete pair and their experience in the subject area. For example, when using test-driven development the driver might be focused on the writing the production code, while the navigator could be thinking about how the next unit test should look like in order to change the system architecture in the desired direction.

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.

Dear readers,

AgileSoftwareDevelopment.com just got a new permanent author - Jurgen Appelo.

Jurgen Appelo is Chief Information Officer at ISM eCompany, recently rated as the #1 fastest growing technology company in The Netherlands. He leads a horde of 50 software developers, development managers, project managers, consultants, quality assurance managers, service managers and kangaroos, some of which he hired accidentally.