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.
Leave a comment
- May 2013 (10)
- April 2013 (13)
- March 2013 (13)
- February 2013 (12)
- January 2013 (12)
- December 2012 (7)
- November 2012 (11)
- October 2012 (12)
- September 2012 (8)
- August 2012 (11)
- July 2012 (13)
- June 2012 (12)
- May 2012 (13)
- April 2012 (13)
- March 2012 (13)
- February 2012 (12)
- January 2012 (13)
- December 2011 (12)
- November 2011 (12)
- October 2011 (13)
- September 2011 (14)
- August 2011 (18)
- July 2011 (13)
- June 2011 (18)
- May 2011 (19)
- April 2011 (16)
- March 2011 (21)
- February 2011 (20)
- January 2011 (22)
- December 2010 (21)
- November 2010 (16)
- July 2010 (2)