Lean Engineering – Lean Methodology Applied to Enterprise IT
November 11, 2014
Lean Engineering defines a set of principles that guide the creation and deployment of software products at high velocity with low risk. By leveraging a Lean Engineering approach, the risk of validating new technology, making incremental changes in process and bringing new products to market can be lowered and a high quality result can be achieved at a faster rate.
Every discipline requires a set of principles or assertions to build upon. As disciples of the practice of software engineering, it is imperative that we define a clear set of unwavering principles that guide the process, methodology and architecture for the products we create.
Lean is not a new idea. Its DNA can be traced back to the 1950’s and 1960’s where Toyota optimized the now famous process of Lean Manufacturing. Many of the guiding principles behind Lean Manufacturing are credited to Taichii Ohno, former Vice President of Toyota Motor Corporation along with Shigeo Shingo. Together they created what is now called the Toyota Production system (TPS) not to be confused with TPS Reports, which by the way are due Friday.
Taiichi Ohno set out to eradicate inefficiency and eliminate waste in the part of the production process that he was responsible for. He introduced several concepts such as Small Batch, Just-in-Time and Continuous Improvement.
Given a large batch of work to do our first inclination as engineers is to devise the most systematic way we could work our way through the batch by organizing the work around the repetitive tasks. Imagine stuffing 1000 envelopes.
As engineers it is very likely our first inclination would be to process this job in the most efficient way possible, use a large batch process approach to streamline production.
- Tri-Fold all the letters
- Place the Stamp, Delivery and Return address stickers on the envelopes
- Place the letters in the envelopes
- Seal the envelopes
This seems straightforward and super-efficient because we are performing each task at a high rate of speed due to the repetitive nature….but we would be wrong.
What if the envelopes were the wrong size for the paper? What if the stickers had no glue? What if the envelopes were defective and could not be sealed?
In order to learn that the manufacturing process was flawed it would be better to do a small batch, in this case 1 complete cycle through the process, (1) fold, (2) insert, (3) sticker, (4) seal, so that we could identify where the process might fail before proceeding at scale.
Small Batches = Fail Fast!
Whenever a problem was found in the Toyota manufacturing process, any worker on the line could stop the process and all hands were on deck to fix the issue before proceeding. Workers were encouraged to find the root cause of issues and fix them on the spot. The line workers were also encouraged to make improvements at their station without having to ask permission from management. This process was called Continuous Improvement. Some of the benefits of Continuous Improvements are:
- Improvements are based on many small changes rather than the radical changes
- As the ideas come from the workers themselves, they are less likely to be radically different, and therefore easier to implement
- Small improvements are less likely to require major capital investment than major process changes
- It helps encourage workers to take ownership for their work and can help reinforce team work, thereby improving worker motivation
W. Edwards Deming a pioneer of the field saw continuous improvement as part of the ‘system’ whereby feedback from the process and from the customer were evaluated against organizational goals.
Among the most widely used tools for continuous improvement is a four-step quality model—the plan-do-check-act (PDCA) cycle, also known as Deming Cycle:
- Plan: Identify an opportunity and plan for change
- Do: Implement the change on a small scale
- Check: Use data to analyze the results of the change and determine whether it made a difference
- Act: If the change was successful, implement it on a wider scale and continuously assess your results. If the change did not work, begin the cycle again
Continuous Improvement = High Quality!
The concepts outlined in Lean Manufacturing were applied by Eric Reis with various startups he worked with during and after the dot.com boom. He evolved the guiding principles of Fail Fast and Continuous Improvement for the process of developing software products. Eric Ries’ overall claim is that if startups were to invest their time into iteratively building products or services to meet the needs of early adopter customers, they could reduce the market risks and sidestep the need for large amounts of initial project funding and expensive product launches and failures.
Eric Ries defined a scientific method for bringing new products to market successfully. Instead of making complex plans that are based on a lot of assumptions, you make constant small adjustments moving at high velocity through the Build-Measure-Learn lifecycle.
Build-Measure-Learn is a feedback loop. The goal is to move through the cycle as fast as possible to validate your ideas.
You first define a Minimal Viable Product which is that version of a product which allows the team to collect the maximum amount of validated learning with the least effort.
You build the MVP and put it into production (Continuous Delivery) making sure you have the means to measure both the run-time health and usability of the product (Continuous Analytics).
You then engage your customers to get feedback on the product using methods such as Split Tests and Surveys. This provides the learning (Continuous Feedback) that will act as input to the next cycle.
Minimal Viable Product
A minimum viable product is defined as that version of a product which allows a team to collect the maximum amount of validated learning with the least effort. Defining the MVP for each iteration through the cycle is an important skill that a team needs to develop in order to be successful using this approach. Scope to much and your velocity drags, scope too little and you don’t learn enough through the cycle to validate the release.
One thing is true we want to avoid the big bang approach of trying to design and implement a large system from top to bottom. This approach leads to monolithic architectures, missed deadlines, poor communication of an end users’ needs versus wants, lost developer productivity due to the sheer volume of the undertaking and the inevitable death march to oblivion.
By developing our skills in defining minimal viable products we can achieve useful, simple products that allow us to engage our users early, get feedback, validate our ideas and fail fast if we hit a wall.
For example let’s say you want to validate the idea that a Microservice architecture is the right direction for an upcoming project. Not everyone is convinced and are learning towards a traditional monolithic architecture but they are interested in seeing if this approach would work. The minimal viable product may be to define one Microservice with a one or a very few API’s and implement it with a focus on the following common capabilities:
- Logging and Error Handling
- Run-time Analytics
- In-memory Caching
- Data Persistence
- API Design
- API Management
Once built you can deploy this into product and let the team (customer) play with the API and if using API Management, getting real-time analytics.
Now at first blush that seems like a lot but by focusing on the cross cutting concerns and not worrying too much about the business logic aspects of the service you can provide validated learning that Microservices with good API design and common error handling, logging and reporting capabilities, etc. will be a feasible direction for the entire project, not just this one service.
Lean Engineering leverages the Continuous Innovation Build-Measure-Learn cycle from Lean Startup and applies these methods to enterprise class product development. Note the use of the term ‘product’. This is an important distinction. As engineers we are conditioned to think in terms of projects that have start dates, tasks, milestones, and more often than not go on forever. Simply shifting our point to view to ‘we create products’ we can rise above our conditioning and become entrepreneurs who are expert in bringing high quality products to market at velocity.
Our market are the employees and partners we support in the enterprise. Our products are the infrastructure and applications that provide the foundation for running the company. We are enterprise entrepreneurs.
In order to achieve our goals of high velocity and high quality, it is necessary to make frequent automated releases. Within the Build phase we define the Minimal Viable Product, that version of a product which allows a team to collect the maximum amount of validated learning with the least effort. We automate our Software Development Lifecycle (SDLC) through the definition of a Deployment Pipeline.
The Deployment Pipeline includes the Continuous Integration that the developers use to automate source code control, build and uit testing. A Deployment Pipeline is the automated process for getting code from version control into the hands of testers, from test to staging and from staging to production. More broadly is is all bout automating the process of getting you idea into the hands of end users in order to drive the feedback loop.
The deployment pipeline defines both the deployment schedule as well as the release schedule. The difference between a deployment schedule and a release schedule is:
- Deployment is an engineering decision about how often to deploy to staging in order to validate the build
- Release is a business decision and happens when the team is ready to kick off the feedback process
The principal benefits of automation is that it creates a repeatable, reliable, and predictable process. It brings order to chaos and if combined with a rich feedback mechanism, insight into team performance.
In order to provide input to our validated learning experiments we will want to take every advantage in collecting data whether that is through the deployment pipeline automation or at run-time in production. Our goal should be to incorporate analytics into every aspect of the process in order to generate data that can be synthesized into information and leveraged as part of our learning process.
In order to get real-time data from our code base it is important to incorporate instrumentation at the code level, logging and exception handling. We will also want to leverage existing operational tools for measuring load, server and process health, database metrics and so on. If necessary the team may consider building a dashboard to coalesce all this information into a single view for easy consumption.
We also release often and engage our customers to provide feedback that we can leverage to help define the next phase of development on our Minimal Viable Product. As the MVP grows in functionality it grows into a product it can move from an early adoption phase to one that allows you to monetize the product. Since you have been putting your product into production from the very start, there is no worry that a release will fail upon launch as you have been launching your product from day 1.
Lean Engineering and the Cloud
Lean Engineering works best with a small highly motivated cross functional teams. The goal is to deliver high quality, valuable software in an efficient, fast and reliable manner through automation and increasing release cycles. Using commercial cloud platforms they can create a highly automated on-demand process to iterate quickly through the Build-Measure-Feedback loop, incorporate into their Continuous Integration and Deployment Pipeline processes and leverage built-in analytics tools.
Commercial cloud platforms provide push button infrastructure and common application and data services. By taking advantage of these services, developers can focus on the aspects of their solution that provides real value to their customers.
Lean Engineering is the application of Lean methodology for the delivery high quality software at low risk. It incorporates ideas from Lean Manufacturing, Lean Startup and Continuous Delivery. Special thanks to Jez Humble who has been very influential in the field and who is at the forefront of evangelizing these ideas.
The Lean Startup, Eric Reis
Lean Enterprise, Jez Humble, Barry O’Reilly, Joanne Molesky
Continuous Delivery, Jez Humble, David Farley