Posts Tagged ‘why agile’

Selling an agile approach…

December 1, 2009 Leave a comment


I came across this question at Discussion: Agile | LinkedIn (account required).  In the original posting Myroslava Trotsyuk referenced an article (How Agile Practices Reduce Requirements Risks) by Ellen Gottesdiener which describes 6 project risks that are mitigated by agile practices.  In response Lanis Brett Ossman raised the question:

Why is it difficult to sell an agile approach when delivering software solutions?

In explaining the question, Lanis Brett created his own list of 6 objections to adopting an agile approach.  While he labeled them as “risks”, I have encountered these same objections when trying to answer the question “why agile?”

– Risk 1: For the “major” cost, customers expect developers to figure out the details. They expect developers to know their business, for the money they are paying.

– Risk 2: Added cost for paying employees to review progress rather than do their regular job. Again, why can’t the developer nail down the details up front?

– Risk 3: Developers typically eat the added cost of poor impact analysis. Not the customer’s fault.

– Risk 4: Many developers just allow scope creep, so the customer does it expecting no impact to them. Creep is often small changes, but they add up fast.

– Risk 5: Defective requirements pretty much involve the same customer issues as Risk 1.

– Risk 6: Why should I, the customer, pay for your learning curve implementing new tools and techniques?

Nice list of risks/objections.  The original article was compelling, but outside of project risk it doesn’t address other objections to an agile approach.  When the customer comes back with “purchasing insists we know all the costs up front”  or “It is the rules, sorry” you often have no choice but comply – taking the cost-overrun bullet yourself instead of letting it hit the customer.  At this point, you have to overcome the purchasing or rules objection.  There is no point in pleading project risk anymore.

As the original article stated, software is different than other types of products.  In the physical world project estimation and sales are relatively straightforward.  Not so in the software world where our deliverables are unbounded.  We are not even limited by our materials or tools.  We can create tools as needed.  If we need a new fundamental data structure, or other “materials” we can create those too.

Until it is fully delivered, software only exists in the imagination of those requesting it and those building it.  There is plenty of room for misunderstanding and error.  This is the problem Agility was created to solve.  For it to work, though, you need to sell something that fundamentally looks agile.

Are you selling an agile project or a traditional one in which you hope to apply agile techniques?

Case study:
If I am an oil company ordering a drilling platform, I expect to specify its dimensions, drilling depth, and other requirements for the finished unit.  I expect the contractor to take my finished specifications, then working from a wireframe model, I expect the contractor to come up with a list of materials and standard times for attaching those materials.  The sum of the parts rolls up to a final cost estimate.  This is monolithic.

Similarly, as an oil company asking for “asset management software” I expect the vendor to pull pre-built elements off the shelf and attach them, like welding, to produce a final product that meets my specifications.  When I hear that I need to participate in discussions about every rivet, bolt, and plate it doesn’t make sense.  Why can’t you just pull 5 compressors and some 2″ steel plate off the shelf and put something together?

Points of failure:
Physical world –
Despite its enormous complexity, a drilling platform is made up of only a few hundred basic elements – steel plate, bolts, pumps, steel tube.  During construction these basic parts are used repeatedly. By modifying or “fabricating” these elements into the proper shape, they can be attached to an adjacent part. The complexity of this originates from the volume of repeating elements.

Software world –
Software is different. If a basic element is repeated, it is a sign of poor programming. If a software program has 100 different parts, every one of them should be unique and independently useful in shaping the final result.  Our raw materials – software classes – need to each function flawlessly to receive information, act on that information, and pass that information onto another class.  If a single element malfunctions it can affect the entire application.  Complexity arises from not only the number of assembled parts, but also from the fact that each one of these parts is individually unique.

Bringing it back around:
Our customers are accustomed to purchasing monolithic items in which the number of fundamental parts is small.  In theory if we could break our offering into elements, each of which is no more complicated than a drilling platform, we would reduce our software risks to the (embarrassingly) relatively low risk of building a drilling platform.

To achieve this we need to get our offerings (what we sell) small enough where the functionality is represented by a few hundred classes at the most.  By keeping what we sell small, we lower everyone’s risk – ours and our customers’.  We can build up complex solutions from these smaller elements.

I came across the following article Still playing planning poker? Stop gambling with your project budget. – About Agility which addresses the question of estimating an agile project.  In it Robert Neri describes an approach to using user stories to estimate the project.  Admittedly a user story is too fine grained to be useful in a sales situation.  We need something a bit bigger, but not too big.

What does this look like?
Try breaking your offering into smaller lego sized chunks of value.  Instead of selling “asset management” try selling solutions to individual problems within this domain.  The trick is finding a level of usefulness that we can sell.  I can’t sell a login screen, but I can sell a “remaining life monitor”.  I can’t take the risk of selling a “control panel”, but I can handle selling a “panel shell” and some “snap-ins”.

In the way that a user story breaks functionality into something we can build, we need a way to break a project into valuable chunks we can sell.  Right now I am working with a concept I call “critical paths to value”.  Instead of proposing to build the entire offshore rig, I’ll start with proposing we build a boat that could hold a drilling platform.  A floating platform is the first critical path to value.  The next would be the drilling rig, followed by a control room, and next maybe a transfer point for offloading oil.

So where are the critical paths to value in my own application?  I am working on it.  I’ll post an update as things unfold.