It’s Not About the ‘How’. It’s About the ‘What’.

Software development experts, myself included, get caught up in methodology battles. I like Scrum. You like waterfall. My approach is more responsive than yours. Your approach is more disciplined than mine.

But, are we losing sight of ‘what’ really matters? The approaches we follow are the ‘how’ of building software systems. My goal (and I hope yours also) is to build better software so that our respective businesses can be successful. That’s the ‘what’ — build better software for our businesses.

If you and your team are not satisfied with the results you’re getting, you need to let go of the ‘how’ and focus on the ‘what’. In other words, if you’re unhappy with your team’s results, your approach isn’t working — so change it.

• What is wrong with the software you’re delivering?
• What makes it inferior to competitive products?
• What causes it to fall short of expectations?
• What issues are business users reporting?
• What internal goals are being missed?

Once you know ‘what’ is going wrong, you can turn your attention to the development approach to understand ‘how’ these issues came to be. You may need a completely different approach or some changes to your existing one but, either way, something needs to change.

Arguing about Scrum vs. XP vs. standard waterfall vs. iterative waterfall is a semantic debate. Instead, identify the tactics within your current process that work and those that don’t. Preserve the tactics that work and eliminate the ones that don’t.

• Don’t treat anything as sacred and unchangeable.
• Don’t start changing things simply because they’re easy.
• Don’t draw conclusions without hard data to back them up.

Here’s an example of a really bad ‘improvement’ idea. (I’ve witnessed this several times over the years.) A software system is widely perceived as buggy. It’s hard to use; it crashes; etc. The proposed solution is to do more testing. If you can identify more bugs before the software ships, you’re ahead, right?

– Wrong! –

If the software is buggy, there’s a fundamental problem with your team’s approach to specifying, building and testing it. Your entire process from front to back is suspect. That elephant is too big to eat in one sitting.

Accept that the software will be buggy for a while. You can make incremental improvements but you won’t be able to fix everything in a release or two.

Get to the core issues and fix them. Until you’re willing and ready to do so, a new software development approach won’t help, whether it’s agile or not.

photo credit: dhaun via photopin cc