How to apply agile principles

At Inspire11, we believe that mixing domain expertise enables us to deliver novel solutions for our clients. 

The result of this thinking is greater throughput with improved quality and is often associated with a lower total cost-to-value realization. One area of domain cross-pollination comes from mixing up agile software development with lean manufacturing. In principle, the foundational elements are similar – focus on the customer, eliminate waste and let value flow, and iterate.

At large enterprises, we find that agile software development looks very different everywhere and companies struggle to align their business planning cycles and requirements definition processes to the various agile delivery mechanisms.

Too often, there’s a blow-it-up and start-over mentality because the outcomes fail to meet expectations. While at times this may be necessary, assessing organizational processes the same way lean six-sigma black belts leverage Overall Equipment Effectiveness (“OEE”) to identify bottlenecks can be the tactical means to increased velocity and better business outcomes. 

When OEE meets agile development

In lean terms, OEE is an overall measure that evaluates a process or piece of equipment by combining several key measures into a single KPI – performance, quality, and reliability. 

OEE is a straightforward mathematical equation that aggregates overall process efficiency by breaking things into components and assessing the efficiency at every step along the way. For example, let’s leverage a simplified distribution example to demonstrate the value of the metric for a customer order: 

1. Item is available 98% of the time 
2. Item is picked in the correct quantity 98% 
3. Item is packed and labeled correctly 98% 
4. Item is shipped on time as the customer expects 95% 

The overall OEE for this system is 89%, which is achieved by multiplying each component. What may intuitively seem like an A-Level performance from each component of the project results in a B+ experience for the consumer – which is why we invested in the first place. 

Transposing this concept onto software delivery is fascinating as the impact is more dramatic. More so, we find that organizational processes around development are far less consistent, organized, and mature than the Standard Operating Procedure (“SOP”) world of manufacturing. If we transpose OEE to the traditional Software Development Life Cycle (“SDLC”) of Design-Build-Test-Deploy and assign a 90% effectiveness score to each component, we realize an OEE score of 66%.  

Each component of the system is working effectively and doing a “good job”… A-players doing great work! Nevertheless, the business stakeholder in aggregate has a very different experience than the individual teams assessing (accurately) their individual contributions. There’s an argument to be made that this is possibly the root cause of the divide between business and IT. 

Real-world actions & outcomes

Instead of an organizational realignment or new enterprise framework, there are some tangible actions organizations can take that will help keep all the well-performing processes while improving work items most impactful to output and value: 

• Process Inventory: What are all the things an organization does? Take the end-to-end delivery path of a single unit of software. What are all the things that need to be done, at a high level, within a given context? 
• Demand Analysis: Where is the organization’s capacity focused? This can be a low-resolution estimate to a time-study supported analysis. The goal here is the 80/20 principle – identify those items where organizations spend the most time finding waste. 
• Quality Assessment: What are the expected outputs and how well do our outputs meet organizational and customer expectations? The critical component here is to think about both the quality AND the timing components. Again, various mechanisms work from analyzing workflow in an Agile-tracking tool to surveying process SMEs. 

Combine the three components to calculate OEE and prioritize remediation activities. 

In other words, strive to pick a subset of two or three areas with low OEE scores and high organizational demand. Dig into the processes more. Map the Value Streams. Calculate OEE at a more granular level by repeating the above steps for the individual process components. Work with the team(s) to define the problem. 

Make changes and iterate.

These changes can be incredibly simple. Sometimes it’s a regular sync between two product managers. Other times, it’s setting clear expectations on what high-quality output means through examples. Frequently, it’s a process of elimination for those low-value and relatively high-effort activities to free up the capacity to focus on high quality and timeliness of delivery. 

OEE can be the means to MVP. If we improve each component of our 4-step SDLC by 1% – we gain nearly 1 full sprint of output over the course of the year. By continuously improving one increment at a time, the results gain momentum.