Often the adoption of DevOps goes hand-in-hand with the application of lean practices. Lean practices are focused on value creation for the end customer with minimal waste and processes. When thinking of lean practices, small nimble startups come to mind, but consider the behemoth Amazon.
Image: CNET / James Martin
You may have read the “2016 letter to shareholders” from Amazon CEO, Jeff Bezos. It’s a very interesting read and can easily be used as advice on how to become more lean. There are many nuggets of pure gold on how to transform towards becoming a more lean and customer-focused organization. Here are some of my favourites:
- Nuture experiment patiently, accept failures, plant seeds, protect saplings, and double down when you see customer delight. A customer-obsessed culture best creates the conditions where all of that can happen.
- Focus on results and not process: “process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right… The process is not the thing. It’s always worth asking, do we own the process or does the process own us?”
- Customer obsession: “the product or service owner, must understand the customer, have a vision, and love the offering”
- Make decisions quickly: adopt high-velocity decision-making, don’t spend time in constant disagreement as it’s exhausting, instead “disagree and commit”
If we were to look at ourselves in the mirror at how we are operating: Are we experimenting and nurturing? Are we driven by the outcome of value for our customers? How often do we change processes for improvement? If we were to answer the aforementioned questions honestly, we’d probably have to say, no or sometimes.
Get out of the building
Image: sunolgroupmedia.com / Tito Hamze
Companies adopting lean will use a “get out of the building” approach, in order to ensure they are creating value. They go out and ask potential users, purchasers, and partners for feedback on all elements of the business model. This feedback not only includes product features, but will include things like pricing, partnership strategies, customer acquisition strategies, etc. Then, using the customers’ feedback, they revise their assumptions, start the cycle over again, test redesigned offerings, and make further small adjustments. Yet, another “Rinse, Repeat…” cycle in the DevOps adoption journey. Bezos refers to this as “resisting proxies” to your customers, where proxies are customer surveys, analysts etc. rather than use these proxies to go out and talk to your customers.
Lean and its origins
The precursor to Lean practice is the Toyota Production System (TPS). TPS is a manufacturing methodology developed over decades by Toyota. The system identifies three classes of waste in Japanese: muda, muri, and mura. Lean Thinking equally aims to remove waste (muda), overburden (muri) and unnecessary variation (mura). Muda, muri and mura are called “the three M’s.”
Image: mudamasters.com
Muda – Waste
Muda is waste. Eliminating waste is a key DevOps principle. It’s simple to identify muda: if you’re not adding value, then you are adding waste. Always be asking and challenging yourself with the question, is the activity that you’re currently performing adding value?
Waste reduction is an effective way to increase profitability. There are many ways to avoid waste:
- Start finishing and stop starting or limit the WIP (Work In Progress). WIP is the amount of work you have started but is not yet complete. On the factory floor, WIP is half assembled items that are lying about waiting to be completed. Eliminating WIP is a way to increase throughput in your software. Stop working on multiple tasks at the same time, people think that they are multitasking, but in reality they are context switching. Each switch, takes time to ramp up and causes tasks to take longer to complete. Thus, you need to start finishing and stop starting.
- Avoid hand-overs. I have witnessed a ticket for a security scan which took almost 60 days to move from open to close. Everyone on the ticket did a great job and were working hard, but everyone on the ticket belonged to different teams, which resulted in handover between the teams. The handover was further compounded, by the fact, that teams were in 3 different time zones. The end result, 60 days to complete! Where possible, we must strive to eliminate handovers and ensure that we have cross functional, empowered teams 100% capable and supported to deliver customer value.
- Make everything as simple as possible, but not simpler. Wherever possible, in our products and process, we should be striving for simplicity. We must avoid complexity. For example, if we build a complex system then the cost implications for us and our customer is huge, due to a multitude of problems.
- Remove bottlenecks. If you have read the Phoenix Project, then you will know all about the character Brent. Brent is a rock star of an engineer. However, as a result of his rock star status, he is essential for every project and is badly overcommitted. Brent is a human bottleneck. The hero of the novel accelerates work and removes waste, by finding ways to protect Brent from interruptions and ways to reroute work, allowing Brent’s efforts to be focused elsewhere. Many organizations have a “Brent” type character, they are someone without whom work would stop. These people are overcommitted and face burn out. They are so overcommitted they feel they’re too busy to document their process or methodology, leading to a situation where they are a single point of failure. How many teams have a go to person for product down issues?
- Hire a Director of Getting Stuff (or choose your own word here) Done
Mura – Inconsistency
Mura means inconsistency or excess variation in work flows through the factory floor. An example, the manager is measured from the factory floor on monthly output, and as a result the department rushes like mad in the final week of the month to meet targets. This results in using up components and producing parts not actually required. Now, during the first week of the month, production is slow, due to component shortages and no focus on meeting targets. This unevenness has created waste.
Within R&D, we reduce inconsistency in workflow by adopting a consistent process for delivering software or services. Today, for teams, this is a choice between agile, scrum, or kanban. It means reaching a nirvana, whereby work is broken down and planned accordingly, and whereby the team commits and delivers to some committed scope of work. It means management is working to protect the sprint team from distractions, so the team can focus on getting things done at a consistent cadence.
Muri – Overburden
Muri represents the activities where processes, people, or machines are pushed beyond a reasonable limit. If we have a lot of muda (waste) and mura (variation), then more than likely we’ll suffer from muri. In theory, if teams have adopted agile/scrum correctly, then they are empowered to select a realistic amount of work with their sprint and as such there should be no overburden. However, in reality, with context-switching, defects, too much work-in-progress, bottlenecks, handoffs and delays, it often means that agile cadence is lost, and teams become overburdened, leading to burnout. The management and scrum masters have a role here to protect the sprint, which protects the engineers from burnout. In addition, for some light relief, there are events like hackathons, which can be more relaxed and change of gear to the regular release cadence.
Wrap up
Becoming Lean won’t happen overnight. It will involve some introspection into who we are and how we operate. We can take inspiration from the likes of Amazon, but we should also be cognizant that we have a completely different culture than Amazon (remember C is for Culture).
Also, we should know that one shoe does not fit all. Validation of our move to lean should be easy, as we should see more cost savings, more happy customers and most importantly happy engineers!
And, here are all the blogs in this series: