4, one of the less desirable aspects of their rapid expansion was that their teams had grown organically and in many cases they had teams that were entirely missing representation and/or leadership from either product, tech, UX or agile. These gaps had caused a few different anti-patterns to emerge; with some teams lacking a clear roadmap, others struggling to address technical challenges and most battling with coordinating cross team delivery.
Over a number of months we worked with each of the teams to help build an understanding of the key perspectives needed to ensure we had balanced cross functional skills in the teams. We called this ‘The Quad’.
Each of the roles above is critical to keeping team delivery on track and avoiding a bias towards a particular perspective or approach. In this case the role that was missing entirely from teams was that of the delivery leader, by which I mean a Scrum Master, Agile Coach or Delivery Manager person – depending on how you choose to define the role. This role had traditionally been performed by a project manager who sat outside the teams and had a pretty thankless task of trying to coordinate delivery from 10+ teams.
Our first task was to set up this ‘delivery leader’ role in a way that empowered teams and was sympathetic to the existing team roles. In this context we wanted to emphasise the need for individuals with strong empathy and coaching skills whilst also being able to get into the detail enough to help remove impediments to the team’s flow. After a bit of debate we called this an ‘Agile Delivery Coach’. There’s definitely a whole different blog article we can go into just on how we defined this role, but for brevity let’s summarise it as a servant leader position with a clear focus around facilitating multi-team delivery in a sustainable way. We leaned heavily on the Agile Coaching Institute and Lyssa Adkins’ work on an Agile Coaching Competency Framework in developing this role [http://agilecoachinginstitute.com/agile-coaching-resources/].
Introducing the ‘ADC’ was a big step, but we also needed to make sure this didn’t become the only perspective in how to delivery. We needed to make sure each team also had reps from the other angles of the quad. This meant hiring additional talented Product Owners where there were gaps and supporting the development of existing PO’s with a career path and mentoring. We were supported by a really talented Chapter Lead for UX, who helped us bring the UX folks into the teams and onto the same cadence as their squad. We borrowed from Jeff Gothelf’s great book on Lean UX to inspire our thinking here.
In parallel with this, our CTO and Engineering Directors worked with their engineering teams to make sure that we had strong engineering leadership available in every squad and that Architects were on hand to support our Platform teams.
Finally, and most importantly, once each team started to bring together these roles we made sure that the individuals involved took the time to discuss how they saw their roles working and where there might be overlaps. We facilitated open conversations about how they might identify and resolve conflicts based on where they saw the likeliest areas of overlap. There’s a picture below of how we ran these sessions, where we asked each person to sticky note key activities that the team needed and whose area of responsibility they most closely aligned to. This was revisited on a regular basis to discuss how the responsibilities were evolving as teams matured.