High value at low cost.
There's nothing quite like finding a bargain.
That's why my colleagues and I bargain hunt when planning and developing software.
Many teams pay full price for features because they don't take time to shop for bargains.
They follow a popular process like this:
- Product Owner writes stories.
- Product Owner prioritizes stories.
- Developers estimate stories.
- Product Owner selects stories for a time box.
- Developers build stories.
Missing from this process is a step that says "now everyone collaborates to discover what is genuinely needed by users and how to deliver that functionality at low cost."
Bargain hunting requires:
- Collaboration: A diverse community of bargain hunters collaborates to understand user needs and consider trade-offs in delivering those needs at low cost. Having only one Product Owner authoritatively specify and prioritize features leads to high-priced development.
- Discovery: Sometimes you discover a bargain that wasn't exactly what you went looking for in the first place. The bargain appears and you realize it may in fact be better than what you originally sought. This doesn't tend to happen when you treat the prioritized backlog of stories as authoritative and definitive. Instead, if you treat each user story as a draft of an idea, you are open to changing your mind about that idea and potentially finding a bargain version of the idea.
- Evolution: If one-fourth of a whole feature satisfies users, then it is a bargain compared with developing the whole feature. Evolutionary design asks you to start primitive and add functionality as you learn from users. Too many teams jump immediately to building a whole feature instead of a fractional feature and learning how/if it needs to evolve.
- Creativity: High-value features don't have to cost a lot. There are many ways to implement a feature. A community that values bargains will creatively discover a low-priced way to deliver the feature. Our eLearning product once needed a security feature that was estimated to take about 3 weeks of work. Too expensive! After some creative brainstorming, we realized we could get 90% of the functionality with only 2 days of work.
- Savings: Experienced agile teams eventually optimize their sprint/iteration planning from a day or half-day down to 15-30 minutes. That's a great savings in time, yet such savings are lost when teams constantly develop high-priced features.
- Backtracking: If the implementation of a feature turns out to be much more work than was previously thought, it isn't a bargain at all. The team would do well to backtrack and renew its hunt for a genuine bargain.
Bargains Aren't Cheap Knock-Offs
A bargain is something valuable that you get at a discount.
It isn't something cheap and fragile that doesn't cost much.
Bargain hunting is a way to save time and money, not an excuse to cobble together inexpensive solutions into a bad design.
Like a cheap umbrella, a cheap design may work today but will likely fail tomorrow.
If you have to fix too many fragile designs, you are likely finding and developing cheap knock-offs, not genuine bargains.
Once we identify a bargain, my colleagues and I use test-driven development and refactoring to implement the work.
However, we also seek ways to minimize the amount of code we need to test-drive in the first place.
Recently, instead of test-driving some custom code, we found a third-party utility that could do 95% of the work for us.
We used that utility, test-drove the last 5% and then made sure the whole solution worked correctly.
When you run a small business (as I've been doing for 14 years now), you value being frugal.
The other day I found my daughter in her room, wearing shorts and a t-shirt, sitting in front of a mirror applying makeup and blasting a space heater.
Let's just say we had a little talk about wearing sweaters in winter and not wasting resources.
If the community of people you work with is frugal, they will actively seek bargains when planning and developing software.