With a couple of decades of experience working in and leading businesses in financial services I have seen first-hand the transition to Agile practices. Agile was first formalised in the early 2000s beginning in software development. But, how well does Agile really translate to a non IT world?
Spoiler alert…it’s a tough call. My experience is that there are a number of Agile positives and I will be specific on some of these below. Many of these are positives that high performing teams already embody and Agile is not the only path. That said in any business I lead into the future I would take the very best of Agile and apply it to the needs of that particular business.
- Cross functional teams. As an example (and specific to the world I typically occupy) this formally puts trading people alongside pricing, digital, operations, marketing colleagues working together in one team. The invisible boundaries of teams caught up by their own goals are removed and individuals work alongside each other. The business upside this can create is huge when the team are given clear goals and freedom to truly collaborate.
- Sense of ownership. A team that has a clear view of its own workstack, feels able to prioritise and choose how to allocate work based on capability and capacity is a wonderful thing.
- Workforce movement. That’s a horrible bit of jargon, but essentially I mean the act of throwing permanent job titles and team constructs in the bin. Colleagues expect and feel comfortable that they will move around based on business need. Development opportunities for colleagues categorically needs to be the quid pro quo for this change otherwise what’s in it for them?
- Transparency of workstack and throughput is my final major positive. This offers so many upsides. It generates a beautiful state through which output will often increase over time. Under performance is harder to hide through the nature of taking and delivering tickets and in my experience it can give the perfect foundation for colleagues to question how they do better and move faster.
Before you order your ‘Agile Project Management for Dummies’ and get cracking let’s discuss some of the potential downfalls.
The first is something I have seen throughout and I refer to it as ‘Agile Purism’. This type of behaviour is not unique to Agile but it certainly is prevalent. Colleagues and leaders hang their hat on the Agile framework and become slaves to fragments of the idea. They lose the big picture and instead Agile becomes a reason to object. For example, it is well known that Agile promotes the concept of regular releases and enables flexibility in what the release contains depending on capacity. I’ve seen this turn into scenarios where colleagues refuse to provide likely delivery dates because “it is not Agile”. My preference is for an ambitious delivery date and ongoing dialogue about trade off choices on scope. This is just one example and sadly ‘Agile Purism’ is probably my personal biggest barrier to the methodology and that’s because in my experience this is a hard one to overcome.
‘Limbo Leadership’ is next on my list, it demonstrates how important it is to upskill leaders alongside teams in a shift to Agile. Frankly I think that any individual operating as a strong leader will find the transition to Agile a fun one. But leadership skills are often in short supply i.e. the ability to lay out a vision, getting great functions of talented people together, clearly communicating, holding people to account, empowering their decision making and celebrating success. In my experience a transition to Agile for a leader who is still developing these skills can result in a limbo where they feel it is not their place to lead and guide.
The final potential downfall is the all or nothing nature of Agile. Different areas of the business of course have very different requirements in terms of how they operate. For example a product management function with a predictable workstack would really benefit from clear transparency of backlog and throughput. But, they are unlikely to benefit from a Kanban style of backlog management (i.e. constant reprioritisation) – this would be an unnecessary overhead. One size does not fit all.
Agile at it’s very essence is the desire for continuous improvement, and this is my view about how in a non IT world we do just that.
“there is a way to do it better – find it!” Thomas A. Edison.
If you want to learn more about Agile – values, methodologies and case studies then try out these links and resources. And feel free to add more in the comments below.