Developing Automation with Lean Methodology

So, now we are on what I consider the most fun part of the IT Automation Curator’s job description ( see the first blog post ) – developing new automation. Let’s first review the job description as I outlined it:

  • Collect existing automation, and then Catalog it where others can find it (See Part 2)
  • Develop new automation based on requirements from IT
  • Train others on how to use the automated processes
  • Maintain the existing automation

There is lots of great technical material out there about creating automation, and I won’t try to duplicate it here. And I also won’t push a particular toolset, though I have my opinions, of course. I am convinced that most automation project fail, not because of problems with the toolset, but rather due to problems with the approach. That doesn’t mean that one tool isn’t better than another, quite the contrary. The difference is just how successful can you be when you do it right.

To Automate or not to Automate – that is the question.

I think choosing what to automate is much more important to how you choose to achieve the automation. The best model we have for that, in my opinion, is Lean Methodology, and Lean Software Development, in particular. The Poppendiecks, creators of Lean Software Development, have their first principle as Optimize the Whole. The whole point of this step is to eliminate waste, known as muda in Lean methodology. Muda is “anything which does not provide customer value”. This is such a simple, yet revolutionary, concept. What if every sysadmin asked himself whether that script he was working on added customer value? Would they even know how to answer the question.

So, how do you answer that question? You look at the whole, end-to-end, process. This means no silos, no team-centric thinking, no “that isn’t my job”. What does it take to deliver a service to the end user/customer, and where are we wasting time and resources? In Lean Methodology you figure this out by drawing a value stream map. In the context of manufacturing, the source of lean methodology, it meant going from factory to factory, supplier to supplier, and putting together the complete picture of how a product is built and delivered.

So, what does that mean to our Automation Curator? Typically lean, or agile, software development stops at the delivering of the product to IT Operations. In the spirit of DevOps, that needs to stop. IT organizations need to start looking at the delivery of a service to a customer from requirements all the way through to production. That is the only context where it makes any sense to uncover muda. If you view IT Operations in isolation, you could very well create a highly efficient IT operation that doesn’t good services.

The IT Automation Curator has to focus on the automation projects that provide value to the customer – delivering new applications and features faster, restores services faster, provides better customer experience, etc.

What does success look like?

Once you have automated a process, how do you even know that you have achieved your goal of eliminating waste? That where measurement and reporting come in. If you have no way of measuring the effects of your hard work, how do you even know if you have been successful? You don’t. That means part of developing any automation has to be about measuring the impact on the customer. For example, you just automated the full-stack build of an application from scratch. How much more quickly can you deliver updated applications, or recover from problems? So, you have automated the application release process. Did that reduce downtime and error during new releases?

Once you have those reports – advertise them. Don’t be shy about showing how you are increasing value for the end customer. So many IT departments have been forced to show value by how much they can cut out of their budget. How much more would the business appreciate an IT department that demonstrably increases value for the customer?

I think this approach is so much more effective for determining what to automate and how. This singular customer and business focus is bound to make the IT Automation Curator a valuable member of the team. A lot more valuable than the “IT Hero” that corrects a preventable problem with heroic effort. I am also hoping to see this result-focused approach take over from the tools-focused approach so prevalent in DevOps today. If DevOps is to be relevant for more than just a few years, it must encourage behavior that adds value to the customer. Why? Because the customer is King!

Advertisements

5 thoughts on “Developing Automation with Lean Methodology

  1. Pingback: Value methodology | Fotozoom

  2. Pingback: IT Automation Digest for November 13, 2012 | Puppet Labs

  3. Pingback: IT Automation Curator – Good for techies, good for business, good for DevOps | Newtonian Nuggets

  4. Great post… No doubt that Devops must inherit Lean ideas which include systems thinking and optimizing the whole. However, one of the things that often gets missed by just Lean thinking (IMO) is to much focus on customer value and waste. I think Deming and Goldratt best summarize my thoughts about focusing only on customer value and waste respectively. Deming believed that all parties involved had to be satisfied (the worker, management, and the customer). Some have credited Deming for coining the phrase Win-Win. I am not sure of that but it is clearly the core of his philosophy. Deming believed that everyone in the equation had to have a win. Sometimes Lean practitioners tend to be too dogmatic in regards to the focus on “customer value”. Customer value at all cost and doesn’t take into account the other components of the system. You can talk about customer value all you want, but if you are not giving the worker value there will be no joy in mudville. Simon Sineck, in his awesome book “Start with Why”, says that the most important part of an organization’s life cycle is not the shareholders, not the customers, it’s the employees. Great employees create great customers who create happy stockholders.

    Goldratt has what I believe is a minor spin on Lean waste. Again, some Lean practitioners get dogmatic abut eliminating waste at all costs. In fact, it is my believe that Value Stream Mapping can sometimes promote this type of thinking. After a VSM it is very simple to identify the big pockets of waste and then wind up doing local optimizations that can possibly hurt the global flow. I would argue that Goldratt’s view would be to not to focus on waste but to focus on flow. In his book “The Goal” he illustrates clear examples of too much attention to efficiency and waste can lead to bottlenecks. Goldrtt is the inventor of Theory of Constraints which teaches us that not all waste/efficiencies are equal. In fact eliminating some wastes that look like they can have a huge positive impact can actually create a huge negative impact.

    Bottom line is that you have posted a great article and I am pretty sure Goldaratt would agree that without a clear cut view of the systems, local optimizations are better than nothing. In other words focusing on customer value and waste are a good start, but only a part of a bigger story for this thing we call Devops.

    Deming to Devops
    http://itrevolution.com/deming-to-devops-part-1/

    John Willis
    @botchagalupe

    • Thanks for the comment, John. I agree with your call for balance. This is a big topic, and there is a lot of nuance. Unhappy employees with no sense of mission will never be as efficient and on top of things as happy, motivated employees. They have to believe in the waste-elimination process. Most importantly, well-applied lean methodology should empower the “line” employee to proactively raise issues and ideas for increasing customer value. Top-down, forced implementations are doomed to failure.

      I am glad you raised value stream mapping. I wanted to spend some more time exploring how we could use VSM effectively in DevOps, and I will definitely be looking closer at Goldratt’s work in that context. I think that whole process, end-to-end, flow-oriented thinking is essential to doing this right.

      Thanks again for pulling in this additional perspective!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s