Today, DevOps is the latest and greatest in making work efficient. Before that, Agile called on us to rework our development process. If we keep going back we eventually reach Frederick Winslow Taylor and the birth of scientific work management.
Taylor famously (or infamously) measured the time needed for every action in a production process. While degrading for workers, it was also effective. Taylor was able to pay higher wages because he made workers more efficient.
IT workers can't be "Taylorized"—they need to make decisions on their own, not mechanically follow a script—but the method of increasing efficiency by breaking work into smaller units still applies. Agile replaced the monolithic waterfall with the iterative unit of the sprint. The Phoenix Project draws strong parallels between the division of labor in a factory and in the software development lifecycle. Amazon's "two pizza rule" is another way of limiting scope to keep work units smaller.
When automation efforts fail, or fail to even get off the ground, over-sized work units are often to blame. This is a common complaint among people trying to implement DevOps ideals: automated build systems are feasible for green field companies but require too many moving parts for the enterprise to seriously consider them. Framed as an "all or nothing" work unit, automation is out of reach.
This is why some shops try to automate a little bit at a time. Doing it that way makes sense in the short term but ultimately results in a maintenance nightmare. An automation strategy needs to be comprehensive. Otherwise, each of your automations becomes another set of snowflakes to maintain. We know this happens because we often help clean it up.
One of the effects of gaining system visibility via UpGuard is being able to divide work into smaller units. Ian Buchanan, a Product Manager at VersionOne, started using UpGuard to standardize pockets of automation. After getting a clear picture of his build system he realized there was a lot of work ahead–much more than could be done immediately. Because Ian had visibility, however, he was able to divide up automation tasks into smaller units that could be completed without creating technical debt. Rather than kicking the infrastructure can down the road:
"UpGuard allowed us to 'chop the can' into smaller pieces so what we are kicking down the road is smaller. In other words, UpGuard enabled a more iterative and incremental solution. We don’t need to solve all of our configuration drift problems at once. The upside is that we started to solve some of our configuration drift."
The ability to actually get something done points to one of the less obvious virtues of smaller work units. Even if a given project takes the same total amount of time no matter how you slice it, being able to divide it into smaller work units gives you more flexibility in how you schedule that work. A project that requires 40 consecutive person hours is going to take longer to get on the roadmap than 40 one hour projects. Even if they both conclude at the same time, the smaller tasks completed first will have been creating business value the whole time you were completing the rest of the work. (This principle is one of the foundations of continuous deployment and modern finance.)
Breaking up projects into smaller units makes your time more efficient and your planning more flexible. System visibility enables you to know what you need to do—and that alone is a huge step toward effective automation—but it also lets you measure and predict that work with greater precision. Once you know what you have, you know what you need to do and when you'll be able to start.
Next article: You're Doing DevOps Wrong. Automation in the Enterprise