The spectacular view of the London skyline from my office roof

As those of you who know may will recall, I was made redundant from my job as a Scrum Master at Redgate back at the end of May 2016.

Luckily, I wasn’t out of work for too long and since July I’ve been working at a major multinational ecommerce player in the travel and tourism sector (very boring company rules on publicity mean I’m not allowed to name it in blog posts but that doesn’t matter)…

The team I’m in is a backend data team, looking after a number of the main company data sets. As such, our ‘customers’ are the business analysts and finance people who use that data in their reporting.

The wide variety of the sorts of data we handle means that the team is split into sub-teams, handling everything from the basic booking data to feeds of bookings with commission payable on them, and from the data relating to A/B testing on the website to the OLAP cube that’s used by the financial people for reporting up to the CEO.

New challenges

This role has brought a number of new challenges for me so far, which stem just from the nature of the job:

• Our customers do queries in the databases we provide, so ‘user stories’ are often no more interesting than ‘provide this data in a new column in this table’. Sure, we can explain the business value but there’s no concern about usability and, with the stakeholders in the building, there’s often no interpretation required about what they are actually trying to achieve.
• Being a publicly-listed company, there are significant overheads from security and auditing concerns. As much as I might like the team to fix their own problems, they don’t have access to a lots of the production systems they deal with in order to enforce separation.
• Since I joined, it has become a global team, with people in both London and Bellevue (Seattle). In an attempt to avoid siloed knowledge, we have refrained from having some work done in the US and other work in the UK – the work is shared between the two locations, even though this creates a bigger need for communication.
• Like any team handling backend systems, work is regularly interrupted by critical production issues that can’t wait. This is made more difficult by the fact that we’re handling very big data where processing times are measured in hours if not days. Any delay in fixing a problem can have significant impact on downstream systems and, ultimately, the ability of people to do their jobs.
• The sub-teams work with a Technical Product Manager, rather than a Product Owner as defined in Scrum. The difference is that the TPM owns not only prioritisation but also provides a lot of detail (sometime too much) on the implementation side.

The first few weeks

As is always recommended, I spent my first few weeks watching how things were working and understanding what I should concentrate on trying to assist with first, resulting in a set of objectives for the first few months, such as:

• Restarting retrospectives
• Getting epic-based swimlanes on the Scrum board
  (Individuals had their own work in their own swimlane, which was clearly hindering the notion of working as a team when they each had diverse work to do, and would make migrating towards a Kanban approach in the future problematic)
• Stopping the useless sprint demo sessions the team was having
  (Stakeholders never attended them and so it was just a ritual for the developers to show each other what they had done in deep technical detail)
• Supporting the existing initiative to have dashboards showing what data was available and how up-to-date it is
  (The team was working in a very reactive way and often wasn’t aware of problems until our end-users had spotted them.)
• Improving communication with stakeholders through introducing regular A3 Reporting on high-profile / larger projects

There were two much bigger things on my plate, though, which I’ve spent the bulk of the last few months on: getting the Bellevue team set up and developing the sub-team that’s responsible for the OLAP Cube.

Creating a remote team

This was actually a process that was underway around the time I started. My line manager had just moved to Washington State from London to found the team there, and moving the two Indian developers to the US was just the first step. Between October and December 2016, we had two more developers join in America too.

What fell to me was the practicalities of making this work, when the majority of the developers were still in London, as were all the stakeholders. When it had just been two developers in India, standups could still happen in the morning in London, which was early afternoon in India. The switch to the Seattle area now meant that it was the middle of the night there during the morning in the UK. I didn’t want to move the London standup to the late afternoon, as that would rather defeat the object in my opinion, so we introduced an additional catch-up call at 4pm UK (8am Pacific) to ensure work is kept in sync. To complete the cycle, the team in Washington State leave a message in HipChat at the end of their day, which we can pick up the following morning.

This sort of practicality, and the need for planning and retrospectives to be held at the end of the London day, is easy to resolve, while not ideal. It has certainly led to me having a very odd-shaped day, where I’m relatively free during the middle of the day, and very busy with successions of meetings at the end. The most unexpected issue we’ve faced is a perception among stakeholders that quality has reduced: If things broke overnight London time, they were used to it being resolved by the Indian developers before the stakeholders arrived at 9am UK. That no longer happens, of course.

The biggest issue however, predictably, is communication. As I’ve said, we’re trying to avoid silos by having work shared between people in London and Bellevue, rather than allocating different tasks to each place, but that means getting communication right is incredibly important and complex. Add into the mix the need for the TPM in London to answer the majority of questions, and you’ll understand the difficulties when there’s only 90 minutes of time overlapping between the two offices per day. We’ve already had a couple issues where the Bellevue team-members weren’t quite aligned on the project goals, and a near miss where work was almost duplicated between two people in different places.

Cube team

When I started, the Cube team was in a really bad place. Unlike the rest of the wider team, they’d been pretty much ignored and didn’t really have any process at all – neither Waterfall, nor a form of Agile. They had lots of disjointed, small tasks with no real stories tying them together, and a technical debt backlog kept separately from the product backlog. We’ve had a couple of stories that were aborted during development, because it became clear that the value wasn’t as expected. Above all, however, the people in the team didn’t get along. There was a lead developer, who had the technical skills but struggled with people skills. He was also the original (only) team member. Subsequently, another, more personable, team member had joined and had been made team lead before I started, which naturally caused some tension between him and the original developer. And, most recently, a new junior developer had come into the mix, and was naturally caught in the tensions between the two, which I think was partly a cause of him having little confidence.

What a dream scenario! I believe strongly that people problems can be fixed if caught early enough. I took them through a ‘5 Dysfunctions of a team’ training session over several weeks and we managed to resolve many of the interpersonal conflicts. Simultaneously, I put some gentle pressure on the TPM to improve the roadmap and started setting them up with a basic sprint cadence and teaching them Scrum. This doesn’t come overnight, of course, and they’ve struggled to complete their sprint commitments but by showing them data on what their velocity is, we’re getting nearer.

The plan from now on

The next few months are also going to be very busy. A couple of new major projects is almost certainly going to result in having to adjust the team structure slightly. But beyond that, there are a number of more fundamental things to fix:

• I want to get the OLAP Cube sub-team working closer with the other sub-teams that they are dependent on. This isn’t helped by them having a different TPM and a different roadmap.
• I’m introducing a more thorough kickoff process for larger pieces of work, moving from a model where one or two people do a spike and produce reams of spike documentation, to one where the whole team is involved hearing directly from the business what the requirements are.
• Starting to experiment with introducing BDD as a way of having conversations about the requirements.
• Set the expectation that Sprints should end with a tangible thing that can be demoed. At the moment, everything is still very waterfall. I see creating regular, tangible, value as the key to getting stakeholders back into demo sessions.
• Starting to introduce Kanban in the sub-team that has most production issues to deal with.

Exciting times ahead…