Over the last three years I’ve  heard ‘Agile’ as a project methodology really take purchase. I’ve also seen a lot of change projects describe themselves as using ‘agile’ methodology, but I’m not so sure they were…I suspect there is a lot of liberty being taken!

The Agile Manifesto can be summarised with four principles

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

 

So this week I have Jenny Vandyke explain what Agile looks like from a change management perspective. Jenny has worked several bona fide Agile change projects and is author of the The Innovation Recipe: Key ingredients for world-class results in big business.

In this piece she uses the cooking metaphor to explain the differences between traditional project methodology (also known as waterfall) and Agile.  As an aside, Jenny’s book is great – I’ll be coming back later with an interview to share more with you!

Dishing up change one bite at a time

 

There is no doubt that agility is a huge competitive advantage.  It’s frustrating when major corporate change programs take two or more years to implement, and business strategy, environmental conditions and available technologies have all shifted in the mean time.

Traditionally, change programs have been delivered in one ‘big bang’ like the traditional roast dinner – hard work to prepare and slow to cook, but the end result has all the trimmings and won’t leave you hungry. More recently, a ‘bit by bit’, tapas of tasting plates has become popular, also known as Iterative or Agile delivery. For an explanation of these two menu options, you can take a look at my Big Bang versus Bit by Bit cheat sheet.

Traditional, Waterfall, Big Bang delivery is suited to complex or high risk change programs and risk averse, conservative or complex businesses.  There’s more time to prepare for the change, and fewer surprises along the way.  Bit by Bit or Agile delivery is great for getting a change delivered quickly, then progressively adding new bells and whistles to make your solution even better.

Key ingredients for success

The key ingredients for success are exactly the same on Waterfall or Agile projects.  Either way, it’s still key to:

  • be clear on your project objectives and requirements
  • have strong sponsorship and change leadership
  • manage risks
  • maintain active feedback loops and robust testing
  • communicate effectively to manage your impact on staff and customers.

The key ingredients are the same but the cooking methods are often different.  In Agile there is less formal documentation and more informal conversations.  There is also substantially more stakeholder engagement required on Agile projects.  A 300 percent increase in stakeholder engagement requirements is not uncommon, including multiple half day or full day stakeholder workshops.  From a stakeholder’s perspective, the good news is they don’t need to read a 200 page requirements document written in tech-speak.  It’s much easier to get a feel for what a system will be like by sitting in a workshop experiencing a live demonstration of the latest prototype.

Maintaining enthusiasm for the change program tends to be easier as you get runs on the board along the way.  It’s really important, though, to manage expectations.  If your stakeholders are used to waterfall projects they may expect all the bells and whistles to be delivered in the first release, which goes against the Agile philosophy.

The role of the Change Manager in an Agile project

It’s critical for Change Managers to have a seat at the table when setting the delivery approach on an Agile project.  The sizing and timing of each Agile release needs to consider not just the technical development complexity and lead times, but also the magnitude of impact on staff and customers.  I’ve seen one change on one screen of a system impact 100 business processes and 40 teams.  A small technical change doesn’t always equate to a small impact.

Conversely, it’s important to be sure that each release delivers value to impacted businesses.  I worked with a client recently who had to move their application to a new back end platform – the system looked exactly the same but was on a new, future-proofed platform.  Now, they could have made the new application an exact replica, but they took the opportunity to make a few small tweaks that added real value to staff and customers at the same time.

Working on an Agile project takes a different style to Waterfall.  Flexibility, and effective communication are critical.  Within Agile’s tight turnaround times, everything becomes critical path, with little time for contingency.  You need to be really clear and focussed on those activities most critical to success, because the odds are you won’t have time or bandwidth to do everything you’d like to do.

Having an experienced change team is critical on Agile projects.  Things move more quickly so there is less room for error, and less time to develop solutions.  There is less time to learn on the job.  There is less bandwidth to learn from mistakes.  When selecting a change manager for an Agile project, deep change management expertise is far more important than prior Agile experience.

I’m seeing some really exciting projects get off the ground and deliver quick results using Agile principles.  However, it’s not enough to compress a Waterfall timeline into Agile releases.  You’ll need to ramp up your stakeholder engagement, bullet proof your decision making and recruit a seasoned team of project professionals if you want your Agile project to deliver on the promise.

Bio

Jenny Vandyke is an innovation consultant and the author of The Innovation Recipe: Key ingredients for world-class results in big business.  She helps business leaders turn great ideas in to great results through Zumbara Consulting, based in Melbourne.  Jenny developed her six-step Innovation Recipe based on more than 10 years senior level experience on major projects at Australia’s largest companies, including National Australia Bank, BHP Billiton and KPMG.  Over the years she has presented hundreds of workshops and keynotes, including a keynote at the 2013 Australian Innovation Festival.  Zumbara is Spanish for buzz, and Jenny gets businesses buzzing.

 

mm
Dr Jen Frahm – Experienced change management practitioner, communications professional, coach and facilitator. Member of Change Agents World Wide network, author of the Transformation Treasure Trove Series 1 & 2 and upcoming book “Conversations of Change – navigating workplace change” .

5 Comments

  1. James says:

    Unfortunately this article really hasn’t helped me at all. I’m a change manager at a government organisation. We have a scrum team and they want to become more agile. I’ve been doing change now for 5 or so years and really am not across what that means for our current process. No doubt it will need to evolve, but does that simply mean some of the quality gates are removed as we are moving so fast? What does agile really mean for change management? what process impacts does it have?

    • mm Jen says:

      Hi James – very sorry, I haven’t been helpful to you. I would suggest you chase down a copy of Jason Little’s Lean Change Management and Emma Sharrock’s The Agile Project Manager. They may be able to explain things in ways you may find more helpful.

  2. Gert Pienaar says:

    I have read the article and would like to contribute my understanding. Agile really means, lets get real and focus on the business reality.

    To me this became the need because technoligy did not fully serve the business requirements even though rigorious water fall processes and stage gates were followed.

    Agile want people to refocus on the real story lines of the business. Lets change in relation to the real story lines of the business. Change is either incremental or we choose to write a completely different story. Where does the story originate from is the question.

    I did narrative practitioner training for the past year and without intimate understanding of the narratives operational in the organisation it is not possible to be agile. Alot of people are misunderstand agile to be ready for anything.

    Lets drop all the disciplined approaches, because it takes to much planning time and we are making to slow progress with getting the solutions out.

    I am convinced that if the narratives of the organisation is not understood, agile is a recipe for more seat of the pants decisions and thus a disaster in making.

    We either make changes thoughtful and deliberately or we do it intuitively. Kannebaum asserts that if we act with untrained, immature and inexperienced intuition we could make huge errors of judgement.

    Let me end with real story. I have observed a team doing scrum in a development team for a whole year. They basically wrote down on white board what everyone was busy with on daily basis. It was an individualistic exercise.

    I do not listen what you are saying. I instead think about what I am going to say. There is no time to cross pollinate and discuss the collective work and what we actually are trying to achieve. Without the story lines clear you would not be able to be more agile.

    Agile does not mean people are active and running around like headless chickens. It means we are in charge of the story line and can drop, continue or start new work because we are intouch with what clients and thr business wants. No more flocking of dead ideas because we have invested so much time and energy in them already. We push the boundaries of excellent ideas because it fit with the storyline whe chose to create.

    Best regards

    Gert Pienaar

    • mm Jen says:

      Gert – a wonderful contribution, thank you so much – I really like your threading of narrative and story lines into agile practice and yes, can imagine if more did it this way there would be more comfort with agile.

Leave a Reply