Leveraging Agile Principles in IT Operations: Part 4

Responding to change over following a plan

Agile Overview
The last post in this series discussed customer collaboration over contract negotiation, focusing on ways to foster collaboration between IT operations and internal customers.

This week's post will outline a possible approach to the fourth precept of the Agile Manifesto: Responding to change over following a plan.

Agile Systems
When discussing IT operations, we can look at implementing Agile culture and practices within the team or making the infrastructure itself Agile. Throughout this series I have focused on the people in IT operations. This article will continue that pattern.

However, there is tremendous value in looking at Agile infrastructure ideas. For more on that topic, see what Andrew Shafer has to say at http://stochasticresonance.wordpress.com/.

Andrew and Israel Gat also carry on an interesting conversation on The Agile Executive site at http://theagileexecutive.com/2009/07/17/agileexec004/.

Define the work
IT operational work can generally be divided into two categories: interrupt-driven and project-related. The bulk of the work is interrupt-driven, so team members are forced to constantly re-prioritize and context-switch throughout each day.

However, responding to change is not the same as disorganized or chaotic focus-shifting. In many IT operations teams, the interrupt-driven work is re-prioritized on the fly based on gut instinct, or driven by who is yelling the loudest or who happens to be standing next to your desk demanding results.

Quantifying the work your team does and creating processes to prioritize and order the work will give your team a foundation from which it can respond meaningfully to change.

Lay the foundation
Start by base-lining the amount of interrupt-driven vs. project work done by your IT operations team. Use this information to kick off a planning cycle, similar to Sprint planning that is done by software development teams.

Knowing the amount of time you have available to dedicate to project work will help with planning accuracy, particularly after your team goes through a few planning cycles that include basic time tracking. I suggest starting with a 4-week Sprint cycle with daily, 15-minute standups.

Track your time
Solicit your team’s input on how it can estimate and track both types of work in a meaningful way. This can be quite granular if your team already uses precise time tracking, but a precise time-tracking approach can be burdensome to IT operations teams, when the bits of work take less time to complete than to record.

One suggestion is for team members to offer estimates of their previous day’s project vs. interrupt-driven work during a daily standup. These estimates can be graphed and mapped against the amount of time the team forecast as available for project work during planning at the beginning of the Sprint.

Define meaningful chunks of time
Another useful planning tool is to determine meaningful chunks of time that team members can regularly dedicate to IT operations project work. Agile development teams sometimes use “ideal days” to talk about time they can dedicate to project work. They assign ideal days to tasks, determine how many ideal days they have available during the Sprint based on vacation, mandatory meetings, etc., and are then able to forecast the tasks they can complete during the Sprint.

Because of the massive amount of interrupt-driven work in the IT operations department, ideal days typically aren't applicable. As a team, decide what a meaningful chunk of time might be in your organization. Half days? Two hour blocks? Something else?

Understanding these meaningful chunks of time will assist in more accurate planning and help the team tell its story more clearly if tasks aren't completed within the planning cycle. It will also help IT operations management make better decisions, such as staffing decisions, and when to introduce new project work to a Sprint.

Sprint planning
During Sprint planning, use your baseline numbers to lay out the project time available for the Sprint and divide it into meaningful chunks of time for each team member.

Let’s say a meaningful chunk is decided by the team to be 2 hours. Team members could then estimate how many of these 2-hour chunks might be available during a Sprint, based on their calendars, and assign the chunks of time it would take to complete each task in the current Sprint’s backlog.

Breaking down tasks by time and then only taking the number of tasks that fit into the time each team member has available for project work during the sprint will assist planning accuracy. It will also help the team be realistic about forecasting the number of tasks it can tackle per Sprint, reducing the incidence of IT operations projects that drag on and on with no recognizable progress.

Task development
Part of Sprint planning includes breaking down stories into tasks. These tasks should be the smallest feasible meaningful slice. Knowing your team’s meaningful chunk of time will help determine the smallest meaningful slice of work.

