Ever since my college days (many months ago!) there has been a “situation” concerning IT and the business. Despite a plethora of new methods, technologies, software, and business-focused efforts, the valley of communication between IT and the business remains. Sure, there has been progress – business analysts, project management, agile development, Kanban and others have brought the customer to the table (so to speak) with software developers, but the gap remains.
Just today, a colleague in the Kanban / Lean development space remarked on Twitter:
It seems that the more that things change, the more they stay the same… and it is frustrating. There is so much work to do in terms of communication, education, soft skills to bridge this gap.
So WTP* of methodology battles?
Really, WTP (What’s The Point) of methodology battles in software development? I see it all the time in cyberspace and at conferences:
- Function points (and flavors within) versus lines-of-code versus story points versus use case points;
- CMMI® versus SPICE (a European framework);
- PMI (Project Management Institute) certification versus IPMA (International Project Management Association) versus Prince 2;
- Kanban versus Agile versus Scrum versus Waterfall?
Perhaps it is human nature to pick battles we think we can win (as opposed to looking at the overall bigger challenge of the business / IT dysfunction), but What’s the Point?
When you come down to it, a Win/Lose result in software development (along the lines of schoolyard “My mother is smarter than your mother”) ends up being a Lose/Lose for everyone involved. Emotions flare, tempers rise, and time is wasted. In addition, when you consider the bystanders (other professionals and executives) watching these methodology “catfights”, it’s no wonder many of them step back and retrench without a second thought about ways forward.
Case in point – the function point wars fueled by assertions of “my way (of counting) is better than yours” or “ours is a 2nd generation method while yours sucks” is a pitiful battle proposition when one considers that a mere 10% of organizations measure any software development at all. Yet the battles go on fueled by notions of superiority and self-congratulation. (It is no wonder why some organizations forego function points altogether.)
I see the same battles brewing in the Kanban, Lean, Agile, RAD and Waterfall communities. While each approach offers its own advantages and strong points, none is a panacea and in fact, a diversified team of qualified practitioners can often blend practices to increase output and quality. When allowed to co-exist in relative harmony (with the goal to deliver better software, reduce rework, and delight customers) – the results could be stellar. But, we’re not there yet. I can imagine that when the power nailgun was introduced into construction, it probably faced the same resistance as modern methods have in software development. Of course, since human beings and professional credibility is involved in both industries – opinions emerge about the best way forward.
No matter which “camp” or area you adhere to in software development, there is no silver bullet or Swiss Army Knife. We have to learn to lay down our petty differences and work together for the betterment of our customers – and over time, maybe our customers will take notice that we are collaborating for them.
If you agree with the notion of collaborating and learning about how professionals are integrating these various approaches (and others) together, be sure to attend LSSC11 (sponsored by the Lean Software and Systems Consortium) being held May 3-6, 2011 in Long Beach, CA.
I can promise you’ll see Kanbaners, Agilistas, Scrumbies, Sigmalites, and even a few Waterfallers working the space networking, sharing, and gently sparring (in jest) – all for the advancement of our industry. Why not plan to join us?