We all agree that agile software development practices are a good thing. I presented here The Five Ingredients for True Agility in Software Development, so now here is my top things to avoid when you want to implement agility in your organization.
As I said, agility has a positive impact on companies, but there is danger lurking. We have to be careful not to use the agile springboard and jump head first into code construction. This applies to all projects, big and small.
The experienced carpenter considers the task three times, measures twice and cuts only once!
Agility is no pretext to completely forgo requirements gathering, planning and designing. The thinking phase needs to precede each iteration. Your urge to code could prevent you from exploring often overlooked but very powerful options at the initial stages…
Let’s Build a Dog House
Jack, your new dog, needs a house. So your partner asks you to build one and goes out for the day. Building a dog house is not that complicated: leftover materials, a few tools, and the job can be done quick and easy. The result; however, is not what was expected, as you find out when your partner checks out your day’s work.
You could choose to adopt an agile approach and consult with your partner every step of the way. When the day is done, the new dog house will be completed and everybody will be happy, including Jack.
The general belief is that waterfall projects are doomed to fail, while agile projects have a much greater chance of being successful.
Our new focus on agile processes can promote the notion that our ability to deliver is the end goal.
That’s where we may be misleading ourselves.
In software development, benchmarks for success should not be based on under-budget and on-time delivery. The real measure of success is a positive return on investment.
The Power of Simplicity and Compromise
Happy carpenters would probably be surprised to know the TCO (total cost of ownership) of the new dog house. From the cost of building materials to the tools, without forgetting the labor of ALL the people involved. Considering a $50 hourly rate, your dog house may very well cost you $750. At $50/hour, the dog house may very well end up costing $750!
That’s a sizeable investment. What’s the return on investment here? That’s the real question we need to ask.
Whether it’s for a dog house, a new application feature or a complex development project, I always start by asking:
- What if we just didn’t do it? Can our users live without it?
- If not, can we repurpose existing artefacts or buy some off-the-shelf components and achieve a baseline of capabilities?
How did we come up with the need for a dog house in the first place? The dog certainly didn’t ask for it. The house will certainly get some use once in a while. But Jack is never left outside at night. There is not an absolute need for it.
But what if you have a bigger dog that effectively spends a lot of time outside? Well, I’ve seen incredibly good looking dog houses on Walmart’s Web site for $150. Factor in the time to go and pick it up, and you’re looking at $200 vs our original $750.
Seems obvious ? Those decisions are still not the norms where some businesses stubbornly choose to develop everything in-house. They develop their own CRM, CMS, online store instead of paying a small monthly with a SaaS 100 times more powerful than what they will ever achieve.
Take It a Step Further
The biggest gain here is not that you saved some money. Rather, you could be doing something else of value with the time saved.
If there is effectively a need for a dog house and building the dog house is not really perceived as a great way to spend your time, what could you do instead? If you’re an entrepreneur, you could work on something your customers are waiting for and willing to pay. By buying the dog house you’re left with 7 available hours that you can use to build value and bill your clients for it. At the end of the day, you’ll have the dog house and $150 more in your bank account.
Let’s go back to our online store example. Instead of wasting months on building your own solution, why not be up and running as soon as possible with an existing solution so you can put all your efforts in selling your product? Isn’t that where you really create value?
Is any solution going to fit 100% of your needs? Probably not. But, it will satisfy 98% of them while being 10X cheaper and 100X quicker to set up.
Being agile should not distract us from the need to constantly ask about business needs and question the ROI. Moreover, we have a strong tendency to overdesign when most users of our solution would be content with a baseline of functionalities.
Agility is not the ability to do more or more complex software.
Keep it simple and be open to compromise. You’ll be more agile than ever!
Be the Revolution!