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