Tools For Agile Blog

Quick. What’s the biggest waste in software development? Defects? Rework? Documentation? Work in progress? Communication? Coordination?

Those are all big wastes for sure. But the biggest waste is building features that nobody wants.

We can put up with rework and defects if we at least get something useful at the end of the day. The problem with unwanted features is that you not only incur all the other wastes, but you end up developing nothing useful. Worse, you could have the best delivery process in the planet, and it still won’t save you from incurring this waste.

Here is the catch though – how do we know that we are building a useless feature? It’s not like we intentionally want to build unwanted features, right?

Does it fit in with the product vision?

Often times we look at a product and think “wouldn’t it be cool if…” or “if only we had this one feature…” When you get these thoughts, stop for a while and think it through. These one-off features often don’t fit in with the product vision and the target user group. Sometimes they could be good ideas but more often than not, they don’t have enough unity with the rest of the product.

Another way this problem can manifest itself is when the sales or marketing group comes in and asks for a single feature. “Just add this feature and the customer is ours”. The problem is that each customer might want a different feature.

Building a feature that nobody wants is the biggest waste. Whats the second biggest waste? Building a feature that only one person wants!

Eventually the software loses its coherence. By trying to do everything for everybody, it ends up doing nothing for anybody.

Deploy and observe

Sometimes you aren’t sure. A feature could be a good idea. How do you find out? Deploy and observe.

A question – How often do you deploy to end users? No, I don’t mean “potentially releasable”. I don’t mean showing a demo. I mean actually releasing it so that end users can use it in day to day work.

Many agile teams build increments of software without releasing it to end users.

Spint 1 – build increment. Sprint 2 – build increment. Sprint 3 – build increment.

At all times, the software is “potentially releasable”. But you won’t get feedback if it does not get into the hands of the end users. This leaves you open to the risk of building the wrong thing.

Deploying the software is important. Thats step one.

Step two is to observe.

Are you getting feedback about it? Getting good feedback is nice. It means people are using the feature. Getting bad feedback is nice. It also means people are using the feature. Getting no feedback is where you need to investigate further. It could be that the feature is satisfactory, or it could mean that no one is using it.

Another way to observe is to build in some metrics to count how often a feature is used. This is a method popularised by Eric Ries. A lot of Eric’s work is about building the things that customer want. I really recommend reading some of his stuff.

But we are a service company

Service companies are in an awkward situation here. From their point of view, useless features are a good thing, because they get paid to develop the feature. Who cares if it’s useful or not. The customer asked for it, they are willing to pay, so lets develop the feature and collect the cash!

In this case, the burden for managing the feature list lies with the customer. If you are getting software developed by someone else, then ensure that you are getting the software deployed often and you are collecting feedback or checking metrics on usage.

Agile teams need to take responsibility for this

One failing with agile teams (by team, I mean everyone who is involved with the software, not just the dev team) occurs when they absolve themselves of responsibility in delivering the right product and place the entire burden on the customer (or PO). In this mode of operating, the customer dictates the features to build, and the team builds it. Built the wrong thing? Well that’s what the customer asked to build. If the project fails, its the customers fault –  we just built whatever they asked for.

The agile team is supposed to be the expert in the delivery process. They cannot push this burden to the customer. They should take on the responsibility for building the right software and incorporate the practices necessary for making it happen.