How to overcome friction between multiple agile teams (Part 2)

This is the second blog in a two-part series which considers the main friction points for organisations who have embraced agile ways of working with multiple agile squads. In the first blog, we identified the following two situations as common causes of friction where multiple agile teams are concerned and provided a solution to the first. As a reminder, these were:

1. Agile but siloed teams: Squads of teams aligned around technology abstraction layers that are using agile delivery methods, but are siloed in their approach to end-to-end outcomes.

2. Front-end focused product ownership: Individuals in product owner roles tend not to own the end-to-end outcome but focus mainly on design aspects. This is likely due to their skillset and level of comfort working in more technical areas.

In this blog, we will be delving into the challenges presented by a front-end focus in product ownership.

Product ownership overly focused on front-end journey flows

In large organisations, we sometimes find that the Product Owners do not always focus on coordinating siloed technology teams. They may set up communication channels and a ceremony cadence that favours front-end and user experience over end-to-end product enablement. Additionally, Product Owners trying to deliver thin end-to-end solution slices based around a customer journey are hampered, or even stopped, by the organisation's design or hierarchies.   

Often, an Architect, Project Manager or Business Analyst will be leant on to try and stitch better ways of working together across teams. However, those individuals sometimes do not have a deep agile background, nor the inclination to be the servant leader to these teams. As such, the role of facilitating and unblocking issues, as well as providing coaching and habit changing skills, is often missed.

Disjointed demonstrations of software progress

Sprint work that is disjointed across teams reduces the ability to demonstrate thin slices of end-to-end customer journeys. The individual teams are not actively working together to show the simplest, end-to-end pieces and building out features sprint-by-sprint.

A key symptom of this situation is that the first few demos are of increasingly detailed screen mock-ups. Subsequent demos cover technical 'postman service' demonstrations of APIs that are not related to any front-end code being shown in the same demo. This is usually followed by a 'lull' period when all the teams' components are fixed to work with each other. The worst possible outcome of this is that the stakeholders see the user interface getting completed and believe the product is nearly ready for release.

We have always observed that fully end-to-end demos, even if ‘roughly designed’ to start with, increases stakeholder confidence much more than showing static screens or even working clickable prototypes.

A tried and tested solution 

Essentially, our recommendation is to use a standard agile approach: a cadence of recurring sessions to elaborate features into thin slices, one by one. Some sessions may focus on the detailed flow of data ‘up and down’ the stack and also need 3rd party vendor participation, whilst other sessions may focus on end-to-end design to facilitate specific aspects of a screen flow.

The main ways of working change we often implement to achieve this is coaching with a focus on breaking down front-end outcomes into small, end-to-end steps that can be demoed. In doing so, the teams move away from infrequently demoing completed pages of functionality and instead show, sprint by sprint, more and more integrated working code. Credera’s coaches help teams work together to show cross-team working software as often as possible.

Moving into a new paradigm of showing imperfect, partially complete customer journeys to stakeholders requires a mindset shift across the whole team. It is important to invest time with the key stakeholders to explain how progress will be seen in this new approach and educate them in how this reduces delivery risk. That requires sessions with stakeholders one to one and with sub-sets of the wider team to continuously focus on maintaining the habits that are required.

To give a specific example, consider an application that has a page to show a customer’s current month’s activity (it could be items like money spent, visits made, product purchased, savings accrued, and so on). The Product Owner has designed a screen that shows a mix of: historic activity by date, a ‘progress towards a reward’ graph, and a scrollable list of offers to click on.

To embrace a thin slicing approach to real working code, the first sprint could show a simple application screen, with a single button in the middle. Upon clicking the button, the business service APIs are called all the way to the database, but for only one of the data elements (e.g. the ‘progress this month’ data item). A piece of text is displayed, showing the data item. There is minimal implementation of screen design, and each API only has to have coded one data element.

The positive shift of this approach is that the teams are showing working code all the way to the database and have probably solved a number of issues they didn’t know were going to be problems. Some of the APIs could be temporarily utilising hard coded or test data until, for example, connectivity with a specific support service has been achieved.

How do we achieve this?

The most effective way to achieve the above is via regular collaboration sessions and it is essential to get cross-team representation into those sessions. This takes some influencing, agreements with senior managers, and then tight facilitation to ensure high value is achieved from the time given.  

We find that bringing the key individuals from the separate teams together to ‘really make a start,’ rather than simply discussing the ways of working, results in them seeing the value of the approach. Often, they then influence their senior managers positively as they see how the efficiency and work progress will increase.

Historically, such collaboration would occur in a room, hopefully with a permanent large whiteboard. The whiteboard would be used to show the whole flow, work on specific issues together and so on. Often you’d see individuals huddling round the white board – discussing, pointing, drawing, correcting mistakes, and adding detail.

How do we achieve this in a virtual world?

Nowadays, achieving the same outcome requires virtual sessions as it is rare to have more than 30-50% of the required participants in the same time zone, never mind in the same office. It is extremely important to embrace electronic tools and active screen sharing for this virtual approach to be successful. It is almost impossible for detailed technical elaboration to occur by ‘voice only’, hoping that everyone will be fully listening, understanding completely, and have perfect recall of the discussion.

To achieve the collaboration in a virtual environment, take an active approaches. It is not as simple as picking a tool to replace the physical whiteboard, although this is critical (there are many tools such as Mural, Miro, etc). The meetings must be facilitated using the tools yet still focus on collaboration. This means sharing the virtual whiteboard on screen with all participants watching; verbal comments and changes captured; ‘mouse’ control being moved between individuals; switching between the whiteboard tool and text based requirements in the workflow tool; actively adding detail, breaking down requirements on screen; and adding technical detailed tasks as they are discussed.

In many cases, achieving the above involves one or two individuals leading by example. Individuals with more natural coaching style should be encouraged to ensure all the individuals’ voices are heard and that all relevant concerns are uncovered by asking probing questions. They should also help the team make risk-based decisions and unblock progression.

In a nutshell

Keen to achieve this outcome? Consider looking into the sprint planning activities being undertaken between siloed teams to achieve a customer flow. Are the right agile outcomes coming out of those interactions?  Pay particular attention to check that multi-team user stories are demonstrably end-to-end, and not siloed to one part of the tech stack. Reach out to us here at Credera for more ideas!