Recently I replied to a request for support from a colleague who saw me speak at the Itron Utility Week conference last October.
The request focused on how Agile principles can be used to strengthen an Operations team. Here are the highlights of my reply:
The SMNO (Smart Metering Network Operations) group borrowed the idea of the morning stand-up from Agile, and we take to heart the basic concepts of moving quickly on a series of small things and checking in with our stakeholders frequently.
Our Operations team holds a standup daily, to review what happened in the systems the night before, and ensure that any impacts are communicated to stakeholders. We also use it to identify any new actions or tasks, and we work those in as we go (since we’re not ‘delivering’ anything other than highest quality operations). Especially in the early phases of our operations, the standup helped us make sure we were paying attention to the right things, and responding quickly.
I think each team has to decide on a case by case basis whether ‘surprise’ work must be handled right away. Plot these things on the urgent vs important matrix, and keep a close grip on the Agile framework fundamentals to make sure that ‘urgent’ doesn’t drag you off course. Part of Agile is being willing to wait for things to unfold at the right time.
I have worked with many companies who wanted to do Agile, and who eventually ended up doing some percentage of it. True Agile software development requires real courage from the leadership, who cannot ‘manage’ features or timeline in the traditional way. This tends to make them deeply uncomfortable! So I’d advise to make sure that you are telegraphing the heck out of why Agile is so good, and what your leaders can expect to see.
Finally, if at all possible (and often it isn’t) don’t book people to 100% of their time. Agile (and indeed, any kind of development or invention) works best when individuals in a team have some breathing room, to have good ideas, clean up loose ends, work through problems at the water cooler, improve documentation, etc. It is a false economy (in my opinion) to focus on squeezing every last line of code out of each operator. Soon they will all be coding as fast as they can, just to keep up with their minor mistakes.