DevOps and The Theory of Constraints (I)

Likewise in the manufacturing industry, software development responds to a series of transformational steps, but these are orthogonal to creativity, leaving the impression that manufacturing processes will always be ahead in terms of maturity. And this is important. Whether it is making cars, metal plates or applications, there is a coordinated activity between a sequence of specialists. In manufacturing it is called the Production Line (or Assembly Line) and in software development we call it the Delivery Pipeline. And both systems of production are subject of being applied the same rules of productivity: poorly coordinated activities between these specialists create bottlenecks, reduce throughput, increase operational expenses and set rework cycles up high. Does it sound familiar?

Manufacturing industry is really process-heavy, and if we look back to the recent decades, many companies have mastered processes of improvement such as LEAN, Six Sigma or JIT in order to survive in a highly competitive world. And this is certainly an area where software development can learn a lot from. Concretely speaking, the Theory of Constraints (ToC) – introduced by Mr. E. Goldratt in the inspirational novel The Goal – gives us a powerful framework to guide our process of continuous improvement in the IT industry. These techniques, applied to the production line, have demonstrated results in reducing lead time and improving due-date performance, something that is absolutely interesting to replicate in software’s delivery pipeline.

Having said that, if we now look at all the modern LEAN, Agile and DevOps techniques such as test-driven development, weekly sprints, small user stories, automation, team collaboration and all the new measurements around them, they seem to be a natural embodiment of applying the ToC framework to the IT space.  The match between both worlds is extraordinary: there is an increasing focus on accepting the SDLC as an end-to-end production system by bringing development and operations together; a desire to relieve the most constrained resources by implementing automation and a vision of using the available finite capacity to consistently ship Apps faster to the market. Yes, the mantra of DevOps has a lot of intersection with the ToC.

But let’s explore this intersection in detail, illustrating how these new IT techniques are perfectly aligned towards the goal of an organization expressed in terms of the ToC: increasing throughput while simultaneously reducing both the inventory and operational expenses.

  • Increase Throughput: measured as the rate at which the system generates money through sales. In other words, this is money coming in the company. If something is produced but not sold, that is not throughput. Then, techniques like continuous delivery combined with smaller batch sizes – in the form of discrete user stories – and better feedback between teams play in favor of improving the lead time needed to turn a requirement into a working software feature. For products (in SaaS or licensing modes) this means more and faster incomes from users who were waiting for those features; for those development projects where price is fixed and time is boxed, the income is not recognized directly at the application itself but more at the business process which it is enabling.
  • Reduce Inventory: all the money that the system has invested in purchasing things which it intends to sell. In other words, money contained within the system. These are unfinished goods, such as different versions of code ready to be tested and built artifacts deployed in intermediate environments. From another perspective, these are potential features that cannot be purchased by end users because they are still trapped in the system, so the sooner we release them, the faster they will be turned into cash. Technologies such as automation and cloud environment provisioning combined with methodologies like Test-driven Development – where testing sets the pace of the full SDLC – help reducing piles of inventory queueing and waiting to be processed by humans.
  • Reduce Operational Expenses: measured as all the money the system spends in order to turn inventory into throughput, this is, money coming out the company. In apps development this typically the hardware and licenses needed, as well as the labor hours of development team, or work in process. All the techniques introduced by LEAN, Agile and DevOps help reduce operational expenses in terms of less rework needed, less defect rates and less time to recover from failures. With shorter sprints and automation technologies, we will incur in less costs needed to produce inventory (trimming work in process), helping to reduce overall queue and waiting time of inventory (finished code, built artifacts) which means we help boost throughput up (deployment in production). One special case to mention is knowledge, which can also be treated as operational costs if only because it helps turn inventory into throughput – unless this knowledge is stored in a DB or is included as part of the product documentation, which in that case, is considered as inventory.

In essence, these new Agile and DevOps techniques will help companies capitalize on software, applications and IT services, resulting in better financial performance which can be measured in terms of higher levels of profit, ROI and cash-flow.