March 16, 2018

The Agile NOC'er (Part 2)

The experience of introducing agile practices into a reactive Operations team (part 2)

In part 1, I described the challenges of integrating Agile practices into a dispersed, reactive Operations team, and the general strategies we were “hoping” would come some way to meeting those challenges.

Well, three months down the track it is time for an honest retrospective on how we fared.

Here’s a quick revisit from part 1, summarising the strategies we focused on to solve some of the particular challenges we face:

Strategy #1 - Kanplan

As described in part 1, the traditional scrum-based approach is not very suitable for a team that has to respond to unscheduled work. Kanban is the obvious replacement, but also has some issues with exploding backlogs unless some backlog grooming and prioritisation occurs. Kanplan is essentially Kanban, with the addition of scrum-like backlog refinement.

Strategy #2 - The “boundary spanner”

We have a “geographically-challenged” team, functioning across three different (very different) timezones. To tackle the problem of all team members having to attend all the various agile ceremonies, often in an hour that would be considered “insane”, we decided to test the idea of using a “boundary spanner”. That is a person who “spans” two different teams with the goal of coalescing and re-presenting information from one team to another.

The retrospective

What worked:

In general, the “Kanban” part of Kanplan worked as expected - tasks were created, then moved along from left to right and then closed. The “plan” part of Kanplan also worked insofar as the backlog diminished instead of increased (significantly). So, I would give Kanplan a big green tick for our particular circumstances. However, as I said before, this is “expected”. Independently, these two agile processes (kanban & backlog refinement) have been around for decades and are tried and true. Combining them was a painless process, and there are no obstacles to them fitting together. It also helps when you use a tool such as Atlassian Jira to help you keep track of everything. In fact “Kanplan” is an Atlassian construct, so it makes Jira the perfect tool for our situation (can you tell I am a Jira fan-boy).

What didn’t work:

When we kicked off this process, our backlog (the “plan” part of Kanplan) was entirely un-groomed. The advice we had been given was to invest some good time up-front to get this done as a priority, so we organised two ceremonies per week to try and knock it on the head. The idea was that each region would have at least one meeting to groom the backlog in their time zone, and the “boundary spanner” would again facilitate communication. I quickly learned that the backlog refinement ceremony was one of those meetings where you need everyone present.

The prioritisation of tasks was not so much of a problem. We receive our priorities from the Product Owner (or his representative), so the only real requirement here was that the Product Owner was present. However, there were two practical limitations when attempting to story-point a task in one region only. Firstly, there may be a small number of members in a particular region, and that negates one of the benefits of story-pointing as a team. That is, to have a large enough sample size to make it statistically sound and even out any bumps in terms of estimating complexity.

The second issue is not so obvious. “Story-pointing” is about estimating the degree of effort required to complete a task. In a way, it is also about the team “accepting” this task, which is of nominated complexity, as being able to be completed in a suitable time-frame. The problem occurred when the team member who picks up this task off the backlog had no part to play in the assigning of the story points.

So in this aspect, the concept of a “boundary spanner” does not even come close. Backlog refinement is about the whole team accepting the work, and therefore it needs the whole team. In fact, the idea of employing a “boundary spanner” didn’t take off in reality, even for simple things like daily standups. Despite our best attempts, it was too much work for that “spanner” to adequately absorb all the information and then regurgitate it in any reasonable manner. It was becoming evident that the information was not getting to the team members in other regions.

What didn’t work, now works:

So, in the purest spirit of agile, we adapted.

They say that a “picture is worth a thousand words”, and in this circumstance, “a (moving) picture is worth a thousand (million) words”. So, one of the innovations we introduced was recording “everything”. For instance, each region has their daily standup ceremony, lead by a designated scrum-master (the “spanner”). This meeting is recorded and published. When the incoming team comes on-line, they all watch each person present their standup as if the outgoing team members were actually present, albeit, they pre-recorded theirs 8 hours previously. It was not designed to replace the hand-overs but to enable the whole team to (sort of) attend a daily standup together. It is not perfect but has worked well.

This idea of “recording everything” has relieved the pressure on the need for all team members to be physically present for all ceremonies, which would have been a nightmare if you tried to organise that for the three regions in which we operate. The team has found this innovation extremely valuable, and I would say that it has been the single largest contributor to the successes we have achieved so far.

What we can do better:

In all honesty, although we have made significant strides towards minimising regular early-morning/late-night meetings, I still think there are advances to be made. For example, now our backlog is in a good state, there is less need to have multiple backlog refinement meetings per week. We still need to capture those tasks created since our last grooming session (we get numerous new jobs every day), but some aspects of that process can be handled out-of-cycle. As I stated before, the priorities come from the Product Owner, and the broader priorities don’t change that often. As long as those priorities are adequately communicated to the team beforehand, most team members will have reasonably sound judgment on priorities anyway.

My final thoughts:

It’s early days in our Agile journey, but the signs are looking positive. The general feeling is that the “project” so far has been a success. We have increased our productivity, and we are enjoying solving some of these particular challenges faced by a geographically dispersed and highly-reactive team. As we grow in experience and innovate even more, I have the feeling that our Agile journey will only get stronger.

Previous - part 1

© Craig Robinson 2018

Powered by Hugo & Kiss.