Leveraging Agile Principles in IT Operations: Part 1

Individuals and Interactions over Processes and Tools

Agile Overview

“Agile” refers to a way of approaching software development based on four values and twelve principles. The four values stated in the Agile Manifesto are:

·         Individuals and interactions over processes and tools

·         Working software over comprehensive documentation

·         Customer collaboration over contract negotiation

·         Responding to change over following a plan

These principles have developed into a set of practices that focus on iterative and incremental software development, emphasizing collaboration between cross-functional teams. Because these principles speak to the relationships between people and the simplification of process, the Agile methodology has been expanded far beyond software development into almost any activity that requires people to work together.

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).

In this series of blog posts I will discuss how each precept in the Agile Manifesto can bring value to the activities 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 method 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.

Individuals and Interactions

Fortunately, you can reap the benefits of a structured framework while creating 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 up the framework itself 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.

Suggested Agile Practices

Some useful Agile practices you can easily institute in your IT operations team include holding daily standups, co-locating your team, conducting Sprint cycles with structured planning sessions and retrospectives, delivering Sprint reviews and identifying a ScrumMaster.

Daily Standups

I find daily standups most useful when they are held at the same time and place at the start of every business day. Daily standups provide context for the day’s work because they answer the following questions:

1.       What did we do yesterday?

2.       What will we do today?

3.       Are there any impediments?

A daily standup is not a status report. Rather, it provides a way for teams to understand general patterns of their work and to communicate work of an interdependent nature. It’s also a forum for impediments, creating a communication path from team members to the ScrumMaster.

Co-Location

Co-Location offers quick, immediate chances for communication. In an interrupt-driven department that often relies on inputs from more than one team member to resolve issues, co-location is ideal. Co-location also offers team member the chance to read non-verbal information and to develop dialogue, rather than the one-dimensional communication that tends to happen through email and messaging.

Sprints

Because operations teams are more strongly impacted by changing requirements than any other IT department, I recommend 2-week Sprints. The danger of driving at this pace is potential burnout, so be aware of the risk. (I’ll speak more to burnout in operations using Agile practices in a future post.)

Sprint Planning Sessions

Begin with structured Sprint Planning Sessions. These include the Product Owner (generally the IT director), Scrum Master, the entire Scrum Team, and other stakeholders as seems appropriate. The Product Owner presents the prioritized backlog (or top section of it). The team determines which items can move from the product backlog to the sprint backlog, based on available time and team velocity, and breaks the backlog items into tasks.

Sprint Reviews

Sprint reviews demo the work done during the Sprint. This isn’t a formal presentation and should never include things like PowerPoint presentations. Rather, the Sprint review provides the Scrum team the opportunity to share meaningful progress with the Product Owner, the Scrum team, the ScrumMaster, and anyone else who is interested in the work of the Scrum team.

This is also when the Product Owner checks the team’s work against the acceptance criteria. Knowing whether or not the completed the planned work of the Sprint allows the Scrum team to adjust expectations and become more adept at predicting velocity.

Sprint Retrospectives

After the Sprint Review is completed, the team should hold a Sprint Retrospective. Sprint Retrospectives drive continuous improvement.  During the retrospective the team evaluates what went well and develops a prioritized list of what could be improved. This valuable information should be captured and fed into the next Sprint planning session.

Summary

Introduce the Agile principles and get buy-in from your operations team prior to instituting the practices. When the team understands how Agile methodologies can support their work, they are more likely to embrace its implementation. Focus on team empowerment, increased communication and collaboration and Agile’s adaptive nature. This should increase your chances of success.

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 Stone Browne

@jenstonebrowne
http://www.linkedin.com/in/jensbrowne

Book Review: Orbiting the Giant Hairball

Orbiting the Giant Hairball by Gordon MacKenzie

One aspect of developing an Agile mindset is fostering creativity -- not always an easy practice when we're surrounded by rules and regulations and our days are chopped into almost unusable blocks of time separated by meetings over which we have little or no control. Feeling creative can be a struggle.

What is this all about?

Orbiting the Giant Hairball is a delightful approach to the sticky problem of cultivating creativity while dealing with bureaucracy.

David Rouse, Booklist, says, "A corporate hairball is an entangled pattern of behavior or a mess of bureaucratic procedure that discourages originality and stifles imagination." Fortunately, MacKenzie says that, although we can do little to reduce the hairball, we can use it to keep our creativity flowing while staying out of the hairball’s pull.

Inception

MacKenzie tells us about the generation of his idea for orbiting the giant hairball, rather than getting entangled in it:

"Desperate, I turned to fantasy and conjured a make-believe department that would be ideal to me: a creative-friendly oasis where it would be possible to thumb one's nose at empire building, ass covering, and all those other deterrents to fashioning vigorous concepts and fresh products."

Letting go

MacKenzie isn't afraid to get up close and personal when he tells us how to foster our own creativity. He says:

"To be fully free to create, we must first find the courage and willingness to let go: Let go of the strategies that have worked for us in the past... Let go of our biases, the foundation of our illusions... Let go of our grievances, the root source of our victimhood... Let go of our so-often-denied fear of being found unlovable."

