Fotolia
Is development time theft stealing DevOps productivity?
Is your project suffering from deveopmenht time theft, and is that time theft hurting productivity? Here we take a look at the most common ways time theft hurts DevOps productivity.
Dominica DeGrandis, Director of Training & Coaching at LeanKit, used her time on stage at DOES 2016 to talk about uncovering crime in the workplace. Her session, Time Theft: How Hidden and Unplanned Work Commit the Perfect Crime, described the most common ways that companies lose productivity and efficiency.
The talk was all about bringing these thieves into the light of day to be recognized and dealt with. The focus was definitely on the visuals in DeGrandis’ presentation. "There’s a reason our offices are plastered with whiteboards. We are visual learners." She used a series of charts and graphs to show how a typical DevOps team might surface the various time stealers that are impacting their work.
Five thieves steal time from software teams
According to Dominica, "There are five thieves that, if we could see and measure their impact, it could help us improve our performance, reduce our cycle time and be more predictable." The five culprits are:
- Unplanned work that starts small but can turn into big fires
- Neglected work that is important but gets benched by urgent work
- Unknown dependencies which tend to be very expensive in both time and money
- Conflicted parties with interests and priorities that are at odds
- Too much WIP (work in progress)
WIP leads the pack
In DeGrandis’ model, WIP is the most common and most dangerous thief, because it exacerbates the other four problems. "We see this when the demand on the team exceeds the team’s capacity. They are fully allocated at 100% resource allocation. People are troubleshooting on top of their full time job, and can’t get started on work until 6PM." This way of working leaves no room to deal with issues as they arise. It also leads to burnout. "I always say, ‘We don’t let servers get to 100% capacity, why do we do that with people?’"
Too much work in progress is a leading indicator of increased cycle time and the cost of delay. Teams can’t deliver because a new feature is added on or they are constantly context switching. Even something as simple as being asked for help by a colleague can have a snowball effect in an excessive WIP situation.
Dominica advises using a board that visually shows how much work is in progress so that accountability and transparency can go hand in hand. It’s easier to see what is competing for the team’s time when it is all out in the open. On such a chart, there might be separate lanes for "silver bullet" requests of high priority that come down from the CIO, the typical team work such as security and bug fixes, and business requests that have to do with revenue generating work. When everyone can see how much work is going on in each lane, it’s easier to prioritize and keep from overloading the team.
Unknown dependencies can kill a budget
This second thief is particularly likely to arise in projects that involve tightly coupled architecture. Other unknown dependencies could be a bottleneck from relying on a specialized skill set or work done by a third party that is not under the control of the internal team. In one anecdote, Dominica described one team making a deployment that completely broke another team’s product, costing millions of dollars and making end users very unhappy. This happened because the two teams simply didn’t talk to each other.
What’s the typical impact of dependencies? "They matter because every dependency increases the probability of starting something or late or finishing it late by 50%. Dependencies are asymmetrical in their impact." In other words the chances of something going wrong increases exponentially with each additional dependency.
Key indicators that dependency issues are going on include a high need for coordination or when a change in one piece of code unexpectedly changes something else. In part, the Agile methodology may be to blame since small teams require a high amount of cross-coordination to avoid these problems when collaborating across the business. "Small teams can move fast, but you pay a price of not moving fast as a whole organization."
Unplanned work is inevitable but reducible
This is a particularly pernicious time thief that is as demotivating as it is unexpected. "Failure demand is work based off of some kind of problem. It’s not associated with delivering something new and exciting that we can sell. It seems to come out of nowhere." This type of activity steals time away from work that’s creating value. According to one DevOps survey, high performers spend 11% more time on planned vs. unplanned work. In this way, lots of unplanned work may indicate lower overall quality.
Dominica said she can always tell when unplanned work is about the fan. "You know it is about to get out of control when someone joins your Slack channel and several more people get sucked into the vortex. There’s a lot of interruptions and context switching. If it happens frequently, chances are that thief is stealing time and predictability."
As with all time thieves, the solution is exposure. She encouraged audiences to find a way to visualize things that interrupt their day. Logging interruptions is important, even if it seems like just more work at first. "If it’s not tracked, there’s no evidence and it’s the perfect crime." Documenting unplanned work helps people can see it and understand why their stuff didn’t get done.
Seeing the crime is the first step to stopping it
This was the primary message from DeGrandis’ presentation: It’s essential to count and measure to see where time is going. If every DevOps team developed a "time thief-o-gram" to track where their time is slipping away, they could more easily change workplace behaviors and development processes to nip these crimes in the bud.
