Agile Transformation: Finding your way in a complex world of Agile
Agile is here… to stay.
Believe it or not but in my relatively young career, I have been in the middle of 3 large scale agile transformations as well as 2 large scale SAFe implementation. And I don’t believe that I am an outlier. The latest State of Agile report found that 97% of the respondents practice Agile development practices and the most popular scaling framework is SAFe.
Source: 13th State of Agile Report
So, as I read my last book “Lab Rats” by Dan Lyons, I was amused by his critique of Agile as another management fad but I could relate to his perspective. Though I do have to say that I do not agree with his somewhat cynical view of why most organizations embark on their Agile Transformation journey.
Agile is super complex. No it isn’t. Yes it is. No it isn’t. Yes….
One of the things that did resonate with me is the complexity of Agile these days. There are so many frameworks and methodology to choose from that it can get challenging. Chris Webb from his Deloitte days is credited with creating the following Agile subway diagram.
Source — Slideshare
You gotta admit. It looks pretty daunting. I have read through the critiques of this picture. The ones I came across are — “Its contrived to make agile look complex”, “Don’t worry about it. Just pick one”, “Pick Framework X. It’s the panacea.”, “Its contextual”, “Deal with it. Everything is Complex”, “Welcome to the real world”.
However, here is the reality.
- The picture is real. All these methodologies and terms exist in context of Agile. I actually know quite a few of them and have come across them in my work and research (I know. I am little embarrassed to admit that).
- The picture is also misleading. These are not neatly arranged stations and routes that lead to your destination. Where you are starting from and where you are going is very contextual and the sequence of things could be just about anything. All these things have overlap (like crazy overlap) in principles, philosophy, methodology, you name it.
- And here is another sobering fact — this picture is incomplete. It didn’t even call out Spotify, Scrum of Scrums, Nexus and other scaling methodologies. Devops, which is called out on the right-hand side itself has multiple flavors — DevOps, DevSecOps, Rugged DevOps, CALMR, …. I could go on … Yikes!!!
And here is the real kicker. Let’s say, you follow the advice of “Pick Framework X”. Well, that was actually the easy part. In real life once you do that, you have to actually implement it. With people. Lots of people. People who have had different levels of experience, knowledge, training on something in that picture. And those people have opinions. Well… And then the real fun begins (if you can call it that) …
So, what’s the answer?
Drum roll … Here it is — All you have to do is …. Sorry. This is NOT that kind of blog. I do not have a grandiose opinion of myself to provide you the answer. I am NOT a consultant (not presently). You will have to find your own answers.
But here are some pointers (DISCLAIMER: based on my personal experience, being part of leading some of these transformations, reading (a lot of it) and talking to my peers):
- Don’t choose a framework/tool/methodology at first… Framework or methodologies are tools trying to solve a problem. You don’t pick a hammer on weekends and go looking for nails to pound (Unless you do. I am not going to judge). Start with a problem you are trying to solve and outcome you are looking for — faster delivery of value to business, improve quality of products, more innovation etc. Have an unwavering focus on these outcomes throughout your journey.
- If you do decide to go agile, have the conversation for the need for a methodology/framework/common language. In a large organization, you need some consistent way to coordinate across.
- Once you start on a journey, be vigilant about Doing Vs Being. I know there is quite a few blogs about small “agile” and large “AGILE”. Though, I do like the picture below from a blog about change by Alex Carabi, I will not get into that academic debate here . I will just say — use common sense. Don’t just go through the motions / rituals / ceremonies / quack together / etc. Make sure that you are getting the outcomes. If the outcome was faster delivery to business, don’t settle for once a year release even when you are agile. If the outcome was improving quality, don’t ship low quality products. If the outcome was more innovation, make sure that you are delivering on new capabilities/features.
Once you are on the journey, this is the most important pitfall to watch out for. Once you choose a framework and get some “practitioners”/consultants or train people, the doing becomes easy because it’s the tangible part (standups, retrospective, PI Events, ARTs). However, the being (mindset, core values and principles) as well as the focus on outcomes becomes less tangible and visible.
You will need to focus on both the Doing and Being. Success usually will require a balance of the two.
Based on my experience, it’s very much possible to run a large SAFe portfolio and yet have a whole PI (8–12 weeks) focus on regression testing or have 1 team working on features while other team working on testing and yet another on infrastructure with cascading dependencies. And you only release to business twice a year. I am saying that this is possible and still portray that you are doing SAFe. Hopefully you won’t get away with it for long 😊
Also, if you do end up in a similar sounding scenario, then you will probably be worse off than before because that is NOT the outcome that agile was meant to optimize. You could have potentially stuck to your waterfall ways.
I hope that helped. Let me know your thoughts in the comments. Has agile become too complex, too overarching? Is it actually simple? Have you seen / are you seeing tangible value from your agile transformation?
BTW, I didn’t even mention other frameworks in an organization and the impact of Agile on the same — COBiT, ITIL, TOGAF, ITSM, SRE …. Let’s not go there yet…
