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

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 

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