Saturday, April 12, 2014

Can you afford to be Agile?

Agile practices have the buzz of yielding results that are better, faster and cheaper.  But if so, why is it having such a hard time catching on?  Sure, many people are using it, but it is still considered a bit of a fad

I like the approach myself, under the right circumstances, and I contend that I have been using it for about as long as some of today's coders have been alive. Prototyping and mockups; Rapid Application Delivery; Joint Application Design -- these are all forerunners of Agile, all aimed at cutting through the ever-increasing pile of documentation that slows development and adds to its cost.

And let's stop calling everything Agile just to try and stay in the cool-kids club.  Releases every three to six months aren't Agile. A normal set of Agile sprints - 6 to 10 - would take 2-3 years to complete at a quarterly cadence, and most of these so-called Agile efforts don't deliver working product for the first 2-3 sprints anyway.  A year from inception to first delivery?  That's not Agile. It's iterative (and nothing wrong with that).

Over the past year I've had the opportunity to fund my own software development effort and certainly did not adopt an Agile methodology.  I've also set up a major development effort in an organization that does accept the Agile construct - but for this project we didn't use it. If Agile is so great - why didn't we use it?

  • For smaller development efforts, Agile is VERY expensive.  A standing team of developers and business analysts (even if it is only a couple of people and working at well below market) costs 160x50 = $8,000 per person per month. Let's say only 4 people, and say 3 months to run 10 sprints after setting the project up.  With a couple of extra thousand in incidental expenses, that's $75,000 to flesh out requirements and develop a minimal viable product.  Don't even think these folks are going to "work for equity" - they have to pay their bills, and you're stopping them from making money elsewhere if you're asking them to go full-time on your project.  Most startups can't handle that amount of investment. Even if they do have the money, or even if you are thinking about a smaller application within a large company that can afford to pay these folks, is there a business case for spending at least $100,000 by the time the solution goes into production?  That's not "just a little application".  Incremental iterations won't be as fast or efficient for the same amount of code, but they can be more affordable.
  • In the larger situation, we're not building an application.  We're building out a major infrastructure capability.  The full scope hasn't really been shaken out but it needs to be in place when the customers need it -- that puts us in front of them, which creates some challenges, most particularly that they haven't really locked in on what their needs will be at the time that this infrastructure is needed.  We don't yet have a solid future-state architecture.  And the hardware and software versions that this capability will use aren't even for sale yet.  We can't just start developing a solution.
Again, I like Agile - in its place.  There are far too many artificial barriers to using it in larger organizations.  In future postings we'll discuss those barriers and some was to get past them.  At the same time, let's not blindly chase the trend.  Sometimes, Agile is not the right answer.

Have you got examples of where an Agile approach is either impractical or undesirable? Maybe we can work out a classification system that would help people cut through the hype and pick an approach that will work for their actual situation.

No comments:

Post a Comment