…to your Brother-in-Law.
A great article by Joe Little, on his new blog. Thanks Mishkin for telling us about it.
Joe’s article serves as an excellent precursor to our comparison of agile software development methodologies.
It would also be extremely effective advice for getting mindshare prior to rolling out agile in your organization. In fact, we should add “mistake #11” to that list: Roll out agile without explaining what agile is.
Why should you read Joe’s article? Here’s a quote:
What are the benefits?
The benefits can be stated many ways, but usually amount to these things:
- Faster time to market
- More business value delivered per period
- More accurate delivery of business value (the customer gets what they really need)
- More transparency for the business (the business can see where their investment is going, and how they can help remove impediments)
- More satisfied customers and shareholders
- More satisfied workers
My general rule of thumb is that in 2 years a team should be 4x as productive as before Agile.
Any value in a 4x productivity improvement for your team?
Check it out, and we’re all looking forward to more from Joe!
Do you have anything that proves the benefits? Sounds like a lot of un-proven hype by Agile people to me.
Thanks Stewart for reading and commenting. Your question is a good one – many authors don’t provide data that “proves” their positions. I don’t know that I can “prove” mine, but I will attempt to bolster them.
Will my personal anecdotal experience qualify as proof? What if enough people comment on this article with their anecdotal data?
I’ve seen over a million dollar software development budgets spent in waterfall projects (plural) for enterprise software that were never deployed because they got so far off track with the (admittedly moving targets) of customer requirements. I was a dev lead on one of those projects (my first dev lead role).
I’ve also lead a team through a very successful iterative project – releasing every three weeks, using continuous integration – with a single exception, every nightly build of the trunk was bug free and we leveraged that twice to deliver unscheduled releases.
I’ve been on projects that rolled out initial, valuable functionality that immediately began generating a return for the customer. Those projects also gained momentum through delivery that helped them stay funded and visible throughout their development cycles.
I’ve helped clients with “broken” processes reduce maintenance costs and simultaneously improve quality and reduce feature-release cycle times by introducing continuous integration, automated build and test procedures and habitual refactoring into their dev cycle.
The most successful projects I’ve personally worked on, lead, or been aware of have universally applied elements of agile processes. The most spectacular failures have all been waterfall processes with manual build cycles and quality procedures that lacked rigor.
I don’t believe you can isolate enough variables to create “scientific proof” that it works. Even if you have the same team implement the same software with multiple methods, those people will learn something the first time, making the second attempt better than the first. And if you have teams simultaneously create software to address identical needs you can not factor out the team-member skills as a variable.
Other folks want to chime in?