CALMS for DevSecOps: Part 3—How Lean Improves Performance

This is the third of my blog posts investigating DevSecOps through the CALMS lenses—we’ve looked at Culture and Automation already so this time it must be the turn of:
 

LEAN

In the previous blog post I looked at some DevSecOps tools I particularly like and introduced you to TaskTop. TaskTop is the ultimate in optimising your flow from idea to realisation—a connectivity framework that takes the pain away from writing and managing integrations and visualising your lead and cycle times. It’ll show you where your bottlenecks are.
 

I do a lot of value stream mapping with my clients as part of their journey—it gives us incredibly powerful metrics but it differs from TaskTop in that it’s not driven by data from the systems but from people’s heads. Not that this is necessarily good or bad—I’m firmly in the camp of a combination of man and machine works best in the business climate we have today. Humans still need to interpret trends and mostly decide how to act upon what the data is telling them. And often the data isn’t yet available.
 

Recently in a value stream mapping exercise I facilitated the team assigned an eight week wait time on the security activity in their value stream due to the resource constraints and separation between the teams. It was the biggest delay by far to the overall cycle time so one of the key areas we addressed. There are two main ways in which to tackle this when we see it in a value stream:
 

1. Man: A pattern that’s worked really well in many of our clients is to put security practitioners into the autonomous squads or product/feature teams for a period of time (around 3 months usually). I’ll explore this more in the fifth blog in this series around the S in CALMS—Sharing
2. Machine: In the last blog post, I looked at the A in CALMS, Automation and how to shift left by integrating tools early on into the pipeline for security checks and also how to provide operations-as-a-service
    

Another lean tool to think about in the context of DevOps is Kanban and the ability—like with Value Stream Mapping—to visually collaborate on the flow of work. These tools are so powerful partly because they are all about visibility, and visibility builds trust which is—as we learned in the first blog post in this series about Culture—foundational to nurturing a DevOps environment. Kanban can help show where are blockers are and where we have too much work in progress too. This is fundamental to driving conversations about improvement.
 

Talking about improvement, we encourage all organizations to become experimental to drive innovation whilst reducing risk. Using lean’s improvement “kata” is key to this becoming habitual—breaking away from a meetings and planning culture, towards small frequent incremental improvements. People who have trained in martial arts are familiar with kata—it’s about practicing the same pattern repeatedly until it reaches automaticity in the brain and it truly is a habit or “the way we do things around here.” We start by considering the long-term vision or direction, consider the current state and decide on our next target state. Then we PDCA between the two states—we Plan then Do then Check then Act in a continuous cycle.

This idea of incremental and continuous improvement is also reflected in the DevOps Kaizen, a model that drives us to encourage our clients to think of a DevOps journey in evolutionary rather than transformational terms, reaching an overall state of improvement faster. Since the impact of smaller changes on productivity is smaller and the organizational system has time to recover faster and make another small change more quickly.
 

Whilst improving the system though, we are still running the system. John Allspaw once said:
 

“An incident is an unplanned investment, and if you don't see it that way as a leader, you are not getting a return on the investment that was already made on your behalf.”
 

We don’t often feel this way though, particularly with security breaches. But this brings us to another lean concept: the Andon Cord and its relationship to high-trust organizational culture. Thanking people for a learning opportunity and working together all the way through to an improvement helps build our security posture and remove waste from our flow—and removes a blame and punishment approach, building trust.
 

At its core, lean is concerned with identifying and removing waste from the production line, so the metric we most commonly associate with it is cycle time. It’s super-effective at showing us when our security model is acting as a bottleneck, but what other measurements are useful in the DevSecOps world? I’ll answer this in the next blog post in this series: CALMS for DevSecOps: Part Four: Measurement.

Related posts

• CALMS for DevSecOps: Part 2—Why You Need Automation
• CALMS for DevSecOps: Part 1—Why Culture Is Critical 
• Why Manually Managing Machine Identities Destroys DevOps Automatio