The No Business Case Myth
The No Business Case Myth
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
Once in a while I run across individuals, or even teams, who still think Agile is about just getting on and doing it. Well it is, good for them, but, that doesn’t mean there isn’t a reason for doing it.
There seems to be a myth in some circles that work done using Agile techniques doesn’t require a business case. Lets get this clear: Agile does not excuse you from having a business case for your work.
Of course there are instances were a business case might not exist. Some companies, for better or worse, work without them; those companies aiming at innovation may allow work to proceed to a more advanced stage before asking for some rationale; and products which are in a steady state may just tick over without too much attention to a business case.
But in each one of these cases the lack of a business case has nothing to do with Agile. (Actually, each of the cases does have a business case, its either a tacit business case or a part of a much bigger business case.)
Many development efforts which lack a visible business case can benefit from demanding a business case. If you are not sure why your company is doing some piece of work then maybe the company needs to be clearer about the reasoning.
However, a business case might look a little different on a Agile project. It may well be shorter than a traditional business case, it may lack some of the detail traditionally found in a business case, and it may describe much more a trial-and-error approach.
What Agile projects don’t need are in-depth business plans. Here its a question of detail, a strategic business plan makes plenty of sense. But a business plan which lists many many features to be build and a detailed schedule of when they will be built is little more than an illusion. Such plans give the appearance of certainty but certainly don’t provide it. Indeed, too many plans can actively hinder a project - plans are not benign, they are dangerous. (See An alternative view of design (and planning) for more discussion here.)
That said, there is a very good case for writing a business plan - indeed most forms of plans actually: they are rehearsal time for the real thing. They help you explore and learn about the thing you want to build.
Still, sometime you might skip the business plan. Maybe there isn’t time for a rehearsal, and sometimes learning can be maximised but just getting stuck in .
But, if you do write one, then once that exercise is over, once you start doing it for real, don’t try and hold yourself to a plan. Put the plan in the draw and don’t look at it. The value of planning is not the plan you produce at the end of planning; the value it is the knowledge you acquire in your head.
For that reason you want to maximise the number of people involved in the planning rehearsal so you can maximise the learning.
Published at DZone with permission of Allan Kelly , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.