Dealing with distractions as a DevOps

hourglass-620397_640

Being a transverse department, every DevOps must learn how to deal with issues. It’s a common pitfall that, embracing the agile philosophy, the team ends up accepting that word of mouth is a tolerable method to track or inform problems. Although having a chat can be a good initial contact, it has the potential to turn any work environment into a toxic one. Let’s take a look on practical approaches to avoid these productivity killers.

Prioritize business demands

Not every task is born is equal. Most ticketing systems allow to define a level of priority and/or impact when defining a concern or issue. Having a view that lists all these tasks sorted by their urgency will allow for easy dispatching of the most pressing matters. Solving an environment block does not have the same gravity for a standard regular feature on the beginning of a sprint than that very same issue when it affects a critical hotfix.

Learning where to relieve pressure is just another tool in the DevOps toolbox (and, actually, in any other department).

Timebox non-focus tasks

Set a maximum alloted time to deal with those tasks that do bot belong to the current effort. Chances are high that you will have to deal with obstacles belonging to any of the main DevOps branches (development, quality and infrastructure), but as a team you will also have your own goals and objectives. Make time for both internal and external issues, and obey these restrictions responsibly.

Reconcile with the idea that there will always be work to do

In my experience, developers and QAs that make the jump to DevOps have the most trouble with this point. Used to dealing with a small task backlog that is strictly defined on intervals, moving to a position where the focus can potentially change several times in a day can be stressful. The impact that small blocker tasks can be underestimated, and thus they can feel that their own effort is useless.

Learn to let go. You must be a reliable part of the team, dealing with your share of work. But that does not mean that you must overextend and take care of everything by yourself.

Educate your coworkers

And my last point will be about what can easily become the biggest irritation: the usually impatient workers that, finding their work blocked by difficulties out of their reach, buzz around waiting and hoping that you deal with it. They stop by, breaking your attention and demanding action. The following comic illustrates what they are actually doing when they come by your desk and request help:

Originally posted on http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/
Originally posted on http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/

I am actually using this strip to let them know what happens when they interrupt us without a genuine cause. In a nonchalant way, we must strive to teach them to follow the usual procedures, without letting us being dragged down to the inflexibility of bureaucracy. Talk to your colleagues, and let them know when and what is acceptable, putting emphasis on whether the impact of the issue is worth it.

In conclusion, learning how to manage your own time to help others is as much important as knowing how much time you must set aside to perform other duties.


Originally published at Álvaro G. Cachón.