3 Ways to Start the Journey to Agile and Bimodal – Part 3

Wednesday, February 15, 2017
Agile is becoming mainstream. A recent Version One survey on the State of Agile1 reported that 95% of respondents said their organizations practiced agile. However, many organizations with established waterfall methods continue to grapple with what this means in practice and how to blend agile and traditional methods to establish bimodal delivery capabilities.


Whilst most organizations recognize the benefits of agile, traditional methods will continue to have a place in their delivery toolkits.  The real challenge is understanding how the two approaches can co-exist.
As discussed in the previous blogs Digital Labs and Shadow IT, starting with smaller initiatives and adopting a pragmatic approach can provide the visible benefits that will build support for agile practices and bimodal delivery.   This is the third of a series of blogs which looks at some of the ways in which this might be achieved.

3  Agile Analysis and Design in Traditional Projects

Blended agile and traditional practice is often described using the derisory terms ‘wagile’ and ‘scrum-fall’ by its detractors.  We at Pcubed don’t understand the aversion, having used a blended approach to deliver clear benefits on several occasions.  True, a blended approach won’t deliver the velocity of pure agile; but if going fully agile is out of reach, then that argument on velocity is purely academic.  Why not use and benefit from agile techniques where there is an opportunity to do so?
Introducing agile techniques within existing gate based project assurance provides an opportunity to start the cultural change based journey.  Some steps you can take are:

  • Establish a project team workspace for co-located working of user community and solution delivery personnel
  • Secure commitment from user community managers for their people to be based in the team workspace for a percentage of their time
  • Use a Kanban or Scrum board for planning activities and tracking progress
  • Run daily stand-up meetings
  • Develop needs (requirements) using agile elicitation techniques: epics; user-stories
  • Time box requirements elicitation: the DSDM Structured Timebox works well in this context
  • Prioritise needs based on business value
  • Adopt ‘just in time’ requirements elaboration, deferring as much as possible to the sprints
  • Use scenarios to develop the business solution
  • Develop the business and technology solution in sprints
  • Use scenario walkthroughs, prototypes and demonstration labs to get feedback during sprints
  • Plan multiple releases; deploy a minimum viable solution to production as early as possible and then further releases at regular intervals thereafter.

To do this you will need to agree a tailored quality gate approach for your project, but this is unlikely to be a new phenomenon.  You are likely to need multiple passes through some quality gates.  One approach is to take themes (a group of related epics and user stories) and the associated sprints through merged requirements and design quality gates at the end of the sprints.  You will also have a quality gate for each release.

History shows that evolution rather than revolution is often the more effective approach.

We have found that users relish the increased engagement and appreciate the value of defining requirements in a more natural format. For most organizations the agile versus traditional debate misses the point; pragmatism suggests that both have a place in a bimodal change delivery framework.  Nor does agile have to be an all or nothing choice.

Continuing the Journey

As we have repeatedly stated, starting with smaller initiatives and adopting a pragmatic approach can provide visible benefits that will build support for agile delivery.  However, as many organisations are discovering, a ‘bottom up’ approach to agile is unlikely to be entirely successful or sustainable.  Agile represents a cultural shift; success therefore depends on changing hearts and minds.   Without this, ongoing friction will occur where agile and traditional practices meet. 
To deliver solutions more quickly everything else needs to go faster too: up to 80% of the delays that occur in technology projects happen before development starts2. One major source of delay are the ‘hand-offs’ where one group is waiting for another to provide approvals or complete tasks, whereby the other team may have different priorities.  Merely tweaking existing processes will therefore not suffice.  Existing boundaries need to be broken down and cross functional teams formed. Functions that straddle the boundary such as the Project Management Office will strongly affect whether an organization succeeds with agile.
All this can only be achieved with active sponsorship from senior executives.  Pcubed therefore recommends a strategic approach to your Agile and Bimodal journey, establishing an enterprise vision for agile with clear linkages to current business imperatives; this provides direction and justification for the required operating model changes. 

1 VersionOne: 10th State of Agile Report
2 Computing: Agile methodology: Can you ever have too many agile projects?

Eric Singleton is a Pcubed Principal Consultant.  He has led the business design and change on programmes in the public sector, logistics, finance, aerospace and manufacturing.  Whilst a Business Solution and Business Analysis Assurance Lead at a large UK logistics company he was helped define the Digital Lab’s operating model, introduced agile techniques into the Technology project delivery model and trained business project managers on how to utilise agile techniques in their projects.

For further information on this article and Pcubed, please email info@pcubed.com.