mikkeman.nl

Are you starting with Scrum? That’s good news!

• You have a Team: check.
• You have a Product Owner: double check.
• You have a Product Backlog:  …. right?

Product Backlog? Yeah, we have a list with things we could work on, and when (if?) we finish it, we’re done. But is that a Product Backlog?

The minimum viable product backlog (yes, I got inspired) is not just “all items we came up with that we could work on”. It is a filled, estimated and prioritized list of work items. There are three key points in this statement.

The backlog is filled

This means it should at least contain enough work items to fill the first sprint and include an extra work item to expand the product backlog. Most projects start out with a backlog with high level items for the entire system (that may be a dozen to a hundred or more).

The backlog is estimated

The team must have enough information to estimate the items on the backlog. The Product Owner should be able to explain the items, the team should be able to give them a relative size (using planning poker, for example).

The backlog is prioritized

The Product Owner should have a clear vision on the entire product (think big), but also on what to build first (act small). Not always easy. The book says “pick the story with the most business value” but that doesn’t make it easier for most Product Owners.

A useful technique in this respect is a story map. The story map works top-down from the high level work items. These high level work items are typically things a system MUST support in some way or another. It’s just the sophisticatedness of the solution that determines the size of a work item. When Product Owner and Team together work out the least sophisticated solution to all high level items, we have what we call the walking skeleton, or minimum viable product.

Building the walking skeleton is a very useful prioritization, because it proves the (functional and technical) feasibility of the product.

Why this post?

Too often teams “rush” into Scrum to find out after a few sprints that the product backlog requires major maintenance. This might cost more capacity than one would like, possibly affecting velocity and the sustainable pace of the team. To prevent it, make sure you have a minimum viable product backlog from the start, and make sure it remains viable throughout all development activities.

Some people like to compress these activities in a few days, other like it to extend it to an entire sprint (to get used to the rhythm). Some people like to call this preparation “sprint zero”, others argue that it might as well be the first sprint. I don’t care how you call it, just make sure you do the activities associated with a controlled start.

Image taken from yoppy’s Flickr stream under Creative Commons license.

“Better is worse than good enough” (or the Dutch equivalent “Beter is slechter dan goed genoeg”) has been my tagline for quite some time. I put it below emails, use it on this blog and anywhere else where it seems applicable. BTW, I don’t deserve the credits, I first heard this quote from professor emeritus Nielen (not sure if he is the authentic source either).

Many people are confused when they read it and ask me what it means. How can better be worse? Better is better, right? And certainly better than good enough, right? Wrong.

The statement reflects pragmatism. Simplicity. Or, as Einstein put it: “Any fool can make things bigger, more complex, and more violent. It takes a touch of genius -and a lot of courage- to move in the opposite direction.”

It feels counter intuitive. We always want to make things better. But think of this: a better solution might be, uhm…, better, but it has at least three major disadvantages:

1. It takes more time to make things better – we don’t have this time
2. It costs more money to make things better – we don’t have the money
3. It has a higher probability on errors – which cost time and money to fix

In software development, we tend to “gold plate” solutions and include all kinds of bells and whistles that will “certainly blow away our customer”. Will this customer really be delighted by those bells and whistles if it means that his project is over budget and too late?

The trick is to hit the sweet spot between “too little” and “too much”. The only way to know that spot is to get frequent feedback -early and often- from your customer. This is one of the core principles of agile software development: close collaboration between development and customers. Scrum implements this principle with the Product Owner role, collaborating closely with the team, delivering software in short Sprints, ending with a Sprint Review of working software.

Now you know what I mean with “better is worse than good enough”. Try it for yourself!

Photo taken from wallyg under Creative Commons license.

Traditionally, software teams are allowed to develop software in a large timeframe. They can read the entire list of features at the beginning of the project. They then usually start designing and developing a generic framework to support all those features. It is not uncommon that developing the generic framework takes more than half of the total project time. The justification is that “once we have the framework, slapping on the features is dead simple”.

As soon as they start “slapping on features”, it turns out to go slower than initially thought.

And as soon as the customer gets a sneak preview of his product, the changes keep coming, which leads to inevitable changes to the generic framework.

Damn.

One of the key concepts in lean/agile software development is to develop software in small, usable pieces. Scrum calls this “potentially shippable”, meaning that a customer may decide to deploy a piece of software and monetize its value. Obviously, such a small piece of software can’t contain all the features the customer ever dreamt of.

But because the customer didn’t ask those features now, doesn’t mean he won’t ask them in the future. Some of those features are even very likely to be implemented in the future! What to do now? Should you build those features anyway? Or maybe partially, just to make it easier to implement them fully in the future? How can we make a generic framework for all features if we are only allowed to build a few? How can we make a generic framework if we don’t know all the features anyway?

The answer is: you can’t.

This is a difficult paradigm shift for teams starting out with lean and agile. Just make the features the customer asked for in this small piece. No more, no less. Experience taught us an important lesson: once you start delivering pieces to your customer, the list of features changes. And keeps changing. Until the end of the project, and even after that. The solution is to make your solutions adaptable.

Adaptable is not the same as generic, although I have met quite a few developers that use these terms interchangeably. Generic means “applicable to all specific situations”, a one-size-fits-all solution. Adaptable means “able to adapt to a certain situation”. Those things are related, but not the same. I have seen too many “generic solutions” that weren’t generic enough to support a new feature (“gosh, we didn’t think of that”). And they weren’t quickly adaptable, because they were designed to be… generic, right? It is not necessary to change a generic solution, so adaptability has never been a design criterion.

On the other hand, if you have an adaptable solution, you just… adapt it to support a new feature. Think about it for a while. It doesn’t matter when you didn’t think of a new feature upfront, because you designed the software to be adaptable in the first place.

Next time when you’re working on a new design, make sure it’s adaptable, not generic. You’ll do your customer (and yourself!) a big favor.