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.
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.
March 26th, 2010 at 8:23 pm
I like this blog post. But I’m not sure you’re practicing that toward your product: http://toolsforagile.com/details/
March 26th, 2010 at 8:40 pm
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
March 29th, 2010 at 5:21 am
Cool … I need to show this to my management.
March 29th, 2010 at 1:03 pm
couldn’t agree more…
July 15th, 2013 at 5:45 pm
[…] actually be what people want to buy (and here’s a strong argument against building such products: http://toolsforagile.com/blog/archives/260). Of course, in order to be viable a product also needs a defined market of eager buyers but […]
April 21st, 2014 at 5:11 pm
[…] actually be what people want to buy (and here’s a strong argument against building such products:http://toolsforagile.com/blog/archives/260). Of course, in order to be viable a product also needs a defined market of eager buyers but […]
January 2nd, 2017 at 8:44 pm
Well done ariclte that. I’ll make sure to use it wisely.
February 14th, 2017 at 8:42 pm
Is that really all there is to it because that’d be flabbergasting.
February 26th, 2017 at 9:46 pm
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?
March 27th, 2017 at 7:02 pm
There’s a secret about your post. ICTYBTIHTKY
April 8th, 2017 at 4:08 pm
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.
August 29th, 2017 at 3:00 am
This actually answered my problem, thanks!