Additionally, if a task’s time can’t be estimated, that’s a good indication that the task is too big or includes too many moving parts. For example, many times I've heard team members tell me that they don't have any idea how long a task will take because they haven't even started researching the solution. Slicing research time off of the resulting work and making research its own task can help with time estimation.

Responding to change
So far, I have emphasized the planning part of “Responding to change over following a plan.” You might be wondering where the flexibility comes in, but the foundation of a defined process will help your team respond meaningfully to change.

Once the IT operations team has a good idea of the project work forecast for the Sprint, the amount of time available during the Sprint to dedicate to project work, and the prioritization and ordering of those project tasks, team members can make educated decisions for responding when things change.

Identifying and prioritizing change
I don’t recommend Sprints shorter than 4 weeks because of the high cost of set-up and tear-down per Sprint and because shorter Sprints increase burnout. However, priorities in IT operations often change on a weekly basis. This means that Sprint forecasts in operations will be more flexible than forecasts in development teams.

One approach to identifying and properly prioritizing incoming changes is to have a weekly meeting with IT team leads that evaluates requests for change against planned project prioritization and ordering and brings appropriate changes back to the team. Although this would impact planning reliability if the team were basing reliability on tasks, having the operations team base reliability on the amount of time spent working on projects vs. the amount of time planned to work on projects mitigates this issue.

Additionally, having a process in place to field incoming project requests or changes shields the team from the kind of whiplash that often exists in an IT operations organization.

I recognize that this approach still leaves us with interrupt-driven change, which I will address in a future blog post.

Listen to the team
As you dig into the best way to keep project work moving forward in your interrupt-driven IT operations organization, remember that the answers to any process problem exists in your organization. Involve the team in any changes you decide to make. I'm continually impressed with the mature, thoughtful responses I hear when I ask teams what they would do to improve.

Summary
This series focused on applying the four values of the Agile Manifesto to IT operations:

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

As you apply Agile values and practices in your IT operations group, keep in mind 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).

Presenting the concepts to your IT operations team and asking for their input on how to successfully apply Agile values and practices to their activities will create the most successful path to implementing Agile in your IT operations organization.

Jen Stone Browne
@jenstonebrowne

Leveraging Agile Principles in IT Operations: Part 3

Customer collaboration over contract negotiation 

Agile overview 
The last post in this series outlined an approach to creating meaningful documentation. It leveraged the Agile concept of maintaining working systems over comprehensive documentation, starting with identifying how an IT operations team would use the documentation to support its regular activities.

This week we’ll look at the third precept of the Agile Manifesto: Customer collaboration over contract negotiation. 

Identifying the customer 
IT operations organizations can support internal customers, external customers, or a combination. This article will focus on IT operations departments which support only internal customers. 

When your customers are internal, identifying them can sometimes seem difficult. For example, IT operations teams often identify the CTO as their customer, while others point to their company’s development group. A simplified approach is to include as a customer anyone who comes to your team for any of the services your IT operations team provides. 

Customer contact 
Larger, more established companies typically create standard processes by which internal customers may approach the IT operations team for services, often filtered through the helpdesk. Smaller, less structured or startup-type companies generally have a more casual approach that relies on various types of shoulder tapping or other informal methods. Occasionally, companies will embed IT operations resources within project or product teams.

Whatever engagement model your organization uses, it’s important for the model to be clearly communicated both to your IT operations team and to your customers. Your team needs to know how customers should contact IT operations and exactly what services the team can provide them. This knowledge will support the team’s ability to track and prioritize requests.

Customer communication 
Communication is the foundation of collaboration. When customers make request of the IT operations department, they want to know what’s going on with those requests, including:

• When will this be done?
• How can I track progress?
• Is there anything I can do to get my request completed quickly?
• If my request is rejected, do I have any recourse? 

Make sure you have a mechanism in place (automated, if possible) that clearly communicates the receipt of the request and the process that moves requests from one status to the next. Update the customer whenever the status of the request changes. Communicate delays when the request is stalled in a status for longer than the customer expects. 

Create a transparent prioritization process. Customers will be less likely to become antagonistic when their requests aren’t acted on immediately if they understand why other requests took priority. 

