February 3, 2015
How to work agile in a waterfall organisation
Turning waterfall organisations agile is a long and requiring process. Without the cooperation of the people involved and the necessary training, implementing agile techniques in traditional workplaces can feel a little bit like you’re helplessly being dragged down an actual waterfall!
To avoid being crushed underneath the piles of documentation and interpersonal conflicts that inevitably arise when there is talk of working agile in a waterfall-oriented organisation, there some things you should keep in mind.
Changing deeply-rooted work practices is a difficult goal to pull off. To negotiate agile processes into a waterfall-based project you need first to deal with the conflict that arises due to inherent polarities in the two methodologies, such as:
- Valuing documentation over working products;
- Valuing contact drafting over customer collaboration;
- Valuing sticking to a rigid plan over responding to changes flexibly and creatively.
In this article, I give some pointers on how you can help your organisation shift from left to right along the spectrum, one project at a time.
Compromise your way to agile, one change at a time
The best time to suggest agile changes is usually before the team embarks on a new project. However, changing aspects of waterfall processes in order to make them more agile isn’t something you can force wholesale onto a team.
Compromising your way to agile is the name of the game.
Negotiating small, manageable changes to the development team by having it adopt select agile concepts from the Scrum framework, for example, allows people to ‘ease into’ the new way of working and prevent the clash of cultures that normally occurs when agile and waterfall collide.
Among the agile processes in the Scrum framework that are usually adopted first in waterfall-oriented organisations, one finds:
- Daily stand-up meetings
- Burndown charts
- Sprint planning
- Sprint review
- Retrospective meetings
Aiming to implement a small change consistently throughout the project is probably the most effective way to bring about an agile change that could eventually take over the organisation completely.
The balance between how much waterfall and how much Scrum is acceptable in a given organisation varies from one to another, as well as across departments and teams. Ideally, you should try to match Scrum processes to waterfall deliverables and avoid unnecessary or duplicate documentation.
Agile doesn’t mean reckless
Sometimes you won’t be able to introduce certain aspects of Scrum without first tweaking them a bit to make them more digestible to those working in a waterfall world.
Adapting agile techniques to fit better to the organisation’s existing, traditional workplaces means that often it is the agile proponents that draw the short stick in the ‘compromise’ I alluded to earlier.
In actual fact there are many creative ways to be more agile, but the main goal is always to help the organisation recognise the benefits of agile.
Trying shorter sprints and giving the team more time to complete bug fixes and increase their bug resolution rates is one simple change that can be implemented.
Another easy change to introduce is breaking down large user stories and test cases into smaller and smaller pieces, thus shifting the focus from long-term ‘planning ahead’ to short-term ‘getting the results we want’.
Although supporters of agile might passionate push their team into adopting Scrum methodology in the least amount of time possible, research shows that partial immersion in agile while the organisation is still largely waterfall-oriented helps achieve longer-lasting and more effective change.
The more natural this gradual process of immersing the team in agile, the easier the break from the traditional way of working will be.
As more and more Scrum-based projects are successfully completed, the team is very likely to start finding agile methods more superior and suitable for modern-day challenges than their old work practices. Once this tipping-point is reached, the transformation to a fully agile organisation is simply a matter of time.