Using Agile Tenets to Address IT Operations Challenges

Introduction

In previous posts, I outlined high-level ideas about how the tenets of the Agile Manifesto map to IT operation, including: 

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

Today I will offer a specific example of how a common IT operations challenge can be addressed using an Agile mindset in general, and the first and third of those Agile concepts specifically.

Circumventing the process

“If I need something from IT, I never submit a ticket. It will just go into a black hole. I go to John’s desk and get him to help me.”

Sound familiar? Circumventing the process in IT is more common than following the established procedure in many organizations. Does your IT operations department suffer from non-standard request vectors?

Rather than getting frustrated and locking down how your customers are permitted approach your IT operations department for help, turn these non-standard approaches into inputs to help you understand your customers’ behavior.  Use objective measures (metrics) and subjective measures (retrospectives) to find solutions that will drive the kind of behavior you would like to see in your customers.

Determine the goal

Start with the goal. What behavior you would like to see in your customers? How would that behavior support the needs of your IT operations team?

Once you know what you’re trying to create, gather the information you need about your customers’ behavior so you can see the gap between current behavior and the goal.

Get metrics

Start with objective measures. As a team, decide how to record the different ways work is requested from your team. Once you have recorded the data for a reasonable length of time, you can dig into it for details and trends. For example:

• Who are your customers?
• How are they contacting your team?
• What work is being requested?
• How consistent are the data points you’re collecting?
• Where are they trending?

Subjective measures

To find out why your customers are behaving in a different way from what would best support your team, invite your customers to a retrospective. Their input during the retrospective can outline the “feeling” responses that can’t always be derived from objective measures.

For example, during a recent retrospective, the IT operations team discovered that several internal customers chose to ask for help face-to-face rather than through email (that operations group’s preferred communication channel) because the auto-response email was phrased in a way that made these customers unhappy. This isn’t a piece of information that could have been easily derived by examining metrics.

As a result of this finding, the team rephrased the auto-response email, communicated this change with their customers, and increased the percentage of contacts made through email rather than in person.

Find solutions

This brings us to finding solutions with your team. After you have gathered objective and subjective information about how your customers contact your IT operations team, work as a group to determine what you can change that will affect your customers’ behavior.

Although teams usually identify “document the process” and “train our customers” as the first two solutions they want to try, those are often the least useful responses. Instead, look for solutions that are specific to your customers’ needs and your team’s situation. The friendlier auto-response email is a case in point. Something as small and simple as rephrasing an email can prove to be more effective than time- and resource-consuming training sessions.

Summary

Agile concepts help IT operations teams remove the “us vs. them” attitudes that put up walls between the team and its customers. When your team is wrestling with specific issues, start by reviewing the 4 Agile tenets. Leverage those ideas to create solutions.

Jen Stone Browne

@jenstonebrowne

Being Present in Meetings

Meetings of various kinds are the bread and butter of Agile practice. As a result, many of us look for ways to create successful meetings that engage attendees, use the time well, and achieve our meeting goals. This often manifests as a set of agreements or rules.

When we look at rules of successful meetings, I often hear "be present" or, put another way, "be engaged." This generally is translated into rules about leaving laptops out of the meeting room, turning off phones, not allowing side conversations, and other enforcement approaches. 

I struggle with the idea of "enforcing" presence. Rather than requiring people's attention, there is value in looking at it from another perspective. If people in the meeting aren't intrinsically engaged, why not?

When people in the room aren't completely focused on the topic, look for a root cause. Are the right people in the room? Are they being bombarded with higher priorities? Has the topic drifted? Was the topic well defined to begin with?

I believe engagement is largely the responsibility of the meeting owner, who can make sure the meeting includes key factors that encourage engagement: 

• A well-defined purpose 
• Logical agenda that supports the purpose 
• Focused conversation driving toward the purpose
• A goal that will be met before the end of the meeting 
• Action items defined with owners assigned and due dates 

Additionally, we can add to these factors meeting functionality: 

• Start on time 
• End on time 
• Have the right people in the room 

After these pieces have been taken care of by the meeting owner, some of the responsibility for engagement will still lies with attendees. However, rather than painting all attendees with the same "engagement enforcement" brush, wait to see if any of the attendees show a pattern of non-engagement, then go to them individually to find out why they're not engaged and resolve the issue one-on-one. 

For example, working with IT operations teams, I find that they often need to be included in cross-functional meetings but only need to be actively engaged for about 10% of the time. I find that it works well to allow operations people to self-monitor in meetings, meaning that when they need to be engaged, they become engaged, but if they are in the room for the portion that doesn't apply to them, they should be allowed to work.  

Each individual in a meeting should be viewed as a person with unique needs regarding engagement. A little thought and effort by the meeting organizer can produce a successful meeting that builds intrinsic engagement while being respectful of the individual circumstances of the attendees.


Jen Stone Browne
@jenstonebrowne