Agile, Waterfall or Wagile software development project? What defines real success?

 

In 2001, the Agile Manifesto set out a series of guiding principles in the adoption of a more responsive, effective and less wasteful approach to software development.  Often seen as a ‘better’ way than the traditional waterfall software development process, is it as clear cut as making a decision as to which is better? Are there really three options – being  agile waterfall or wagile ?

More importantly, why has it been so hard to achieve sustainable agility and responsiveness in enterprise software development initiatives?

Since then, established organisations that have embarked on the Agile journey have met with a mix of unfulfilled expectations, false starts, expensive mistakes, occasional stand-out successes or any combination thereof.

 

The term Wagile was coined some time ago to describe the situation where the traditional waterfall approach masquerades as Agile software development.  Agile Waterfall or Wagile – what’s it all mean and why is it important?

Irrespective whether your organisation’s agile software development initiatives are truly agile or wagile, the bottom line is that any decision to transition the development  of enterprise software from the conventional waterfall to agile is not to be taken lightly.

If your organisation manages to ‘align the planets’, so to speak, and successfully make the transformation to being truly ‘agile’, the potential for delivering business value through adaptability and resilience will extend way beyond the remit of the IT department and could just help save your business in our increasingly volatile world.

Now, that’s IT delivering real value – and one that has the potential to place IT front and centre in your business – a far cry from IT being held back from being actively involved in helping shape business strategies, by being treated for the most part as a cost centre..

Learning from others in their Agile Waterfall or Wagile journey.

The ‘mum effect’, or the reluctance to report bad news about a distressed project, is alive and well in our increasingly time-compressed, competitive, uncompromising and globalised  business environments.

Learning from the mistakes of others on the agile journey can be a valuable exercise, however many project failures do not make the light of day for a range of reasons such as job preservation of the messenger, organisational reputation and brand damage, through to adverse impacts on the company’s stock price.   Troubled projects, unless they hit the media or end up in legal proceedings, are likely to remain obscured, whilst project successes are actively promoted by organisations (as well as the vendors that had a part to play in that success).

For the most part, Governments, unlike private corporations, have a higher degree of transparency over the investments in major projects involving taxpayer’s money. For this reason, it is worth a brief review of the UK government’s Department for Work and Pensions recent agile journey

In 2010, the adoption of the Agile development approach was announced by the UK Government’s Department for Work and Pensions for their Universal Credit project – which was to underpin their welfare payments processing. Now roll the clock forward to 2013.

The September 2013 UK’s National Audit Office’s report as well as the preceding 2012 A snapshot of the use of Agile delivery in central government report should be on the ‘must read’ list for organisations looking to embark on large scale Agile projects from a standing start – especially where consulting firms are involved.  The price tag of £1.12 billion spend on multi-sourced contracts should help focus the mind if you are contemplating a large agile project using outsourced or consulting partners. Was this really Agile Waterfall or Wagile ?

Outsourced software development + agile = ?

The issue of managing Agile Waterfall or Wagile projects involving an ecosystem of vendors presents its own unique set of challenges. The reality is that the ultimate success of the overall project has less to do with the technical competencies or intrinsic capabilities of the individual vendors, and more to do with factors such as:

  • The quality and value placed on the relationship between IT and your organisation (e.g.: a peer to the business, not a subservient cost centre)
  • Clearly articulated locus of accountabilities for your vendors and your own teams, supported by an appropriately structured contractual arrangement,
  • Not underestimating the demands on team members by managing across diverse time zones,
  • Maintaining a healthy, cohesive team irrespective whether the team members are from your organisation, the vendors. or elsewhere,
  • Ensuring that the intent of both the vendor and your organisation on any agile initiatives is clearly understood.
  • Develop a common set of values and expected demonstrated behaviours between the various teams.
  • Diligence in vendor selection. Engaging a vendor whose staffing strategy is based on a revolving door of short term contractors may just be your first mistake.

Now, add heat, and bring to the boil…

When the pressure is on, and cracks start to form on the ‘agile’ project, if the perceived responsibility for a fault or failure lies with an outside vendor, this increases the probability that your staff reporting the bad news upwards (assuming that the fault or failure was not hidden or obscured by the vendor), rather than resolve the issue within the agile process itself. This has the potential to have a corrosive influence on the bonds of trust that underpins any high performing multi-sourced agile environment, and may help your vendor relationship move down the ‘blame-game’, adversarial path.

… topped with a poorly structured vendor contract.

Adding to this mix, if your vendor contract is poorly structured and is positioned along the conventional lines of specifications, deliverables, road-maps, outcomes and penalties, this may be the Achilles heel of any multi-sourced agile project. You could, in fact, be setting the vendor (and your project) up to fail before the project starts if the contract’s intent and terms are not in line with the expectations of operating within a somewhat less predictable agile environment.

Feel free to read my article on strategic vendor management which explored the following factors shaping vendor relationship landscape:

  1. IT may no longer be the primary decision makers.
  2. Your exit is more important than the entry.
  3. Disruption in your vendor’s market
  4. Too big to talk?
  5. ‘Agile’ is the new black
  6. Risk appetite is not constant
  7. Managing vendor jurisdictions
  8. Your vendor’s shareholders are not yours.
  9. What’s the purpose of your contract?
  10. Fragmentation of the vendor’s supply chain.

Question is:  On your software development projects, what measures are you going to put in place to ensure that your attempts at improving agility, speed of delivery do not result in your project being run as a badly coordinated three-legged race.