Welcome

I remember when this whole agile methodology (Agile) thing hit several years ago. Project managers began spouting crazy new terms such as sprints, scrum, waterfall, and stand-ups. I'm not a fan of corporate buzzspeak, but Agile has brought a whole new hellscape into focus for those involved in so-called operations. Operations groups include system administrators, database administrators, cloud engineers, network administrators, and the like. We are the people who support systems and services. We are the ones who keep things going. We have hands on keyboards and are the folks in the trenches. In corporate speak, we are responsible for business continuity and day-to-day operations. The last thing we need is another pointless meeting – especially a daily meeting.

Agile might work well for managing the rollout of a new application, codebase, or something related to software development. Keeping close tabs on developers and their progress toward hitting deadlines is wise, but for operations, it's another pain we must endure as lowly tech workers. We have real-time chat services such as Microsoft Teams or Slack that keep us in continuous contact with coworkers. Ours are days driven by interrupts and constant collaboration. The need for a formal meeting to track daily progress is as useful as an intravenous drip of bubonic plague.

For operations groups, Agile is disruptive, and it causes important support issues to be missed because of the daily pressures of having to present a line-item list of what we've done, what we're going to do, and anything that might block us in performing those functions. FYI – my greatest block to productive success is the daily stand-up meeting, scrum call, or whatever you call it. If I'm in the middle of editing configuration files on multiple systems, I don't want a meeting to fall during my work. My connections time out. I forget what I've done and where. My momentum is lost. And for what? A meeting to tell everyone what they already know from watching their chat clients.

The many disadvantages outweigh any advantages Agile might confer. One of the glaring disadvantages is that success is difficult to measure. Reaching an arbitrary milestone is not a measure of success for operations personnel. We measure success by having fewer tickets to manage. Happy systems and happy users are our yardsticks, not calendar dates or lists of completed tasks. In support roles, a project has no clear destination or finish. Support is ongoing, such as patching, upgrading, performance tweaking, adding capacity, monitoring, user support, backups, and security. Therefore, the Agile project mentality doesn't work for our projects. Executive managers who take classes, attend seminars, or read about some new trend and then force it upon the unwashed masses would never acknowledge it, but they diminish productivity by adopting trendy programs such as Agile into the workplace.

Still, the Agile trend persists in operations. The old "beat to fit and paint to match" saying applies to the attempt to create a complete Agile workplace. It's a failure, but I get it. I understand the idea behind Agile for infrastructure operations projects. Your management wants an Agile workplace, and that's final; even if it doesn't work, you must make it work. I'm sure the most often quoted reason for implementing Agile in infrastructure projects is, "Hey, it works at Company X, so we're going to do it." I'll bet if you ask the good people at Company X, they'll tell you that it, in fact, does not work for them either. They tolerate it because they must.

Agile has one positive outcome, and that is it does keep infrastructure teams focused on the tasks at hand. Managing IT people is often compared with herding cats, and Agile helps harness energies into maintaining a course rather than have everyone go off on their own tangential paths and leave critical tasks half done; so, it isn't all bad. We should extract the positives from Agile and use those to move our projects forward. The projects and goals from Agile meeting notes could easily be incorporated into the very useful kanban boardswhere progress is visual rather than captured in meeting notes that no one reads. Trello, a web-based, kanban-style application, works quite well for infrastructure teams to maintain focus and proceed through tasks.

All in all, Agile methodologies have their place, but not in infrastructure projects. We should glean the positives from it and leave the rest behind. Sorry to cut this short, but it's time for my scrum meeting. See you next time.

Ken Hess * Senior ADMIN Editor