The move towards agile is often kick started in engineering teams with an intention of improving the development process but if this process works in a silo then it’s doomed to fail.
It won’t take too long for the engineering team to improve the processes in their direct control and start looking to improve those processes that feed into the team at which point the organisation needs to adapt or accept the loss of ROI.
In organisations with established practices and processes it can be hard to transition to agile ways of working and they struggle to understand the intention behind such a move, ending up in a half-waterfall, half-agile process I like to call ‘Wagile’.
Under Wagile, the organisation will introduce some of the processes that make an agile approach successful, setting up retrospectives, allowing for more team lead discovery and releasing more often but they also still stick to annual plans, gaant charted deliveries and top-down deadlines.
The organisation may realise that the increments the teams produce aren’t having quite the impact they were expecting, before adopting an agile way of working and move from annual planning to quarterly but this still means there’s a potential three month gap between committing to an increment and measuring the value it delivers.
For the engineering team the Wagile approach has it’s own side effects. The team is told that there are many things they have to deliver but they can only work on the immediate ones as those need to be delivered sooner even though there could be more optimised ways of delivering value to the users.
The annual or quarterly approach harms the team’s ability to forecast what work is coming up, as everything that could be on the horizon isn’t committed to until the big planning meeting that sets out the work for the next year or quarter.
Hopefully after some time not realising the value they were expecting agile to bring the organisation reflects on it’s own practices and realises that they need to change the way they plan their increments and they make a move to agile planning.
An agile planning approach is more fluid than piling work up for an annual or quarterly planning session and involves working with delivery teams to do the discovery, development and release of increments as the teams become available to do the work.
This approach allows for smaller, higher value work to be delivered quickly and for larger work to be delivered in smaller chunks in order to gauge the value that user gains from it and to adapt to any user-driven changes that come up instead of committing to delivering a larger increment that might fail to meet user’s needs.
Programme management are still in control of what gets built but as they are no longer planning what’s being built over longer time scales they can re-prioritise more frequently and engage stakeholders more often to make sure they’re needs are met.
With the delivery team helping with discovery of the increments the programme management also get to learn how the solution will be implemented and can start to identify increments that can unlock faster deliveries of subsequent increments.
By embedding a culture of continual improvement (an aspect of agile that unfortunately is often overlooked outside of the delivery teams) the organisation can also focus on projects to improve their ability to deliver increments and maintain them once in production.
The agile movement in an organisation tends to start in a bottom-up manner with the delivery team changing to work in an agile or Agile way and then overtime chipping away at the processes feeding into the team until they hit a blocker.
It’s at this point the agile transformation needs to be shift from being a bottom-up movement to a top-down one, with the high level buy in lending the clout needed to unblock the delivery teams blockers and to establish agile processes at an organisational level.
It’s in this second phase that makes or breaks a successful agile transformation and where most fall into the Wagile trap so it’s important to implement measures to avoid this.
Originally published at https://averment.digital on October 21, 2020.