The biggest waste in software development

Posted on March 26th, 2010 in Agile by siddharta || 12 Comments

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.

Unwanted features are a big wasteWe 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.

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

12 Responses to “The biggest waste in software development”

  1. Ted Says:

    I like this blog post. But I’m not sure you’re practicing that toward your product:

  2. siddharta Says:

    Hi Ted,

    I’m assuming you feel that the feature list is too big :) The right feature set depends on the target market. I’m not saying that you should not have a lot of features – just features that no one wants. If you have a market for each of the features, then there is no problem there.

    Having said that, we do sometimes fall into this trap too, which is why I wrote the post :)

  3. Guru Says:

    Cool … I need to show this to my management.

  4. Peter Zalman Says:

    couldn’t agree more…

  5. Looking for the MVP | intruthitsnotthatsimple Says:

    […] actually be what people want to buy (and here’s a strong argument against building such products:  Of course, in order to be viable a product also needs a defined market of eager buyers but […]

  6. – Looking for the MVP Says:

    […] actually be what people want to buy (and here’s a strong argument against building such products:  Of course, in order to be viable a product also needs a defined market of eager buyers but […]

  7. Kassie Says:

    Well done ariclte that. I’ll make sure to use it wisely.

  8. coc hack for pc bluestacks Says:

    Is that really all there is to it because that’d be flabbergasting.

  9. Says:

    he was often smiling whenever she looked his way. I immediately said, “I think I know who you mean. I was doing the same thing, focusing on him.” Becky pointed to him in a crowd later, and it was indeed the same person. Becky talked to him later and learned that his name was Mark G. Harris. Funny, that’s how I remember him from that year as well. Are we responsible for turning him surly?

  10. Says:

    There’s a secret about your post. ICTYBTIHTKY

  11. fifa 14 1 million coins free Says:

    I agree Dianne. It was not something I have given much thought to (high school librarian) but your challenging, objective arguments confront this issue with real depth. Well done, great post.

  12. burberry scarf Says:

    This actually answered my problem, thanks!

Leave a Reply