Contracts 
IT service contracts are used extensively by consultants and 3rd-party service providers. They’re valuable for defining factors such as time, cost and scope, and they set expectations. 

A contract is a legal binding between two independent and separate organizations that offers recourse should a disagreement occur. It can help two organizations define the roadmap of their relationship and provide details on the formalized components of the agreement.

Recently, I have seen a trend for organizations to establish IT service contracts between IT operations teams and their internal customers. A low-level type of internal contract is the Service Level Agreement (SLA). While I fully support the idea of establishing SLAs, since they can set expectations and provide a starting point for dialogue, following SLAs too closely or putting in place more elaborate contracts internally isn’t aligned with Agile tenets. 

Contract drawbacks 
Internal contracts aren’t Agile for a couple of reasons. First, they put up walls between IT operations and its customers. When one group within a company can stonewall another by refusing help because a service isn’t listed in a contract, it damages the customer (because of delays) and the relationship between IT operations and other parts of the business. 

Second, a contract limits collaboration and the spirit of teams. When the disparate divisions in a company realize that there is only one team and we’re all part of it, the productivity of the organization can increase dramatically. 

Additionally, internal contracts don’t align with Lean principles because they aren’t enforceable. If a breach of contract occurs, neither party can seek legal recourse. A process that lacks power is wasteful, particularly if the process also limits the work that can be done to support the customer. If an organization requires an internal contract to get work done, there are deeper issues that need to be identified and addressed. 

Customer interaction 
IT operations teams can use every customer interaction to improve its communication with and services offered to internal customers. Use both formal and informal feedback loops to understand what your customers want. Apply that understanding to close the gaps between the service your IT operations team offers and the support your customers need. 

For example, most IT operations teams are familiar with people who always seem to be asking for something beyond the standard available, like a fancy laptop, rogue server, or unsupported software. These are often the same people who seek help outside the regular support process. Rather than dismissing such individuals as high-maintenance, use them as indicators for where gaps exist. What need might be driving the people to seek something outside the norm? Does this need exist more broadly across the organization?

Saying no 
Of course, there are times that the IT operations team must say no. Processes and standards help reduce setup and maintenance work, keep our organizations within regulatory and security guidelines, and help us correctly prioritize work. How we say no to our customers is often the difference between putting up walls and collaborating with our customers. 

Customer collaboration 
True collaboration occurs when IT operations seeks input from its non-technical customers. Create opportunities for your customers to feel they have been heard. Make sure they feel that their needs matter. Let them be involved in decisions surrounding the hardware and software they will be using daily. 

For example, you could offer new hires the choice between a desktop with two monitors and a laptop with one external monitor. Try setting up a panel that draws from cross-functional teams to offer feedback and recommendations on software choices, particularly when changing applications that are used by everyone in the company. You might even hold regular IT operations retrospectives in which you invite your customers’ input. 

Looking Ahead
In part 4 of this series I will examine how the fourth precept of the Agile Manifesto, responding to change over following a plan, supports an IT operations environment. 

Jen Stone Browne 
@jenstonebrowne

Leveraging Agile Principles in IT Operations: Part 2

Working systems over comprehensive documentation

Agile Tenets

My last post described how your IT operations team can reap the benefits of a structured framework such as ITIL while recognizing opportunities for continuous improvement using the first Agile tenet: emphasizing individuals and interaction over processes and tools.

This concept is based on two supporting ideas: first, effective communication should be the primary focus of an IT operations team, and second, the processes and tools that your IT operations team uses, including the organizational framework, should be driven by the team’s needs rather than the desire to watchdog productivity. 

This post looks at the second precept of the Agile Manifesto: Working software over comprehensive documentation.

Although software is integral to the work of a site operations team and some members of the team are often required to code as part of their daily activities, creating working software is not the primary function of an IT operations team, so we’re going to modify this precept to reflect the core competency of IT operations: Working systems over comprehensive documentation.

Working Systems

A common statement in the Agile community is “the left over the right,” meaning that in each Agile tenet, both halves are important, but the focus is on the first half. When applied to “working systems over comprehensive documentation” this means our focus as IT operations teams should be on maintaining working systems.

