Wednesday, March 2, 2011

Leveraging Agile Principles in IT Operations: Part 1

Individuals and Interactions over Processes and Tools

Agile Overview

“Agile” refers to a set of methodologies that focuses on iterative and incremental software development, emphasizing collaboration between cross-functional teams. I was recently asked by a CEO to explain the value of using Agile principles in IT operations, a group that doesn't typically embrace Agile tools and processes.

At its foundation, relating Agile to IT operations rather than to the development world, where Agile was founded, means understanding the differences between the needs of a group that follows a pattern of planned work (software development) and a group that is largely interrupt-driven (operations).

The Agile Manifesto lists four main precepts:

  • · Individuals and interactions over processes and tools
  • · Working software over comprehensive documentation
  • · Customer collaboration over contract negotiation
  • · Responding to change over following a plan

In this series of blog posts I will discuss how each precept can bring value to the responsibilities of your IT operations team.

Traditional Frameworks

When seeking an organizational approach, there are compelling reasons behind constructing an IT department using an ordered framework such as ITIL or MOF. This approach locks the team into a safe, prescriptive approach that is hard to fault. It reduces the need for personal judgment and critical thought while defining roles and responsibilities, offering a clear trail for audits.

However, there are associated drawbacks. Frameworks don’t foster creativity. They’re often top-heavy, requiring a great deal of time and effort to implement and maintain. Additionally, overlaying a framework on a disorganized IT team won’t create useful process and can bog down the team when implementing the framework, rather than providing structure for the department, becomes the goal.

Structured frameworks also fail because they don’t foster continuous improvement. Even though root cause analysis is often included within the framework, the step that remediates the root cause and creates process improvement is frequently not addressed. Thus the value of understanding the root cause is lost.

Individuals and Interactions

Fortunately, you can reap the benefits of a structured framework and create opportunities for continuous improvement in your IT operations team by following Agile’s first precept: individuals and interaction over processes and tools.

The processes and tools that your IT operations team uses, including the organizational framework, should be driven by the team’s values rather than the desire to watchdog productivity. Focusing on individuals and interactions puts a framework into perspective; it becomes a set of guidelines that support the team rather than setting the framework itself up as the goal.

The concept of individuals and interaction over processes and tools also forms a philosophical stance for the management of teams. Trust your IT team. Many IT people are intelligent, internally-driven professionals who want to find ways to improve department processes and customer service. If you don’t trust your team, get a different team, either by getting different people on the bus or by shifting yourself to a new bus. Using processes and tools to lock down the behavior of team members as a substitute for trust can be disheartening for teams and is an ineffective management approach.

Looking Ahead

In part 2 of this series I will address the second precept of the Agile Manifesto, working software over comprehensive documentation, and discuss how it applies in an IT operations environment.

Jen Browne and Patrick Phillips


  1. Very interested to hear feedback on this from those in the IT sector. Good article.

  2. I strongly recommend those curious about lean and agile methods investigate Scrum. Scrum is a tightly controlled--yet highly adaptive--software methodology that reduces risk, cost, design-phase bloat, while ensuring a visible end product is always within weeks of deployment. Scrum teams often achieve several times the productivity of traditional "Waterfall" methodologies.

  3. I find your concepts intriguing, though having to deal directly with regulators and external auditors, straying from a framework or "trusting" employees, especially in the financial services industry, can increase unforeseen risks that may result in material control deficiencies. There's a reason why ITIL and Cobit have become so popular, and I have yet to see a properly implemented universally accepted control framework criticized by regulators.

  4. DrZ... definitely. As a certified Scrum master, I've seen the benefits of the methodology first hand. Scrum techniques can be used in IT operations projects, too, but the actual processes shift slightly to accommodate the unique needs of the IT operations group. Might be a good topic for a future blog.

    Anonymous -- thank you for pointing out the reason we need frameworks. I have been successful in using Agile techniques and a modified ITIL framework as described above in both PCI and Sarbanes-Oxley groups but I haven't used it in the financial services industry or in HIPAA-controlled environments.

    It's good to remember that whatever approach you choose in your IT operations team meets the requirements of the specific business.

  5. I a using mixed agile and traditional (waterfall without the command and control) for implementing the HIPAA 5010 EDI regulations at a very large Health Insurance company. It is a modified structure as the general scope is not flexible, however the implementation of said scope is flexible. so the WHAT remains but the HOW changes. Check out my blog for more on the topic, I have 5 Scrum Teams, 2 week sprints, massive sprint demo/reviews. There are 100+ people not including the UAT team.
    We have about a dozen fixed testing milestones where we MUST be done with certain features in order to test with our trading partners (other insurers and clearing houses). Feel free to reach out to me if you want to know more.
    Joseph Flahiff

  6. Joseph -- it sounds like an intriguing implementation. I'll check out your blog!


Popular Posts