Methodologies and morale: prioritising people

Last month, Tim from Timlah’s Techs sent me a link to a blog post.

You can get a feel for it immediately from its title: I Will Fucking Haymaker You If You Mention Agile Again. Published on the Lucidity site in October, it discusses several issues with the Agile manifesto using a great deal of common sense that’s really refreshing.

Although my background is in IT service management (ITSM) and the ITIL framework, I took a brief career detour and decided to try my hand at database engineering for several years. Towards the end of that period, a new Chief Information Officer (CIO) joined the company and employed a coach to convince the operations teams to adopt more Agile ways of working.

My time spent in the database team was an eye-opener. Tuition from a great developer cultivated a love for Structured Query Language (SQL). I discovered how bureaucracy can kill enthusiasm for improvements and prevent anything from progressing at faster than a snail’s pace. I realised how much I missed ITSM and wanted to return to it. And I also saw that forcing a framework on a team which doesn’t suit them is a very bad idea.

When my company announced that it was looking for a consultant to help with a particular project, it was a way back to my roots so I told them I could do it. That was how I left databases behind in November last year and transferred into the role of Service Management Improvement Lead. The CIO arranged a meeting not long after I started because they wanted to hear about my plan for the work. Their response when I mentioned several ideas was: ‘Forget ITIL, what you should be concentrating on is DevOps.’

I spent the next couple of months updating my existing certifications and studying for a DevOps Foundation purely so I could prove them wrong. And indeed, my opinions in connection with these frameworks hasn’t changed since gaining this additional qualification. DevOps, Agile and ITIL work most effectively when they’re seen as complimentary; but at the same time, it’s vital to maintain a pragmatic outlook. Rigidly implementing an entire framework is pointless if only parts of it make sense for your teams.

This is a longwinded way of saying that, although I have some experience, I’m no expert and still have a lot to learn. But I’ve seen how senior managers’ fixation on methodologies can be harmful for both the productivity and morale of their staff, and feel that we’ve lost the original community aspect of DevOps in our desire to jump to tools as solutions rather than truly understanding the problem. This is why I connected with the views raised in the article on the Lucidity site and forwarded the link to several friends.

The range of responses I received was insightful. Some agreed with a lot of the author’s points, particularly their thoughts on stand-ups. To sum it up: ‘Which absolute fucking maniac in this room decided that the most sensible thing to do in a culture where everyone has way too many meetings was schedule recurring meetings every day?’ Having to attend what should be a 15-minute session at 09:00 every morning, and then watching it turn into at least 30-minutes while someone goes off-topic, really isn’t fun.

On the flipside, there were those who disagreed. They felt that the author’s opinion that people should just be allowed to communicate whenever they needed was hypocritical, considering their article gave the impression that they clearly hate the idea of colleagues who might need to talk to them. One person said that they thought the writer needed to find some teams which weren’t led by morons. Unfortunately, I’m not sure that most of us have ever had the pleasure of experiencing that.

This leads me on to the point of my post. The responses received from my friends seemed to be an indication of two things. The first was how well Agile and DevOps is being run at their companies, with those who generally disagreed with the article mentioning good Scrum Masters and Project Managers who keep everything ticking along smoothly. The people in these roles manage the organisation of the backlog and contact with the customers, so everyone else can get on with actually doing the work.

The second indication was the type of IT job my friends held. Those mentioned above are all software engineers and developers, while those who agreed with the Lucidity article work in IT operations. It has always seemed to me that people with operations backgrounds are far more likely to be negative about the methodologies because they don’t take their whole workload into account. ‘We just sit around waiting for the development team to give us something to do, right? Let’s ignore the other 100 support requests we’ve received today!’

Considering that DevOps was created to improve collaboration and communication between teams (the clue is in the name), this isn’t a positive outlook. Stories like mine show that a massive disconnect between development and operations still exists even with its introduction. Agile and DevOps began in the 2000s through a desire for cultural change. It’s funny how CIOs and coaches now overlook this aspect though in favour of the shiny promise of streamlined teams and faster results (read: profits).

As mentioned above, it feels like we’re slowly forgetting the community aspects of these methodologies. DevOps has turned from a cultural shift into a role and tool, with companies such as Microsoft now offering applications which can apparently do it all for us. They cause us to lose sight of the people involved in the processes. Individuals who, as explained by Lucidity’s author, just want to go to work, talk to their colleagues when they need to and fix problems with other smart people.

So that’s what I’m going to do: focus on the people. It doesn’t matter whether you choose ITIL, DevOps, Agile or any other stupidly-named methodology, your teams and their morale are always the most important element. It’s far better to use common sense and implement processes which work for them. For the record: rigidly sticking to a one-size-fits-all framework is never going to solve all your problems, and nobody likes being dragged into daily 09:00 stand-ups when there’s something else they could be working on.

When I redesigned Later Levels, I realised that I wanted to expand the topics covered on the blog and occasionally write something more related to my day-job. It’s taken me over a year to gather enough courage to do it but the first post has finally been published. I must admit though, I’m a little nervous that someone might actually leave a comment below as I’ll then have to reply and risk exposing my ignorance. I kindly ask you to be gentle if you decide to share your thoughts.