Byoooo!! You need the power to shrink (your app) because it will solve two problems I bet you have. One is that your team is not happy about what they see as “re-working” features they just created. The other problem is your stakeholders/customers probably ask for enhancements and you can see in your usage logs that similar features already in production are not being used.

Let me elaborate…

Problem 1 – Is it Re-Work or Learning?
When you’re first building out a system or set of features, I’m sure you prepare your backlog as best you can right? That means meeting with stakeholders and really understanding what they are hoping to accomplish. Then you help them envision what the product will look like based on those needs and formulate a draft backlog of stories (and story map if you are really on top of things). This makes you happy.

Then you have your first sprint or two and show the results to your stakeholders. They love it. Great! …except can you make this view show by currency instead of country? And can you let them group all the companies up into industry groups instead of industries? And can I have onion rings instead of fries? As a good agile product owner you know this is the right outcome because you have LEARNED from previous work and now have the chance to make it better for your users.

So then why do you get the evil eye from your team when you bring these new stories into the next planning session? I think it’s because in the times before agile, this kind of “re-work” was bad. It meant you didn’t finish your analysis or you got the requirements wrong. The thing is, even in waterfall you would have developed these same features, but you never would have gotten early feedback and the users would ultimately have had to live with their initial (sub-optimal) decision. The core problem here is that people (including you and me) are poor predictors of what elements of an application will succeed and what elements will fail.

Problem 2 – Simplicity vs. Bloat
Let’s say your application is now 12 months old. You have managed the backlog well which means that, all things being equal, you are working on lower priority features now. If you don’t have a ‘less is more’ attitude, you might begin to implement all the random nice-to-have stories your stakeholders brainstormed at the beginning of the project.

Hopefully, you can see this coming though and talk to your users about discarding these ideas – or trying a very rough version of them to see if they provide value. And if you are really feeling courageous (and have some usage metrics to back you up), try talking with users about eliminating features entirely. It is counter-intuitive but you may be adding value because you are increasing SIMPLICITY and ease of use.

There is actually a lot of controversy out there about whether you should try to be simple and meet basic needs well (e.g. Apple), or whether you should load as many features into your application as possible (e.g. Microsoft). I am in the first camp (but see here if you want to read a rant about the ‘more is better’ perspective). Interestingly, both camps agree that the majority of features in many applications are rarely used — I have seen statistics ranging from 5% to 30% of features being frequently used, but even 30% is pretty darn low.

A Solution to Both
To help me communicate about this to others on my team (and now you), I created a little illustration below encapsulating the agile version of “less is more” (click to enlarge…in case you have never been on the internets before). It essentially says this: developing 100 features without re-work feels like you did more than building 75 features with re-work UNTIL you realize that in the first (non-iterative) scenario only 30 features will be used AT MOST and in the second scenario 60 will be used. The jury is still out on whether you can get that kind of bump just from an iterative process, but I can say anecdotally that we have made several mid-course corrections to our systems that lead to much greater user satisfaction and use.

As Jeff Patton said (and I paraphrase), “Our goal is to get the job done with the least amount of development.” This was a bit of a revelation to me – historically our efforts to develop applications inevitably became a game of adding every requested feature…and then struggling not to be crushed by the burden of bugs and production support that came from these overly complex systems.

I think there are big implications here and would love to hear your views on thinking small.