This is the fourth post in a series exploring Lean thinking and DevOps.

In my previous post Increasing the speed of your DevOps teams I covered multi-tasking and large amounts of work in progress as two significant issues impacting the speed of work flowing through teams to customers. In this post we are going to cover another key reason work takes longer than it should; time lost due to work sitting in non-productive states.

This is the third post in a series exploring Lean thinking and DevOps. In this post I cover one of the reasons work takes longer than it should.

In my previous post Introducing Lean thinking to DevOps I showed how Lean thinking, particularly establishing a pull system through work in progress (WIP) limits, can fully align the delivery capability of your DevOps team(s) with the ability of business to accept change.

DevOps seems to be on everyone’s lips right now. It has surpassed Agile and become the newest and blackest of blacks.

The definition I’ll give it for the purposes of this blog is “…a lot of technical stuff done using strangely named products with the intent of creating a frictionless and smooth flow of value to end users”. I mean, Chef, Puppet, Git. Who names these products? Nevertheless, the important part of that definition rests in the last ten words; a frictionless and smooth flow of value to end users.

I kicked off our third 'Projects and Agile Community of Practice' event in early December with two teams of six participating in a 'work in progress' exercise. Each team had a timer, four project team members and a project manager. The four project team members were assigned a Greek character - Alpha, Beta, Gamma, and Delta. They had a backlog of 30 cards, where card by card each team member would put their specific colour sticky dots on spots on the card that referenced their character, before handing it onto the next team member. The project manager collected the completed cards (work) at the end of the line. Two rounds of work were completed.