What the hell? My victimhood? My fear of being unlovable? How dare you, Mr. MacKenzie! My confidence overrides your victimhood card! My… uh… well, okay. We all have inner demons of various kinds that can impact our ability to create. Recognizing them and letting them go, transcending the parts of ourselves that hold us back is a lesson that can be learned and relearned throughout our lives.

Creativity is Agile

MacKenzie also grasps a very basic tenet of Agile, "Individuals and interactions over processes and tools.” This becomes clear when he states:

"Holistic organization: form follows function (i.e. organization follows function) eg: Editorial and design are recognized as two elements of the same continuum and so remain integrated in a single ecology rather than hunkering down in separate departments. This results in an organic dynamism and the enhancement of collaboration."

Collaboration and integration are key elements of Agile and, simultaneously, key elements of fostering creativity. In many ways, Agile is a creativity methodology.

I recommend Orbiting the Giant Hairball to anyone who wants to increase creativity at work.

Jen Stone Browne

@jenstonebrowne

For more on creativity at work, Linda Naiman produces a great website full of immediately applicable ideas. You can see it at http://www.creativityatwork.com/.

Technical Debt: Consider Operational Requirements

Technical debt

The term “technical debt” has been popular for a while and has been used to refer to varying scenarios, not just in software development but across the IT industry. It was originally coined in 1992 by Ward Cunningham to help us recognize that quick and dirty work can set us up for increased future effort. One of the most overlooked forms of technical debt is created when operational requirements are excluded from the product development life cycle (PDLC), particularly in the project planning stage.

In many companies, operational support is not considered part of the PDLC. Operational and project teams are often completely decoupled at the lower and middle levels of the IT department, only dovetailing because both divisions report to the CIO or VP of IT.

The disconnect

This disconnect is created when communication is limited between IT operations and the rest of the business, including development. When the business defines objectives and timelines for a project with little or no interaction with the operations team, the operational requirements needed to support various projects are captured in an abbreviated form or left out entirely.

The project team might not even know that operational requirements exist until the code is almost ready to go live. It isn’t unusual for operational needs to be unearthed after code is deployed. Sometimes, these needs only come to light when issues are encountered because the existing infrastructure does not have the capacity to support the functionality or customer load created by the newly deployed code.

Case in point

I recently participated in an emotionally-charged meeting in which operations, development and business stakeholders discussed the root cause of the failure of a client-facing system. The project team was angry with the operations team for not supporting their code in a highly-available (HA) environment. The operations team was defensive, stating that they didn’t have the time or resources to address their backlog, including building an HA environment.

The project team had specified an HA environment in their runbook as part of their handoff to IT operations but the business didn’t prioritize the work against existing operational work. The HA system was acknowledged by the operations team as a requirement necessary to adequately support the deployed code, prioritized it and assigned the creation of an HA system to an operations resource, but the prioritization and operational timelines were not aligned with project milestones.

The HA system’s completion was not considered release-gating by the project team, so the code was deployed on an inadequate system and the project was declared complete. The customer-facing system failed and recriminations flew.

Unmet expectations

The project team expected their deployed code to be considered part of the production system, with accompanying up-time SLAs. The IT operations group was working on the HA environment, but didn’t have dedicated resources on the project, so its completion was a long, drawn-out process. The same people working on HA were also doing regular maintenance tasks, working on systems for other projects, and putting out fires.

The key point of failure in this conflict was in not consciously determining the value of the various requirements in the project. Although the work was in the project’s prioritized backlog, a good process wasn’t in place to prioritize the project work against other operational work or to align timelines.

Miscommunication

Miscommunication started right at the beginning of the project, when people from the operations team were not included in the planning process. It was exacerbated when the code was permitted to launch into a non-HA environment. It really snowballed when the project team went on to the next project without fully completing all requirements in that iteration of the product development life cycle. The operations team pushed code live without ensuring that all project requirements were completed, and then repeated the pattern over multiple releases.

After just a few project cycles, it becomes clear that the decoupling of operational requirements from business requirements within consecutive projects creates a backlog for operations that can’t be surmounted without drastic remediation efforts.

Finding a solution

Fortunately, this problem has a simple solution. It’s not easy, because it requires being realistic about the true time and resource demands of a PDLC. Paying attention to operational requirements can initially slow project completion rate or require the addition of people to your operations team.

Pay attention to three key points to prevent a buildup of technical debt as a side-effect of project work:

1. Make operational requirements release-gating.
2. Don’t launch on temporary environments.
3. Bring operations people into the project early and often. When possible, make them an integral part of the project team.

Projects are not complete unless the systems on which they live are complete.

Jen Stone Browne
www.jenstonebrowne.com

This post is a re-work of an idea I originally created for http://leantechnologytransformation.blogspot.com. Check out that blog for great ideas by Patrick Phillips, a skilled Lean and Agile practitioner and coach.

For more on technical debt, see what Israel Gat has to say at http://theagileexecutive.com/tag/technical-debt/.