The First Way of DevOps puts a huge emphasis on the flow of work, which factors in a timeline, a roster of leads and subject matter experts, and a work path with clearly defined roles, tasks, and expected outcomes. This is the basis for establishing work expectations, as well as what the outcome of the work must be. These things are the underpinnings of work visibility – the way in which performance and quality are driven by ownership and accountability.
The First Way aims to solve the problem with invisible work, meaning to say it aims to organise the work process, so that everyone in the organisation knows what their role is and the scope of their work. This is the way to establish a beginning and an end for a task, a stage, or a phase, and where each of these endings should connect to, in order to trigger work for the next step in the process. Showing this in a stream of steps, as in a value stream map, can effectively answer the proverbial question, “who’s turn is it now?”
This question is quite difficult to answer without a work map in place. A value stream map is what makes it possible to specify, quatinfy, and measure work that is difficult to do so due to its intagible nature. Without any sort of visual representation for work and time, it’s almost impossible to accurately assess or observe work productivity and efficiency levels, making it difficult to identify problem areas that can hamper or slow down progress.
The importance of making work visible
There will always be dependencies at work, and unknown dependencies are one of the major culprits that hampers the progress at work. Hand offs are the usual problem points, when receiving teams are unaware of the work that the handing off teams are sending their way. This creates a gap that lengthens lead times which results to time wastage.
To solve this problem, we have to make the invisible work, visible. We do this by tapping into our nature as visual observers, using tools like Kanban Boards that make use of physical representations of all of the work involved in a project, and using assessment methods to identify the weak points and problem points on a team level and on an organisational level; everyone needs to see the direction they’re supposed to go, how to get there, and who to go to.
The first step in making work visible: An honest to goodness internal assessment
Before laying out that value stream map and putting up that visual board to make the work visible, teams need to put a pause at work and perform an honest to goodness evaluation of the real and actual situation at work. Putting down the accurate number of projects in the pipeline, the work in progress, and the amount of time lag is the first step in making the work visible. Through this exercise, unseen dependencies as well as conflicting work will all come to the surface and teams will be able to tackle this area much better, because now they know what problems they need to solve and how to solve these.
The second step in making work visible: Create a visual representation of the entire work
This is the point where unseen dependencies and unplanned work are most likely going to surface, and where teams can actually see what the real situation at hand is. It may be difficult to accept the reality that this exercise brings, but it’s a necessary step in putting things in a fresh perspective. This shifts the focus on getting the WIPs down, and giving teams the real amount of work they have at the moment, so that they can decide whether they can take in new work or push back until they have reached their acceptable level of WIP. This is a form of control in the flow of incoming work; if teams keep saying yes to more than what they can actually accomplish within a specific amount of time, their optimism is only going to lead them headlong into a huge technical debt.
By using a visual board, like a Kanban Board with swim-lanes for to-dos, WIPs, and post-release activities, everyone can see clearly where the time is going, as well as what speeds up or slows down the work. Each task must be written down on a sticky note, so that it’s easy to move it from one lane to the next. It’s equally important to have a DONE column and a COMPLETE column. While these words sound synonymous, in software development, they can mean two different phases in the development life-cycle.
Another way to substantiate testing and maintenance work is by using a maintenance card system. This keeps maintenance work down to a manageable level, as consistently checking for errors and performance levels will help in the early detection of possible issues, before it becomes a major problem.
The third step in making work visible: Release work in chunks to make everything manageable
Deploying work in small chunks is actually more effective and time efficient, as it is easier to manage, fix, and accurately document the work. The benefit of smaller deployments is that it is easy to pinpoint the problem in case an issue occurs after a deployment or when a new feature goes live. Small batches of work are also quicker to work on, thereby increasing the speed of the flow of work. In effect, hand offs are also quicker and more manageable.