Ram Khemani is the engineering manager in the enterprise finance team. They have been part of a huge data lake migration for the last 12 months. Last month, they have completed a huge release that was committed by executive leadership to migrate the modules of ledger and revenue management to the new platform. During this final push, he realized that the Definition of Done was not paid attention and hence, the level of automation is not as high as he wanted it to be. He also found that it takes about 2 hours for the developers to complete the check in process. Each step takes nearly 2-5 min, but it is ridden with many manual steps of validation, code reviews and hand over processes.
He went through the state of DevOps and wanted to create a roadmap for his team to move into a more engineering driven culture for future releases. Can you help Ram Khemani for the same?
Solution: Some of the indicative paths
Ram Khemani’s team is in between the governance and chaotic process of change management. His team has also spent the last few months only in the functional side of development collecting lot of technical debt.
Understand the manual steps that are leading to 2 hours of time to check in. Then the team can take specific actions to address them. These can be converted to technical stories in the sprint backlog. This way some of the manual steps can either be avoided or automated partially
Create a backlog of all the technical debt that’s collected. This would bring a level of transparency on everything that has to be fixed. After that, identify the priority. Using a relative priority as a scale, team can add them to each sprint to pay off early. Earlier tech debts are paid off, incremental issues that could crop up later can be reduced.
Identify Infrastructure Automation as a key initiative and identify skills that are required. This would typically be coming from either the DevSecOps team or Center of Excellence for Change management based on how the organization is structured. Creating a partnership with the team is very critical for such an initiative to succeed. Next is the dev team needs to add skills to their repertoire.
Ram Khemani’s work is clearly cut out. Whichever path this team chooses to take, one thing that’s clear during a migration program is to accept the status quo.
Status quo would be the least path of resistance in the short run
And worst path to have taken in the long run
While the solution is simple, its implementation will be tough since the business would not easily sponsor them. While it is a good idea to write all technical debt stories, generally, there will not be any Product Owner who likes to own and accept since the PO comes with business mindset. These kind of work is pushed by external team (not the scrum team). Generally, these is a lack of ownership of these stories and pushed by external teams. I am purposefully, I am not the solution this gap in this comment. Want to hear from others.
I agree Guru. The reason why i mentioned this as a Dilemma for the Engineering manager is do we handle only the low hanging fruits and run with it, or would you work for a harder and more difficult transformation of creation of a working pipeline.
I know one manager I have interacted made the call and felt the next 6 months extremely hard to convince and influence different stakeholders. This is easier to accept while you are doing a transformation.