Big thanks to the 119 of you who deigned to answer to the Cranky Product Manager’s lil’ Facebook poll on software development methodologies. The poll is now closed.
While this is hardly a scientific poll, the results show a HUGE change in software development methodologies between now (2008) and two years ago (2006).
Software Product Development Methdologies: 2008 vs 2006
- In 2006, you reported that a sizable majority of product development used a waterfall methodology (55%), with Scrum garnering a mere 7%.
- In 2008, the picture is very different. Scrum and its Agile cousins account for nearly 60%, where waterfall has dropped to a mere 28%.
- The percentage of products using waterfall dropped by 50% in just two years! (from 55% in 2006 to 28% in 2008.)
- Scrum increased by 410% (!), and is now definitely the most popular flavor of Agile.
Wow. What a difference in just two years.,
Poll Conclusions
The CPM sees the writing on the wall. She’s now on a mission to learn all she can about Agile/Scrum in order to stay employable. But geez, there’s got to be something better out there than that canonical (naive) Scrum book. Something that reflects the realities of developing software PRODUCTS for multiple customers, not doing custom one-off developing projects. Please, say there is.
Nonetheless, the CPM thinks we are approaching Agile’s “Peak of Inflated Expectations,” soon to be followed by the “Trough of Disillusionment” (to borrow phraseology from the much-despised Gardeners), as people realize Agile still has flaws and is no Silver Bullet. Plus, Agile’s flaws aside, waterfall is not going away completely as there are too many products that CANNOT be developed via Agile (hardware, medical, defense, heavily regulated industries, products with very spread-out or outsourced development teams, to name a few).
Detailed Results
119 people responded to this Facebook poll, run between September 12 and October 1. Bare in mind that the readers of this blog are hardly representative of the entire software industry, and that the ones that use Facebook might be even less representative. Nonetheless, the results are very telling.
Question 1: Is your product currently being developed with one of the following software methodologies?
Reported Software Product Development Methodologies in 2008
Question 2: Two years ago, what methodology was used for the product from Question 1?
Reported Software Product Development Methodologies two years ago, in 2006
{ 8 comments… read them below or add one }
Something that might be more insightful is the size of the development team and see if there is a shift.
I think the poll results are very seriously skewed. The people who vote are 1. reading the blog, 2. on facebook. I think it just so happens that the vast majority of folks practicing waterfall are not on facebook, and do not read this blog (I’d bet that the sizable portion of them might not even be sure what a blog is)
There is a definite need for that. But help is on the way.
I know of at least one book on agile product management under contract and being written right now. I’m talking with a publisher about co-authoring a book on how agile teams do user experience, interaction, and interface design. And at a conference earlier this week, I saw somebody give a fantastic presentation on managing product portfolios in agile organizations; she is thinking seriously about a book.
If people have any suggestions about what they’d like to see in books like that, let me know and I’ll pass ‘em on. My email address is my first name at the domain name linked to.
And for what it’s worth, there are definitely people doing interesting agile work with hardware and medical products, and also using distributed teams, so saying “CANNOT” is a little strong.
Max, The Cranky Product Manager agrees. The poll results are no doubt skewed because the CPM blog readership is not exactly representative of the software product universe as a whole. So, true, waterfall is probably around on >28% of projects today. But she still thinks you can’t deny the SHIFT to agile from waterfall in general.
I’ve used Agile on large, distributed software development project in the Healthcare space and it does work. What you have to realize is that Scrum isn’t an Agile program management metholdology. You need to develop/copy/steal that from someone. You also need to realize that Scrum is a framework. I’ve seen numerous examples of people trying to follow perceived “rules” when they make no sense in their environment (common sense isn’t all that common). One of the more powerful aspects of Agile is that it puts much more focus on the underlying behaviours than other methodologies. This, itself, can have a major impact.
Agile is on the march, but there’s still plenty of room for growth. If the questions we get at Forrester are any indication, there are plenty of organizations still pondering whether Agile is for them.
As for book recommendations, what are you looking for? A general guide to Agile? Something more specific to a particular method, or a particular scenario (Agile and SOA, managing Agile groups, etc.)?
I’m the Product Manager of a small team doing a modified version of Scrum/XP. It’s been my experience that while many of the practices work in spirit (small increments, constant grooming, frequent feedback loops, information radiators, etc) trying to cling to a rigid set of practices is a recipe for team troubles.
I totally agree with John above, focusing on behaviors rather than methodologies has been a much more fruitful exercise.
One of the roadblocks to understanding how to apply agile development is that most people refer to it as a methodology. It’s not a methodology. It’s a perspective, a frame of mind if you will. It’s really a shame that so many people adhering to agile and jumping on the bandwagon of agile are so rigid about its implementation because the beauty of it is how flexible it is.
In fact, FDA is currently reviewing allowances for reducing the amount of documentation that has to be submitted for agile projects, and the DoD is moving toward a more performance-oriented release process over the millions of dollars in waste that comes out of the Pentagon every year (based largely on the success the FBI had with implementing agile processes after the collosal failure of their records replacement project. http://www.cio.com/article/714333/How_the_FBI_Proves_Agile_Works_for_Government_Agencies
I’ve worked in companies where waterfall was the method, and in my personal experience, having worked in agile environments off and on since 1996, flexibility and customer focus has met with greater success in getting software released, software that meets what the customer wanted, than waterfall.
I don’t want to badmouth any methodolgy because Waterfall works when implemented properly, but as with everything else in life things are rarely implemented properly, even agile development. Thing is, agile allows for constant customer feedback (if you can get them involved at that level). Waterfall could, too, but I don’t think anyone’s ever thought to try that.
I’m pretty sure that all those nasty replies you’ve received from agile zealots are like zealots in all walks of life. When you only partially understand something, the reaction to counterpoints is a lot more knee jerk and emotional. You see it in religion and politics as well. The most level-headed and soft spoken are the people whose understanding is deep, faith so rooted, that they aren’t threatened by the opinions of another person, so they can discuss important topics with a cool head and a gentle voice.
Software, it appears, is the same way. Maybe the new “two things you can’t discuess in polite company” will become the triumverate of religion, politics, and software development.
{ 2 trackbacks }