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

Flat IT, software developers, manager or designers men sworking with big scrum agile board with daily tasks, kan ban desk with sticky notes, woman at desktop. Vector illustration.

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.

Outcomes

The IT Operations team adopted seven Agile practices as a starting point:

Establishing their Cross-Functional Team—recognizing who was on the team and their roles. Management confirmed specialty roles, including Product Owner, Delivery Manager, and Technical Lead
Scheduling Daily Stand-up meetings to help coordinate the team member’s efforts on project work.
Creating a Project Backlog to organize the project work to be done and make it visible to the team. Refinement Meetings were initiated in conjunction with the Backlog to keep the Backlog up to date.
Establishing a Sprint cadence to facilitate an iterative approach to completing project work in the Backlog and give the team a series of milestones to focus on
Adding Estimating and Planning to give the team a mechanism to manage the amount of project work that they commit to from one Sprint to the next and help make the pace of project work completed sustainable and predictable.
Scheduling Sprint Reviews, at the end of each Sprint, to update the team’s stakeholders and management on completed project work and provide an opportunity for feedback (used to update the Backlog).
At the end of each Sprint, holding Retrospectives to provide the team with opportunities to reflect on how the Sprint progressed and identify areas for improvement.

The Agile practices that the IT Operations team adopted quickly resulted in better outcomes for the team. Specifically, the team observed:

Improved communication with stakeholders. The team’s accomplishments, the project work they were able to complete from one Sprint to the next became more visible, which helped improve the team’s overall morale and trust with their stakeholders.
Better collaboration within the team, with other teams in the organization, and with external vendors and consultants.
Enhanced buy-in and engagement by team members, as indicated by consistent and strong participation from every member of the IT Operations team. Notably, this was observed across team members in numerous regions worldwide and on local, regional, and global projects.
Improved visibility and management of work to be done, work in progress and work completed. Better insights into the status of project work enabled the team to manage their priorities better, organize project work, determine and report status, and mitigate roadblocks.

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.

Challenges and Areas for Improvement

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.

1. Estimating and Planning

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:

Team members: “You expect too much of me every Sprint.”
Product Owner: “But you committed to those tasks and agreed to the estimates.”

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.

2. Stand-Up Meetings

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:

Going into too much detail
Using the meeting to share knowledge and resolve issues
Focusing on status and accomplishments instead of what other team members need to know to keep their efforts synchronized

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:

Take detailed discussions offline. At any time during the Stand-up, anyone on the team should feel empowered to call out: “We’re getting into too much detail here; let’s move on and talk about this separately with a smaller group afterwards.” Some teams will say ELMO (for Enough, Let’s Move On). The advantage of taking detailed topics offline is that the follow-up discussion does not have to involve the entire team. Optional attendance helps avoid having team members who are not interested or who don’t have a stake in the topic feeling like their time is being wasted (note that attendance at Stand-up is mandatory).
Ensure that everyone understands that they don’t always have to speak and that sometimes less is better. Team members need to remember and should be reminded by other team members when they go off track that the Stand-up is not about status but should focus on what the team needs to know to coordinate their efforts and work effectively. For example, if a team member is working on something that doesn’t affect the team significantly, or what they’re working on hasn’t changed much from the previous day, then what they contribute to the Stand-up should be minimal.
Make sure that the team is having regular Retrospectives. A Retrospective is an excellent opportunity for team members to raise concerns that they may have with their Stand-up meetings and identify ways to improve them.

3. There Are a Lot Of Meetings

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:

Objective. Nobody should attend a meeting simply because they feel that they’re expected to be there; they should have a purpose. Concurrent with this, nobody should be invited to a meeting unless they have a stake in or can contribute to achieving the objective.
Agenda. Ideally, an agenda should be created before the meeting and be consistent with the objective. Everyone should show up knowing what’s going to be discussed so they can decide whether they need to attend and be prepared to contribute.
Leader. Somebody should be prepared to facilitate the meeting to ensure that the agenda is followed, the objective is achieved, and the discussion is on schedule. For example, the Product Owner often leads the Sprint Planning meeting.
Notes help maintain focus and provide documentation for non-attendees to catch up later (critical these days when most folks are working from home or remotely). A meeting without notes is arguably just a discussion! For example, the outcome of a Sprint Planning meeting should be the list of tasks or User Stories that represents the team’s commitment for the upcoming Sprint.

Recommendations for Next Steps

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:

Check-Mark

Sprint Kick-offs

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.

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

This practice is an advanced enhancement of Retrospectives that comes with several components:

At each Retrospective, the team aims to identify a small number (no more than 2 or 3) improvements that they’ll strive to implement before the next Retrospective.
A leader assigned to each improvement who is responsible for shepherding the advancement through to completion. The leader is not required to do all the work needed to make the improvement happen, but at minimum, they should keep an eye on the initiative and intervene if there is an issue or something is blocked.
The beginning of the Retrospective starts with a review of the improvements identified in the previous Retrospective. If an improvement is not completed, the team can consider if it is still a priority and should be carried over to the next Sprint or dropped in favour of something else. A team that doesn’t complete its improvements from one Sprint to the next can result in a short Retrospective if they choose to carry everything over to the next Sprint. However, on the other hand, the team is not improving when this happens.

Move People Around

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.

Spikes

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.

Definition of Done (DoD)

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:

Quality of completed work
Transparency, and trust, with external teams and stakeholders
Planning, with respect to predictability and consistency

Acknowledgements

We would like to thank Karen Bruer for her valuable contributions to this post.