Maintaining working systems is the core competency of any IT operations team, and there is a lot of information available on how to do just that, so I’m not going to dig into it here. Keep in mind that, although the left is more important than the right from an Agile viewpoint, the right is important, too. It just has to be kept in perspective against higher priorities.

As a result, I’m going to examine how to add documentation to the regular activities of an IT operations team. It’s rare to have the luxury to build systems and documentation together from the ground up, and IT operations teams commonly feel understaffed. Often, they feel that they are scrambling just to have working systems in place, much less finding time to document them. When deciding between the two, working systems should take precedence every time.

Documentation Challenge

If you want to provoke a negative emotional response in your IT operations team, tell them to spend more time on documentation. Documentation isn’t fun. It’s hard to know how to begin assembling it. Documentation takes away from the time your team can devote to deploying, fixing and maintaining systems. It’s not typically the strongest skill in an IT professional’s toolkit.

On the other hand, meaningful documentation can save a significant amount of time when troubleshooting. It can foster knowledge transfer. It speeds the learning curve for new hires trying to find their way around your systems. Documentation can be integral to a good disaster recovery plan.

Given the advantages and drawbacks to documenting your systems, how can you find a reasonable approach to creating the documentation?

Meaningful Information

The primary difference in the Agile approach to documentation lies in understanding the distinction between comprehensive documentation and meaningful documentation. Meaningful documentation supports your team’s needs.

Lay the groundwork for creating a culture that embraces documentation by discussing how your team would use different types of information. What drivers make documentation valuable to your team? As a group, determine what you need to document and why. This will generally come down to four key ways the knowledge will be used:

•         Reduce troubleshooting time
•         Share knowledge
•         Onboarding
•         Support disaster recovery

If your team members recognize the value and purpose of documentation, not just as a general philosophy but as a meaningful tool supporting their daily activities, the team itself will start driving the effort to create and maintain documentation.

Document as You Go

It’s not practical to drop the regular work of an IT operations department and go on a documentation spree for a week. For one thing, everyone would take the week off. For another, knowing where to start documenting is a daunting proposition.

Instead, document as you go. Refer back to the ways your group will use the documentation as a guideline to creating it. For example, when a team member is working on a standard tasks – deploying, fixing, maintaining – use the opportunity to look at the system from a documentation standpoint as part of that task. If the team member were to hand off those tasks to a new colleague, what would that colleague need to know to get those tasks done?

Getting started

Reduce troubleshooting time

One way to create documentation is to embrace failure. When your systems fail, use the opportunity to strengthen them, address the root causes, and document both the fix and the new, stable state. This can support future troubleshooting efforts while creating training material.

Share knowledge

The intricacy of modern IT operations means that individuals are forced to specialize. Your team members can’t be experts on every aspect of your systems. This means that even senior, well-established team members will have to ping colleagues for answers about systems as part of their regular work. If you have meaningful, readily available documentation that is easy to access, team members will interrupt each other less often, leading to greater productivity across the team.

Onboarding

Understanding the complexities of an organization’s systems can be the longest pole in getting a new team member up to speed and performing. If that organization can supply new team members with meaningful documentation, velocity increases for that team member and the number of interruptions fielded by existing team members from questions the new team member might ask will drop.

Expanding on that thought, use the opportunity of onboarding new hires to create the documentation that is missing. As new team members are taught the system by their more experienced colleagues, they can document the information they are taught and then have it reviewed by the person teaching them.

Support disaster recovery

Disaster recovery generally requires the most detailed, comprehensive documentation. This falls outside the “document as you go” method, requiring a dedicated project and maintenance plan to be effective. However, if you have meaningful documentation in place, it can provide a springboard into the disaster recovery plan.

Summary

Understanding how documentation can support your IT operation team’s needs guides team members in creating and maintaining documentation that is meaningful to the team.

Looking Ahead

In part 3 of this series I will examine how the third precept of the Agile Manifesto, customer collaboration over contract negotiation, can be implemented an IT operations environment.

Jen Stone Browne

@jenstonebrowne