Path Forward

The Waste Perspective

The basic idea is to eliminate anything that the customer is not willing to pay for or sees value in.  Often IT is considered a cost center and until recently little evidence that investing in IT provided signification returns.  Puppet Labs, a leader in DevOps implementation practices found the following in their 2014 State of DevOps Survey:

“Companies with high IT performance are twice as likely to exceed their profitability, market share and productivity goals, giving them a strong competitive edge.” – Puppet labs

Knowledge Waste:

Classically occurs when individuals do not effectively communicate their knowledge to others within the organization.  Some examples might be marketing might know something related to the product and not inform engineering so they could address that issue or perhaps plan for what is coming down the pipe.  A better example would be engineering not informing marketing of limitations of the system that then impacts the organizations ability to deliver a promised feature to a new customer.

Knowledge lost can come from many areas such as personality tensions, physical barriers, reshuffling of teams, or where quality assurance testers are not documenting their testing scripts.

It can also relate to software systems not communicating successfully with each other.  A common theme we dear during deployment is our CRM system has all the customer information, but we can’t get access to it or that it does not have the exact information we need.  What was the solution?  Another system was created to track what the Deployment operation teams needed during release cycles.  The barrier here is that now we have another system that contains customer data and there is no communication between these systems and it is now up to the Deployment team to keep this data current.  The waste in this last example could have been solved if we put the resources on it and implemented a processes that ensures the collection of the correct data and perhaps a plugin for Sugar to allow the deployment teams to grab the exact data they need.  What the point I am making here is that individuals need to think as our systems for tracking information as a unified whole and that we need to extend them and avoid; if possible, creating new systems that do not talk to each other.

A problem we have now is the silo of knowledge of our internal IT infrastructure and systems.  We need a process to distribute this information to others in the organization and a means to test this knowledge transfer.  Examples of these are EZ-Import, IFAS, SSO and our Xen Server Systems.

Waiting Waste:

In development we constantly see waiting waste impacting QA.  I presume there are other example of such waste in the organization.

Over-Production Waste:

As other types of waste build you will see this creep in as a means to buffer against it.  An example of this would be for a PO to request a feature that is fully baked and feature rich when a slimmer version could have been delivered and value to the customer measured. (Measured is the key here)  This example is real in our organization due the simple fact of people saying a second slice never happens.  Another example of this over production is we need to keep people busy so lets us load up on task so we can produce more than we need.  To me as a developer this relates more to loading a sprint up with tons of task, this in turn drives a developer and testing team to push content down the pipe faster without taking the time to produce higher quality work with full feature testing and automation.  Often, less is better.

Over-Processing Waste:

How many features in MS Word do you use?  Over processing leads to feature bloat, which in turn increases support cost and a tendency for customer confusion as to how to use the product.  Just because it could land a sale is not always the best choice for a feature.  Our entering of data in Sugar and other customer tracking systems is an over processing waste something I mentioned much earlier.

Motion Waste:

Staff staying up for long hours to push a product update is an example of this.  A real and impact waste of motion is our QA team performing repetitive manual testing.  This testing must be kicked off each time we have a code change and the testing is manual so a human could forget to follow a particular step in the multipage test document.

Transportation Waste:

Clumsy movement of our code between environments.  In development we see waste in preparing Integration, QA and Staging servers.  We have improved the process by automating the code checking and firing off automatic Integration testing so see if a build has broken.  We also fire off nightly builds to QA servers, but Staging still requires a human to kick the process off.  The ideal would be for various stages of testing to pass and as each pass the system automatically kicks off the next build and deploy.    How often does the deployment team zip up code and transfer it to another system to be installed or moved around?  That is wasteful and should be automated.  I believe there is a ton of transportation waste among other systems outside of R&D.

Correction Waste:

Fixing defects, rushing to hit a deadline to ship yet the testing is not fully baked or the feature impact on other systems not fully understood?  How many times have we seen incentives to ship, not incentives to ship well… This happens when to little emphasis is placed on prevention.  Acceptable quality limit is ok?  The desired result is to build in quality from day one, not on the way out.  QA should not be a trap to prevent release defects only.  Again, quality built in from the front.

Inventory Waste:

Code waiting to be shipped is an example.  Our Houston code as of right now is considered inventory waste because it is not adding value to customers now, nor is it being measured in any way as useful to any customer because they cannot use it.  Integrations is a prime candidate for this, we can develop an integration system, but until it is fully implemented we are not realizing revenue from it.

Dev Ops

Add Value

The entire goas is to add value and improve flow for the organization.  How can I deliver more customer value by improving the flow throughout our organization by reducing waste and recognizing some shared pain and collectively improve some of that flow so that we can make more money for our company.  The point is how can we add value particularly money, revenue, and financial impact to my organization.

Taking a step back consider LEAN – in short, it is not to cut cost, but to free up resources so we can focus on adding value.  Achieving the below goals with the least amount of waste.



So why does LEAN matter in the Dev / Ops discussion?


In short Dev / Ops is the result of implementing LEAN principle to the IT value stream.  How are we shortening lead time, reducing the friction between development and operations?


For the culture piece people must want to improve the processes so they can improve the quality of their work life and the quality of their efforts.  Without the culture buy in, the remaining items will have little to no impact.

The automation process is huge and will help eliminate one of the biggest factors in slowing down delivery value to customers: waste.

Monitoring is nothing more than measurement.  But if we can’t measure it, we can’t improve it which is a very old saying but still holds true to this day.  So in DevOps, we really want to monitor so we can do continuous improvement and sharing of information as related to the health of our pipeline in our projects.

Sharing is huge, it is about having true feedback loops.  Not just dev telling ops things, it is about all of the organization’s people telling others things that lead to reducing waste, improving automating, implementing monitoring and shortening the feedback loop to deliver value.

… working on game plan next…