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
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
No comments:
Post a Comment