The DevOps Void & Value Stream Mapping Do you ever wonder why environment preparation or releases take so long? After all, the company just invested “zillions” on a whole bunch of great tools and a cloud framework. Tools that allow you to automatically provision your infrastructure, applications, data and ensure that all your security obligations are met. Hey! With this new” DevOps toolchain”, we should be moving our releases, from request to delivery, in a matter of minutes. You know … full pushbutton automation! … environments on demand! … And all that stuff! Yeah! Right! But no! That’s not how it typically plays out. In fact, a more realistic example might follow a storyline as follows: • Project manager raises a request for a SIT environment. • Request sits in it service management queue for a few days. • Gets approved & assigned by test environment manager & distributed to engineering teams. • Sits in the team ITSM queues for another few days. • Apps team build the package in 5 minutes, but can’t deploy as infra not ready. • Infra team provisions. • Test team can’t start testing as data not ready. • Data team provisions. • Sorry, testing now too busy with another test cycle. • Test teams spot a defect with the build. • Higher priority project comes along and acquires environment. • Go back to go. I think one gets the point, the issue with DevOps efficiency is rarely the atomic task. In fact (as illustrated in the diagram below), if you were to take a step back, you would probably realise the inefficiency is not in the operations themselves (like a build task) but in fact the “void” (or the wastage) in between.