10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Interview with Linda Rising by Amr Elssamadisy on Oct 27, 2009 Length 00:15:00 Download: MP3
Case Study: IBM's Agile Transformation
SCM best practices for multiple processes, releases & distributed teams
Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.
I've blogged on the similarities between medical science and software development before. Unfortunately, the area where I think the medical community are ahead of us is how they measure the effectiveness (or otherwise) of a treatment against the placebo effect. Merely effecting a change, with the stated intent of it being for the better, in order to invoke the placebo effect should have positive results for the reasons Linda mentions, but the criteria for whether a process change is really worth having is whether it beats the placebo effect.
This comment is in danger of over-running, so I'll put the rest as an entry on my blog. I'll leave with a parting shot of if you were to read just one book on the placebo effect and how medicine tries to work out whether they are better, make it Ben Goldacre's Bad Science.
I agree with Martin. Agile needs more science to back up its claims, not the 'old time religion' that appears to proliferate. In particular, we need to know what works and what doesn't in the Agile world. For instance, how much payback can you expect from TDD? Right now, it's anybody's guess.
I think there's at least a little good news on that front, Craig. I think it was even featured on this site a little while back, but Microsoft have tried to measure the effectiveness of TDD and have published their findings in a paper called Realizing quality improvement through test driven development: results and experiences of four industrial teams.
So Craig, when you say more science, I'm assuming you mean something like experiments, modeling, and proofs - right?
How do we suggest we do that?
I am believer of Placebo and Agile. It simply works. It is very interesting interview. My one question is if we have already believed something works should we be asking questions like "Does it work better than something else?" :)
I recently attended the Stack overflow conference Dev Days, in Toronto. There was a great speaker named Greg Wilson. He is a professor at the University of Toronto and he is doing research on how to actually bring some science into our methods. He showed some great examples of experiments already done, and he is pushing for more rigorous experimentation and a more evidence based software engineering system than we have now. I suggest seriously googling him and checking him out.
The slides are here: www.slideshare.net/gvwilson/bits-of-evidence-23...
and the full conference info is here: meta.stackoverflow.com/questions/27151/devdays-...
It's an interesting perspective (like earlier ones with bonobos etc) but this time I failed to see the direct connection. Considering placebo as something pseudo cure real cure, which part of agile is pseudo? or whole of it? Didn't waterfall give the same placebos - or (false) beliefs? Curious here.
P.S - blogged about it very briefly @ subabo.wordpress.com
/suba
The thing about placebos is that they WORK. Agile is working and delivering better software.
I'll be the oddball out here. Does it matter if the solution is because of belief or because of action? If the result is positive, that's all I personally care about :)
Blimey Amr, I'm glad you're not my doctor :)
The essence of the argument is that we can make any old change, even if it's something as silly as making the room brighter, and see some improvement due to the placebo effect. So, if we are relying purely on placebo for our benefit we may as well make changes that are incredibly cheap and easy to implement. Introducing agile processes aren't incredibly cheap so, if they're no better than placebo, we may as well ignore agile and just turn more lights on!
Amr,
I'm talking about measuring ROI over the lifetime of the software. The research by Nachi Nagappan noted by Martin is a good start. We have many software projects that have a limited lifetime (2-3 years). TDD lowers support cost, but does the payoff justify the 15-35% percent addition to development time that Nagappan found? Both the cost (TDD) and payoff (defect-reduction) needs to be quantified in dollars and cents (or euros, etc).
Martin - I'm not so sure that we can write off the effects of Agile as a placebo. First of all its very difficult to design real experiments around a group of humans and their interactions. Who would be willing to design and fund the following test:
-Team A will build the application using their traditional approach
-Team B will use an Agile approach to build the same application
Neither the teams nor their customers will be allowed to communicate during the development of the application. Run for 6-12 mths and study the products for quality, value delivered, ....
Repeat several times over. Will you fund this effort?
I think the best we will get for sometime to come is the Standish reports - look for the top 10 list of factors in predicting project success - Agile tends to expect all of them.
Cheers
Mark Levison
The Agile Consortium
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.
11 comments
Watch Thread Reply