One reason why your Agile implementation is failing
We spend a lot of time focusing on the people part of Agile — ensuring we have the courage, the heart, the mind, the WoT for the WoW, and the psychological safety to ensure our people in our teams are empowered to bring their best selves to work, every day.
And all of that is hugely important!
But, one of the things we don’t often discuss is the technical aspect of how to prepare your organisation for being able to realise the benefits of quick iterations and leverage the value of a sleek pipeline.
Why? I don’t know. Maybe it’s a chicken-and-egg thing.
Maybe if you’ve got everything in part a) right, then part b) works itself out.
Or maybe we just overlook this in the same way the development team or wider tech department are always overlooked. What even is Infra???
But the reality is that part a) is going to take a long time to do right. And in the mean time you still need to deliver value across the organisation, for your customers, your clients, for your colleagues and end-users.
This is why they should be done in tandem.
In order to truly deliver in a responsive and quick fashion, you need a pipeline and delivery lifecycle designed to enable that.
When leaders think about Agile, or they go to a workshop, or they’re sold it from the development team, it’s all about the sprint:
we’ll do sprint planning, ceremonies — a sprint review, retro, demo, daily standups and deliver every two weeks, it’ll be great!
But, where are they delivering?
Well, it’s what wraps around the sprint itself that’s often the bit that you need to get right if you want to succeed in developing a slick delivery lifecycle!
A living example
One of the products I managed began life with an eight-week scrum lifecycle!
The two-weekly sprint lifecycle was copied and pasted into every type of activity that occurs across a SDLC. There was a two-week sprint, followed by two weeks of SIT, then two weeks of UAT, then two weeks of integration testing, then finally a deployment into PROD.
Each of these done in their own environment!
This is not uncommon — in fact, it’s probably how most organisations implement sprints!
On top of that, the product originally conflated a “sprint” and a “release”, making them the same thing. This meant that we had releases blocked in various environments waiting for a single ticket or bug to be deployed, and we frequently missed releases due to a sprint holding us back or competing business priorities blocking us from releasing.
Once, we delivered six sprints’ worth of work in one release. Not on purpose.
So, we got rid of the separate SIT testing phase, doing testing within the sprint, thus reducing lead time in the feedback loop and allowing us to cut off “sprints” and package them up into fully-fledged and tested releases that don’t block any other work.
Next, we brought the UAT phase into the sprint, also, as a review and approval of the SIT testing, plus any additional business verification testing where appropriate — such as for more complex features.
Woah, we’re now down from an eight-week lifecycle to four!
And the really ironic part of this? It actually took us doing LESS WORK to DELIVER QUICKER!
All of this sets us up to release directly into PROD in some distant future, reducing the lifecycle to two weeks and coming even closer to being truly SCRUM or Agile-with-a-Big-A, reducing the feedback loop as much as possible.
But we’re blocked by another product which dictates that all development work has to go through a dedicated two-week cycle of pre-prod integration testing.
Because this is a core product used across the organisation to which all other products connect, and they have created an awful spaghetti pipeline for numerous projects and this pre-prod integration environment is the FIRST TIME that they all meet and the code is tested!
It almost makes you cry when you say it out loud.
It’s not always the actual implementation of your version of scrum or agile that fails — it’s often the additional waste and bureaucracy that you envelope around it that completely misses the point!
Not every organisation is willing, or able, to go full Agile, with heart, courage, mindset, and organisational structure. This is why I suggest you attempt to work with agility where you can.
What are the key tenets? Heart, mind, courage, action. Let’s do this!