Lean Software Development

How do we deliver Value to the business – FAST.  We do not always:

Know the requirements,
Have the money or the time
Know where we want the solution to go
See the Value in hard $.

This is a time when we need to leverage alternative delivery models that can live in this set of constraints.  Call it Lean Software Development or Agile Methods, there are some proven technigues for making these delivery models deliver value quickly, efficiently and reliably every time.

How do we deliver Value to the business – FAST.  We do not always:

Know the requirements,
Have the money or the time
Know where we want the solution to go
See the Value in hard $.

This is a time when we need to leverage alternative delivery models that can live in this set of constraints.  Call it Lean Software Development or Agile Methods, there are some proven technigues for making these delivery models deliver value quickly, efficiently and reliably every time.

We have a client who has developed their own model (to remane nameless).  And I have seen this method save some large projects from falling off the rails by segmenting deliverables and releases.  These methods are as much cultural as procedural – because quality, speed and lower cost are tightly linked.  Some interesting imperatives to think about:

Productivity – higher productivity can be gained by doing less. x% of effort brings y% of value, where I have heard 80/80 and 20/80 depending on the organization and process.  So why spend 160% or more of effort to get to 100%.  Leverage re-use and building blocks (SOA) as a religion not a practice.

Speed – Respond to your client, the problem rapidly.  Do not re-hash the same meeting over and over again.  As this model matures, you will find that speed will bring rapid, reliable, repeatable delivery.  Deploy small feature sets in priority order more often.

Quality – Superior quality is driven by test-centric processes.  This ugly step-sister can no longer be ignored.  Embrace her and share with everyone your assumptions.  Is an 80% accurate and supportable solution better than non – no way.

Value – Define what you call value of the solution before you start.  Make it real, make it lasting not trite.  Walk and view the world as your customer and test your value proposition.  Work together – closely – client, IT and vendor(s).  Now is the time to innovate and look for simpler ways, not tomorrow.  80% of software is written in the first release – change that mindset.

  1. Mark Dymond Reply

    I have experience with a couple of different Agile techniques. And I see 2 main problems with Agile/Lean software development.
    1. Clients (whether internal or consulting) want to know how long it will take to get to ‘the end’. Most have difficulty accepting the fact that the ‘end’ is a mirage. They understand that in Accounts Payable, for example, invoices keep coming in. So the department never gets to the end. But they don’t accept that requirements keep coming in. Not being able to predict the end makes it more difficult to sell – either internally or externally.
    2. Small teams working together produce great stuff. But when you need to create a large team, with multiple streams, it gets difficult to ensure that all of the streams prioritize requirements the same way. Automated testing will help to a point but without huge amounts of overhead (which Agile tries to avoid) you end up with each stream integrating to the last iteration’s version of the system. So at the end of each sprint/cycle, you have to re-integrate.
    Where Agile works really well is in sustainment. We’ve got a system, it basically works, how many new features can we cram in this month? How much is the end user willing to pay per month for ‘velocity’? This is a good way to introduce it -then from there tackle small systems first.

Leave a Reply to Mark Dymond Cancel reply

captcha *