Engineering Excellence… Introducing Sustainable Process Change.
Background
My mentor always tells me, “play the long game" and he is spot on.
I think of change needing to be regulated and fed into teams at a sustainable pace, especially if you work in a large program with lots of WIP (another article in the making here).
So when we started focusing in on engineering metrics around a monolithic workload. You start asking why are stage gates not enabled if there is the capability in your pipeline to production?
You could find a multitude of reasons: “It will slow teams down", “We will hold up the next release", etc.
There is a fallacy here as you start to rely more and more upon traditional QA talent and devalue them from doing high level exploratory testing by running repetitive test scripts. Well you get the picture… automation is your friend and you want to slow everything down, limit WIP and address underlying issues. At some point if you don’t address this you will hit a wall where CFR (change failure rate) or other factors stop you and force you to act.
Sustainable Change Management
You want to regulate change so you are supporting teams and not adding to the burden of WIP. Be it the introduction of the AWS well architected framework, accelerate metrics or stage gates. You want to break where you want to get to, into its most atomic form. You need to lay down a path and support your people to move past any inertia barriers.
Take a stage gate in a monolithic application, where do you start? It’s doesn’t matter what the technology stack is you need to look at the foundation. What is the testability of the application? Can teams write the tests you want to perform within the application? Culturally are teams prepared to deal with breaking builds or do they try and bypass them?
My team and I sat down and defined where we wanted to get to in our testing strategy and how we could tier gates which we called bronze, silver and gold. We looked at the minimum change we could implement in our stack it was Sonar blockers (our bronze gate). So we set a limit and got teams to work on reducing them over the coming sprint. We celebrated this change and looked at the next step. Limiting a minimum amount of code coverage on net new code (our silver gate).
Ownership
Now how do you bring this change about? I was inspired recently by Elon Musk and his comments around his engineering process and lesson learned including when receiving a requirement or constraint, it must come from “a name not a department. That person who’s putting forward the requirement or the restraint must take responsibility for that requirement. Otherwise you could have a requirement that an intern two years ago randomly came up with off the cuff and they’re not even at the company any more”, adding that this “has happened several times.”
Therefore you need to stick you name on what you expect teams to achieve and support them.
How do you let everyone know:
- Establish touch points with techleads and architecture in Dev forums.
- Establish touch points with engineering management.
- Don’t forget the business, having your product owners onboard is mission critical. This isn’t IT for ITs sake.
