
Agile In IT Operations
In 2018 Intelliware partnered with a Toronto-based company in a co-teaming arrangement to promote the adoption of Agile within their development organization. The project featured a two-pronged approach: 1. Client development teams worked directly with experienced Intelliware developers to gain hands-on experience with Agile processes and technical practices 2. Intelliware experts provided supplemental training and coaching to give the client’s team members exposure to Agile theory and first-principles and support planning and process activities The project was highly successful. Co-teaming supported by training and coaching enabled the client’s development teams involved in the project to quickly become proficient in and realize the advantages of transitioning to Agile. Over the last four years, the client has gone through tremendous growth, acquiring multiple companies through a series of mergers and acquisitions. While this has enabled the original organization to expand into new markets and provide new services and products, it has also resulted in many new challenges. One of the most significant pain points resulting from the client’s rapid growth has been integrating business systems from acquisitions. The integration has involved technology platforms plus compliance, internal controls, payroll, and risk management. And, to complicate matters, many of the new acquisitions have involved firms based in other countries. As a result, the client’s IT Operations team has expanded from a small staff supporting roughly 200 employees in Canada to a team supporting over 1000 employees across the globe. The IT Operations team found themselves with a large amount of project work to get done while also providing day-to-day technical support and other related functions. The team realized that they needed to change their way of working, and, based on what some members involved in the Intelliware transition project had learned earlier, they decided that an Agile approach would help. So, in early 2021 the IT Operations team rebooted and implemented several Agile practices to help to improve collaboration, the way they organize and plan their work, and their overall effectiveness. This post provides an update on how the IT Operations team has progressed with their Agile adoption so far, what has worked well for them, and the ongoing challenges they still face, along with recommendations on addressing them. To conclude, we provide some suggestions for advanced practices that the IT Operations team should consider to help them take their Agile transition to the next level. The IT Operations team adopted seven Agile practices as a starting point: The Agile practices that the IT Operations team adopted quickly resulted in better outcomes for the team. Specifically, the team observed: Towards the end of 2021, the pace of project work was on track compared to the plan developed at the beginning of the year. The team’s ability to stick to the original plan represented a significant accomplishment given the amount and complexity of the project work involved. There is a perception that a lot of project work is getting done both within the IT Operations team and externally within the larger organization. While the IT Operations team has made significant strides in adopting Agile practices and is benefiting from positive outcomes, several practices continue to challenge them. The team recently identified three aspects of Agile that they struggle with. The team finds it hard to estimate consistently, commit to Sprint scopes and deliver on their commitments. A typical conversation between team members and their Product Owner looks like this: The team is unsure if they should be changing the velocity they use for Sprint Planning or their mindset. Arguably, they should change both! In terms of mindset, the team needs to accept that velocity is a tool for planning purposes and is not fixed. As a result, velocity should not be a static value or factor; instead, each Sprint it should be adjusted. The best recommendation for what velocity to use from one Sprint to the next is “Yesterday’s Weather”—the best velocity for the next Sprint should be what the team achieved in the previous one. Because of the many factors involved, it’s nearly impossible to predict velocity. So, the team’s capacity at Sprint Planning should not be based on what the team thinks it can achieve, but instead on concrete evidence—what they achieved before. The IT Operations team has ongoing challenges with keeping their Stand-up meetings short. Their target is 15 minutes, an objective they rarely achieve. In response, the team has introduced an agenda that allows each team member five minutes for updates, which has helped keep the meeting moving along with better structure. Stand-up meeting duration, and meetings dragging on, is a common problem. This situation is an indicator of another underlying symptom—team members losing sight of the true purpose of the Stand-up meeting, which is to synchronize the team’s efforts. Instead, teams often end up falling into common traps like: The risk is that when Stand-up meetings take too long and go into too much detail, participants start to disengage because they’re bored or feel that the meeting is not an effective use of their time. Here are some recommendations that will help the IT Operations team keep their Stand-up meetings short and effective: Too many meetings is a common complaint of teams new to Agile. The shift to a self-organizing team that completes work iteratively does require more meetings to ensure that the team coordinates their efforts and plans their work effectively. However, the benefits are significant, as evidenced by the improved outcomes that the IT Operations team is already observing. As noted previously, improving Stand-up meetings and keeping them as short as possible will help alleviate concerns with too many meetings. Some other improvements that the IT Operations team should consider are: 1. Recognize that not everyone on the team needs to attend every meeting. Some ceremonies are essential for all, such as Sprint Planning and Stand-up. On the other hand, Backlog Refinement can be done effectively by a smaller group, specifically the Product Owner and team leads. A key enabler is ensuring that the Backlog is visible so team members can view the outcome of the Refinement meetings separately. 2. Ensure that team members have a block of days in the middle of the Sprint with no meetings to focus on their Sprint commitment. Ceremonies, such as Sprint Planning, Sprint Reviews, etc., should be scheduled at the beginning and end of Sprints, so the team has a contiguous block of days through the middle of the Sprint with no meetings. Backlog Refinement is different, as it usually occurs through the middle of the Sprint, but as noted above, Refinement meetings do not have to involve the entire team. 3. Practice good meeting hygiene. To ensure effective use of everyone’s time, every meeting should have an: The IT Operations team is well on their way to a successful Agile transition and is realizing improved outcomes as a result. The practices that the team has taken on thus far could be considered core or enabling: practices that are straightforward to get started on and have few dependencies on other practices. Some advanced practices that would apply to the team that they should consider in the future include: A meeting on the first day of the Sprint with the Product Owner to review and confirm the Sprint commitment. A Kick-off meeting provides an opportunity for the team to seek clarification on and confirm the Sprint commitment. To make this work, the team will have to move its Sprint Planning meetings to several days before the end of the previous Sprint. The advantage of this approach is that it provides an opportunity for the team to think about the Sprint scope and clarify requirements before confirming what they’re committing to with the Product Owner. Adding Kick-off meetings and separating them from Sprint Planning reduces the risk of the team signing up for a commitment that they can’t deliver. This practice is an advanced enhancement of Retrospectives that comes with several components: Stable, cross-functional teams are a hallmark of Agile. However, occasionally moving people around to different roles can promote cross-pollination of practices, invigorate team members by providing them with opportunities to work on new things, and facilitate career advancement/promotion. Time-boxed investigations into specific issues or technical challenges. Agile teams use Spikes to reduce the risk of committing to something they don’t completely understand. Spikes are added to the Backlog as tasks or User Stories, estimated and planned in the same way that other functional requirements/project tasks are managed. As such, the team must describe the Spike and its need in non-technical terms that the Product Owner and other stakeholders will readily understand. A consistent, well-understood and documented approach for determining when project work is completed and not completed. Establishing a DoD is an advanced practice because it requires discipline to reach a consensus on what done means for project work, document it and stick to it. However, the benefits are significant—being able to consistently determine when work is completed and not done (and possibly needing to be carried over to the next Sprint) will result in improved: We would like to thank Karen Bruer for her valuable contributions to this post.Agile In IT Operations
Outcomes
Challenges and Areas for Improvement
1. Estimating and Planning
2. Stand-Up Meetings
3. There Are a Lot Of Meetings
Recommendations for Next Steps
Sprint Kick-offs
Figure 1: Standard Sprint Schedule
Figure 1 illustrates a typical Sprint schedule and shows how Sprint Planning can be scheduled before the end of the current Sprint to give the team time to think about the planned Sprint scope and prepare for the Kick-off meeting on the first day of the next Sprint a few days later. The diagram also shows how other meetings, such as the Sprint Review and Retrospective, should be scheduled on the first and last days of the Sprint to give the team a contiguous block of days through the middle of the Sprint with no meetings to focus on their Sprint commitment.
Actioned Improvements
Move People Around
Spikes
Definition of Done (DoD)
Acknowledgements