IT projects often fail, or at least cause a lot of headaches, for a number of reasons. First, a multitude of people approach the operative staff, each with their own ideas of how their individual projects should proceed; however, they all agree on one thing: Their project must be handled urgently. Projects are initiated by almost every part of an enterprise (e.g., marketing, product management, personnel), and, of course, no project is unimportant, so the people responsible expect the operations team to give their project top priority. When all projects are supposed to receive preferred treatment, the admin is left to solve the resulting unavoidable conflicts.

Second, internal projects necessary to ensure stable operation of the IT infrastructure and equip it for the future need attention. Backup systems must be scaled up, monitoring must keep up with an ever increasing number of checks and metrics, and the admin might have a long-hedged wish to introduce a configuration management utility like Puppet or Chef. However, a plan to reserve manpower for these internal tasks usually harvests about as much approval outside of IT as a proposal for a week-long department excursion.

Third, the situation is made more complicated by the large spectrum of responsibilities that fall under the "operations" roof. Layer models like ISO/OSI graphically document just how far the work of a network administrator is removed from that of a database manager. But the diversity is great even on the same layer; you only need to think of Apache and nginx, Varnish and Squid, MySQL and Oracle.

Finally, one of the most important differences between a software development team and an operations team is the amount of unplanned work. Every problem that interrupts normal operations means that one or more admins gets torn from their planned tasks. Unfortunately, such interruptions are frequent.

The Big Picture

All this has a large effect on daily processes. With insufficient staffing, the team must juggle a multitude of tasks, leading to more tasks begun than can be completed and personnel shifted to deal with unplanned incidents.

Under such circumstances, the admin needs an overview of all projects: who is working on which task, which projects are on course, and which projects are threatening to derail. Without this information, neither operations nor the company can plan ahead.

Often admins cannot even answer the basic question: What is my next job, and when can I start working on it? The answer usually comes from outside the team, which dampens job satisfaction and prevents the Ops team from utilizing its resources optimally.

The Agile Solution

More than 10 years ago, lack of capacity, no overview, insufficient planning certainty, and general dissatisfaction lead software developers to depart from the established waterfall model and look for project management methods that allowed more agility. In the waterfall model, a product goes through the phases of planning and development to production and delivery. Mistakes made in early stages are often noticed only later, when the cost of correcting them are high.

Agile processes, on the other hand, focus on product fragments that are easier to handle and go through specific stages, either consecutively or simultaneously, making it possible to make corrections or even radical changes when the costs are relatively low. The most prominent example of this model is the Scrum method.

As attractive as such approaches as Scrum may be, it is a part of human nature to resist profound changes. Quite often, it is this resistance in an organization, sometimes on the part of management, sometimes from colleagues, that causes well-meant initiatives to fail.

Approaches that do without a radical break with the past and instead introduce gradual steps to improvement have a better chance of success. Every step then can be assessed individually and generate confidence.

Scrum

Many who have implemented Scrum [1] in IT operations teams have discovered that some approaches lead to improvements, whereas others cause problems, often because the work of development teams and operations teams is similar, but not identical. The daily routine of an admin differs from that of a software developer in some decisive aspects. This becomes especially apparent in the DevOps approach, which considers the entire life cycle of an IT product from conception to end.

In the area of IT operations, the distribution of different roles is not clear enough for the Scum method; for example, who is the owner of a Postfix cluster? Also, admins are jealous of the planning horizons of their development colleagues. Shorter and shorter deployment cycles are not a suitable framework for inflexible sprints, which do not allow changes to the concept on the one hand and threaten to cause idle time with timeboxing [2] on the other.