That multiweek cycle that suits the dev team isn’t always a great fit for devops
Software development is all about rhythm. In scrum, different sprints might have different lengths, but they follow a predictable pattern. Plan, execute, test, accept the work, reflect, and repeat.
Hopefully devops is an integral part of your development process. But that doesn’t mean it should march to the same drumbeat. That multiweek cycle that suits the dev team isn’t always a great fit for devops. That’s why devops lends itself to a different workflow than scrum.
Much of devops’s underlying philosophy descends from Lean and just-in-time manufacturing techniques, where the work cycles are shorter. In these environments, the workflow of choice is Kanban. Kanban breaks jobs down into small, easily completed tasks, often represented by notecards or Post-its (the word kanban means “card” in Japanese) arranged in columns on a board or a wall, each representing a different phase of the value chain.
The focus in Kanban is on completing tasks, limiting work in progress and delivering immediate value. Because Kanban cycle times are measured in two hours or a day, this model is a great fit for devops, where you’re frequently ticking off small, discrete tasks and moving on to the next thing.
Kanban and scrum
Kanban and scrum aren’t mutually exclusive. In fact, they complement each other quite nicely, and when used for devops tasks, they allow your fast development cycles to go even faster. The more inefficient the scrum team, the more they’ll tend to benefit from devops with Kanban. It’s especially useful in organizations new to agile, where teams tend to carve off more than they can do in a sprint.
A devops team using Kanban is constantly analyzing the software development and delivery value chain and identifying inefficiencies. These will often come up in the sprint retrospective, but you shouldn’t be afraid to add to the devops backlog throughout the sprint. Give the process some flexibility, prioritizing devops work with the shortest cycle time and the largest impact on improving story flow.
Fast follows smooth
The goal is to go smooth, not fast. Fast will follow smooth. At the start of a project, scrum developers will be going slow at the beginning, laying down a solid foundation of clean architecture, and automated tests that will allow them to keep their pace sprint after sprint. Meanwhile devops, using Kanban, can smooth out a scrum’s initial fits and starts by quickly building the infrastructure to make the development team more efficient. By decoupling devops from the scrum development cycle, devops can make quick improvements that deliver huge value to the devs.
As a rule of thumb, you should automate anything you do manually twice. Once you’re knocked off the trivial inefficiencies, you can take on the thornier issues, like code review. Automate as much of the code-review process as possible using static analysis tools, linting, code coverage tools, and code mergeability testing. That’s the stuff that eats up a code reviewer’s cycles and doesn’t add much value. Reserve precious code review time for things that matter: algorithmic efficiency, maintainability, adherence to patterns and the like. Focus on adding value by making your code more sustainable and leave the nitpicking on camel-casing and brace placement to automation.
Like any development methodology, Kanban does pose certain challenges. The idea of working on one thing until it’s done is foreign to many developers. They feel like they’re accomplishing more when they’re spinning plates, moving everything forward 20 percent. But one of the central insights of Kanban is that while it feels faster to work holistically, it actually isn’t. You improve efficiency by minimizing the friction that comes with task switching. Flow through the process is key; anything flowing against the process is waste. Make improvements at the bottleneck. You’ll soon find that as the developers get more in tune with the flow of the devops process, it improves the overall story flow through the sprints.
Also, while Kanban tends to involve small units of work, that doesn’t mean practitioners shouldn’t think holistically. They absolutely should. That’s an essential part of the “product mindset” philosophy, which places a premium on team ownership and initiative. Given Kanban’s small units of work, it’s all the more important for project leads to ensure developers have a clear picture of what they’re building.
Naturally, you will only derive the value of Kanban in your devops if you keep the focus on the business drivers for what you’re building. That means you don’t get so bogged down in the details that you lose sight of the overall value chain, or programmatically follow a process just because that’s what you learned in training.
In sum, own the process, make it better every cycle and pay attention to when something feels off-beat. You can usually ferret out something that gives new insights, improves your process and gets you back into the groove.
