Moving from Waterfall to Agile, mid-project

In my role as an Equinox IT Senior Consultant specialising in business analysis, I often work on client projects with the goal of modernising their business processes, including their development practices. In a recent assignment, I came on board as the Lead Analyst, for a three phase project, part way through the first phase. In this article, I cover the activities that I undertook to help change the way in which the team was delivering, from Waterfall to Agile.

Client Situation

The client was a large enterprise, who amongst other things collected information from suppliers, and the project related to this data collection activity.

Phase one using a Waterfall delivery method had not gone as smoothly as planned and it was clear that things needed to change.

It was identified that the project could be improved in three areas:

• Requirements – the data that was to be collected (inputs) was agreed with insufficient analysis of how the data would be used (outputs)
• Team – the team was siloed by function and faced barriers to collaboration.
• Process – the Waterfall delivery method had long feedback loops slowing opportunities for improvement; there was uncertainty around decision accountability and there was insufficient adherence to development standards.

Fresh thinking

I started talking about Test Driven Development with the team and the business, to give them insight to how the work could be tested before they built it and also to introduce them to the ideas of shorter feedback loops and breaking work into chunks of viable functionality.

Transitioning to Agile requirements

As the lead analyst I had influence over how we did requirements, and so this seemed a natural place to start adopting a new approach. I got agreement to introduce Agile requirements, so long as the documentation was still suitable to develop and later maintain the system.

So in phase 2 we put the existing use cases to one side and I switched our requirements to user stories, and acceptance criteria using specification by example. These approaches encourage much more collaboration with business, something the business representatives jumped at.

From there, because we had introduced the idea of “trying something different” it was easier to introduce the concept of short, sharp iterations. Requirements were tackled iteratively, just in time, along-side the development effort. We started to see benefits from the shorter feedback loops, allowing the business to see, touch and feel what was being delivered.

Transitioning the team

The most interesting part of this journey for me was the changes in the team. Most of the team had little or no experience in Agile delivery, so the task of change was not a small one for them to assimilate.

I’m a certified Scrum Master and so I ran some workshops for the team on Scrum, what it achieved and how it mitigated risk.

I also enlisted Equinox IT’s Ray Cooke and Carl Weller, who brought expertise in Agile development management and Agile project management respectively, to advise the project on reporting Agile project information in a traditional project governance environment.

There was a lot of conversation, coaching and behaviour modelling during the transition period. Slowly, as the team got more used to the new ways, things improved, most notably the communication within the team – rather than making assumptions or leaving stuff to fall out during testing or implementation, questions were asked and answered during the development effort. We were working as a team.

One interesting observation is that the team initially struggled with breaking work down into manageable chunks that delivered real end to end value. When you’ve always delivered work component by component it can be really hard to break that up into vertical slices of a system. To help with this I used Gojko Adzic’s hamburger method (yes I’m a big Gojko fan). This method takes the team, step by step, through the process. Like any change, this one also took time.

Transitioning the process

By moving business representatives to within the team the trust between the project team and the business grew.

The introduction of the Scrum backlog grooming practice, where the business prioritises the work and the development team acts according to that prioritisation, helped to curtail some of the issues around ownership of decisions, predefined planning and prioritisation.

As I’ve already said above, the shorter iterations of work meant the feedback loops were condensed, and the business was able to give real feedback on functionality based on how it was actually delivered, rather than how it was thought it would be implemented.

Result

The end result of transitioning the project to Agile was that this team became a Team. The work was delivered in a way that meant that suppliers could submit their data without having the issues that they experienced in phase one.

Transitioning from Waterfall to Agile isn’t easy. Transition takes time. With strong leadership and communication the project was able to deliver something that added genuine value through the information being collected.

You may also be interested in my recent blog post Agile requirements analysis and specification for a mobile application.

Kirsten Eriksen is a Senior Consultant specialising in business analysis, based in Equinox IT’s Wellington, New Zealand office.