Operating with agility is very important for Wavestone’s clients in rapidly evolving and uncertain environments. The techniques and methods that enable agility, that have come to be known as ‘agile methodologies’, are being employed across much of our clients’ organisations. Initially designed as an improved approach to develop higher quality software products and reduce waste, these methods are now applied across the business as development and operations converge.
This article is about the learnings of my team on my latest engagement, applying ‘agile methodologies’ in a business context.
What does ‘agile’ mean to you?
The word ‘agile’ has become an overused and often divisive word in the world of software development, operations and project management. Somewhere along the way people’s perception of the word shifted from a flexible, adaptable approach to its antithesis: a rigid set of methods that create blockers, cause confusion and slow progress. ‘Agile’ enthusiasts would put this down to these methods not being employed correctly. And they are probably right. But with all the focus on applying the methods absolutely, the one thing we’re trying to achieve seems to have been lost: agility.
When it comes to project (or programme) management, these negative symptoms can become even more pronounced. We substitute out the clean software development world of small, distinct, cross-functional teams for a complex mix of siloed teams with more than a few dependencies. And move from a single product goal that represents what the customer wants to a range of conflicting requirements, including set deadlines defined by a regulator. The ‘agile’ approach established in the textbook can easily lead towards inefficiencies and significantly increased effort and time.
Learning our Lesson
At Wavestone, we have been fortunate to work with many supportive and trusting teams, managers and stakeholders that are happy to experiment with applying a range of different techniques, whether they are labelled as ‘agile’ or (as shocking as it might be) labelled as waterfall. After all, ‘agile’ methods are based on the scientific hypothesis, so for me this approach embodies their values perfectly.
One of the key changes I introduced when we engaged with my last client was to reduce the size of the stories. With the type of deliverables and the number of dependencies, most stories were taking longer than a Sprint to complete. As any product manager would know, that’s not good: without completing stories within a Sprint, the product is not a usable increment that can be properly tested during the Sprint review and the feedback gained is much less valuable. So, I added in backlog refinement sessions with the team and broke down each story vertically to create better minimum viable products (MVPs). We headed into the following Sprints expecting a much greater rate of quality feedback and therefore an increased rate in producing quality, finalised deliverables.
The former occurred, the latter didn’t. We did receive high quality feedback much faster than before, but the feedback was easy to incorporate into the deliverables we had created. They could be edited and improved rather than needing to start again from scratch. The rate of development of the finished product following the feedback also only marginally increased. At the same time, we had lost the economies of scale of completing all the deliverables together, in one waterfall style development process, which were very important with many dependencies.
So, what did we learn?
It became apparent that rigidly applying these methods to our context resulted in us taking much longer to create the same quality of deliverable. It also created a frustrated team who felt restricted by illogical rules, and stakeholders who felt they should have been engaged in a more efficient manner. Incorporating waterfall development ideas and allowing certain stories to span across multiple Sprints enabled us to operate much more effectively.
Having said this, the conclusion wasn’t waterfall is victorious. I am a strong advocate of ‘agile’ and the Wavestone team utilised many powerful techniques that enabled us to adapt our approach and deliver with agility throughout the engagement.
We continued to manage the programme with an ‘agile’ operating model, including using well established cyclical, consumed ceremonies to continually plan, track and measure progress. Due to regulatory deadlines however, we maintained a high-level product roadmap as well as a product backlog to ensure we met non-negotiable requirements while being able to flexibly reprioritise at a more granular level. We allowed step-by-step development when it worked, while encouraging short testing cycles where useful.
In essence, we changed our focus from employing arbitrary rules that may or may not improve the speed and accuracy with which we reached the end goal, to embracing the underlying values that enable agility. We reduced customer feedback loops and tested only usable product increments when that helped achieve the objective. The vast array of methods out there can be great enablers of agility, but they are not the right answer just because they have the right label. Agility in my eyes, is being able to respond quickly to changes in the environment and delivering what the customer truly wants. How you go about doing that is up to you.
Adam Becksmith
Consultant
We support our clients across financial services, government and retail to define and implement change across both business and IT. During implementation, many clients require an agile approach to project and programme management to align their business transformation and development teams. We bring a host of skills and experience that enable our clients to deliver with agility and apply our expertise in managing projects to define an approach that is well suited to their context.
Related Insights
Wavestone
David Marsh