I have been thinking about this topic for a while and finally thought it was worth doing a brain dump of my musings.
In our part of the world (Canberra — AU), scaled Agile has had a big push and drive of implementation. A number of government agencies have been sold on the promise that scaling agile will solve the problems they are having with complexity. Our IT systems are a big bundled mess that has led to big, complex and compounding structures, unbearable to support with dependencies issues and breakdown of communications across the organisation.
I do think this issue is due to the current climate and environment of the small Canberra bubble of government agencies. We have got ourselves stuck in this mess with monolithic systems that are tightly coupled requiring large groups of people to support (think 100s to 1000s of people). These applications are at least 10 years or even older! And now relying on skillsets and expertise that are slowly fading away. Retirement mornings teas seem to be replacing the forced middle management ‘team bonding’ morning teas and are now a sombre affair. The look of dread in people's eyes as the one person that knew COBOL won’t be here on Monday. The COBOL system that processes the customer payments now has no corporate knowledge. Systems releases will now become a black art requiring unicorn blood and the souls of 100 IT project managers to deliver the new ‘widget x’ — or contract back the retiree.
Having such large groups supporting a system where most team members report to different people with different matrix management are having extensive communication and alignment issues. So I can see the appeal of the silver bullet being sold. Let’s do a PI planning session, so we can communicate and build shared understanding. Let’s get all the scrum masters together to discuss blockers and impediments. Let’s all be on the same train, so we can coordinate and align our integrations and releases.
Now don’t get me wrong, I do not have a problem with scaled Agile frameworks. I have seen the benefit of the communication and conversations a scaling framework can create, generating alignment and a shared purpose. But for me, I think it is solving the wrong problem. I think this is addressing the symptoms, not the root cause of the problem. That the application sitting underneath all these teams is still a monolith and is only getting bigger and more complex.
One of the most important insights for me came from Steve Denning at AgileAus 2018. In his sit down, Steve mentions one of the Ten Agile Axioms That Make Managers Anxious, specifically the sixth axioms. Don’t scale up: descale complexity down. I thought, why then are we being sold on and only focusing on scaling? Why are we not instead, focusing on descaling our complexity? The answer I believe, is because it is hard. It is a lot easier to organise a bunch of people into a room to hash out what needs to be done than investing in re-architecting and reengineering our monolithic systems.
However, that practice is now well understood and we should not be afraid to tackle it. DevOps and associated practices have been well-known and adopted since 2010, Jez Humble has been talking about the strangler method for years. This is all very doable but it takes time, which is an investment I don’t think we have or are willing to fight for. Our current practices of funding cycles lead to focusing on large initiatives and projects. Which creates a constant pressure to deliver the next cool feature, or implement a legalisation change, or if the minister has said ’jump’. There is always a constant stream of work flowing in that takes priority to hit the milestones and dates of the fin-year.
When though will we have the chance to take a step back and tidy up our own backyards? I joke that if we stopped all work and if everyone was devoted to rearchitecting and reengineering over the next 12 months, we would regain/recoup the productivity and outcomes in the following 12 months due to the simple fact of removing red tape, not having to deal with internal politics, dependencies, integration issues and conflicts across groups. The benefit of autonomy and loosely coupled architecture would far outweigh the investment it took to get there. We only need to look at the numerous case studies and leaps our brethren in the private sector are making.
It is my belief scaled Agile in this government setting will only take us so far. The communication and governance are important but at some point, the efficiency and benefits gained will dry up. However our customers, the public, will still have high expectations and demand. Maybe this is the peak that ANZ has recently hit, and they are now trying to work out what the next step is. No longer is it good enough to release once a year, 4 times a year or even once a month. The demand is for better products, better quality and frequent updates. This demand has been ingrained in our customers’ psych from all the other services and products they consume in our digital age. Could we then be better spending that time investing in our technology stack?
With the recent announcement of Services Australia, I put this to you, when are we taking on the monolith and strangling it before it strangles us? How are we going to sustainability meet this rapid demand of our customers?