Delivering Business Value
Garrett Smith has posted some thoughts on appropriateness of Agile techniques and being careful about attempting to implement some practice just because “it is Agile”. It comes down to delivering business value. Just because something is “Agile” doesn’t mean it is good for the context the project is being run in.
Garret says:
Just because the team is pair programming, adaptively planning, and driving development with tests does not mean it will achieve the business goal. If the team is programming solo and doing big up front design it does not mean the team will fail.
Couldn’t have said it better myself and there are 100s (1000s?) of cases of both an Agile team failing and a non-Agile team succeeding.
Garrett also says:
I advocate Agile practices; they are generally a better way to get software written.
I like this. In his experience, Garrett has come to believe that Agile practices are generally a better way and so he advocates them. There is absolutely nothing wrong with this. He would be negligent if he didn’t advocate what he has generally had success with.
However, Garrett’s advocacy is tempered with an insight that few possess. The insight is that not everything he has had success with in the past will be successful in the future. Things change and people change. Instead we should be focusing on delivering business value. If the tools/practices you have experience with achieve the business goals then by all means, keep doing them. But, and here is the hard part, if they _don’t_ achieve the business goals or don’t fit in with the context you are in at _this_ point in time, then you must look around at what other people have done to achieve their business goals in order to figure out what will work in your context. You must try to find something that delivers the business value in the context you are in. Sticking to something that doesn’t work and not attempting to find something that works better is negligent at best.
on November 1st, 2006 at 9:35 am
I notice your blog uses the phrase “Silver Bullet” a lot (not in particular entry, though), and I thought you might find interesting what Fred Brooks actually wrote in his landmark article “No Silver Bullet: Essence and Accidents of Software Engineering”.
http://homepage.mac.com/keithray/blog/2006/10/23#NoSilverBullet
I think “Lean+Agile” is a good combination, since Lean works on the whole system from product idea to the sale of a product to the customer. (But maybe not enough on marketing and sales?)
Various Agile methods don’t focus on the whole business - and rightly so. They state clearly up-front that they are about developing software, and that business decisions, including marketing and sales, are up to the business experts to deal with.
The core of Agile - frequent humane feedback and adaptation with a focus on delivering business value - is useful outside of the software development process, but whether that works depends on what values are held most dear by the business leaders and owners.
on November 1st, 2006 at 10:58 am
From Brooks:
Agile is not it. No process in and of itself is it. _People_ lower software costs (or increase software revenue, whichever way you want to look at it). Processes can’t guarantee anything, let alone getting software costs dropping as rapidly as hardware costs. I’m not arguing that _some_ organizations who adopt Agile can’t lower costs. I’m just saying not _all_ organizations who adopt Agile are guaranteed to slay the software cost werewolf.