Why should non-dev teams work in iterations?

You know it just a bit too well – working in infrastructure (or anywhere else considered ”non-dev”) is spending a lot of your time handling incidents and putting out small fires here and there. In between that, you need to update and upgrade both software and hardware, and maybe some work with new technology finds its way in there every once in a while.

Since a lot of what you do is about handling the situation right here and right now, deadlines become quite hard to both promise and honor, unless they’re burning as bad as the incidents coming in. This is where the concept of iterative work comes in for non-dev teams.

The need for prioritizing

But if everything is on fire and everything is important, how do we manage our priorities? Do we choose to work with whatever we enjoy the most or with the client who shouts the loudest? Or do we simply make our priorities based on what we find first in our inbox since I, as the expert, is as suited as anyone else to make that decision in my part of the environment? Without a fixed scope with a clear time frame, it’s hard to predict our work for even rough estimates. There are quite a few different factors in the paragraph above that will be (if, at all) considered very hard, if not impossible to solve. I’ll go out on the limb and dare to say that we have plenty of options. In a few blog posts we will cover some simple mechanisms to structure your work in a way to make it more predictable and making it easier on your conscience to talk about deadlines. In the long run, we’ll also be looking at lowered numbers of incidents and problems.

Why iterations?

Within the Agile philosophy, we talk a lot about iterations. In combination with a close communication with the customer, it has proved itself as working very well in areas such as product development. Over time, it produces a better suited product, while minimizing the risk. Within infrastructure, a common concept is big monolith projects where the delivery cycles are long and different projects running at different speeds must coexist within the same pool of resources. When the same resources are working in multiple projects at the same time, large piles of post-its tend to become the number one information collections. In these conditions, both prioritization and project synchronization tend to lose precedence to simply just ”doing things”. Any things.

Iterations for non-dev teams

By splitting our long delivery cycles into smaller pieces, creating a shorter time horizon, we can focus on what is the most important (and right) thing to do right here and right now. Instead of having the ever-present tension of an enormous to-do-list towards some deadline months away, we simply narrow our scope to what we should be doing the next few weeks. Nothing more. To be able to frame in how much work we actually can accomplish and finalize within e.g. two weeks, we need to peel off and clearly define smaller bites of the total amount of work. This helps us to get a graspable overview of what actually will be done over the next weeks and when the scope is that small, prioritization becomes a lot easier, since you simply cannot choose to do everything at once. If you only have a few weeks worth of time, you are forced to really choose what is most important right now.

It is not incidents vs. iterations

”But, what about incidents?”, you say. We make time for those as well when we plan the iteration. Working in iterations is no silver bullet to making them go away, but with a fixed cycle we will also be able to get a more detailed overview on how many incidents we have and how much time they steal from our planned work, as we are now able to also see how much of the planned work we didn’t do.

The easiest way to get this going this is to start cutting the huge projects into smaller pieces. Try making them small enough to fit into just one iteration. It’s a great start. I think you’ll see that both estimates and prioritization for the smaller bites will become a lot more handy. Also, adding up the estimates for the smaller pieces is probably going to give you a better hint on the total time the project is going to consume, rather than estimating the whole enchilada at once.

Predictability is key in keeping a good track record and a healthy relation to our customer. When being able to plan in short iterations, we become more reliable, as our estimates (and promises) to the customer become more accurate.

Wouldn’t it be nice to practice this in a safe environment before going all-in on iterations with your organization?

This can be arranged! Join us in the brand new Agile Service Management simulation MarsLander (link to swedish page – contact us for more information in English).