Practical Cross-ART Collaboration
Following on from the PI-Planning webinar and blog series, a quick,look at the practicalities of Cross-ART collaborations.
Why do ARTs need to collaborate?
The Reason : Business value does not respect architectural or organisational boundaries, it cuts across them. Even with stream aligned trains that can deliver their own value end-to-end, true end-to-end business value will often require change across a number of areas and disciplines.
Fig 1 : Business Value cuts across ARTs and Value Streams
The Problem : One train needs to collaborate with another.
In practical terms this means that the team members in one train need to be talking to the team members in another team, but this needs to be handled in a such a way that the empowerment and self-organisation of the teams within the train is maintained.
What Does The Textbook Say?
- Instigate a Solution Train for ARTs that are closely coupled within the same Development Value Streams.
- The Portfolio can help with Value Stream Coordination across Development Value Streams and ARTs.
If ARTs are regularly collaborating together then the more formal methods of a Solution Train might be more appropriate, but cross-ART collaboration doesn’t have to be a great big process, it can be lightweight and much more informal. Even with the formal Solution Train, the process is never elaborated from the perspective of the teams and what they need to be doing, only from the top-down perspective of the organisation knowing that collaboration is needed. This can lead to implementations inadvertently imposing collaborations on the teams which in turn can break the empowerment and self-organisation that Agile promotes.
How does it work in practice?
It doesn’t have to be a complex bureaucratic process with extra layers and job titles, ultimately collaboration is one person talking to another, the challenge is triggering the conversations without imposing the conversations on teams and individuals.
If you hold to the values in the Agile manifesto, then the conversations triggered are Individuals and Interactions over Processes and Tools, and Customer Collaboration over Contract Negotiation. It’s prefectly possible to uphold the values when bigger groups need to collaborate.
What are the steps that need to be taken to effectively trigger one team in one train to start a conversation with another team in another train?
Intentional Architecture
Cross-ART collaborations tend to be known about in advance, not the detail, but that one system needs to talk to another and therefore the teams that own those systems will need to talk.
Fig 2 : Business Value cuts across the system landscape
The people that are responsible for a system should know what other systems their system interacts with, and the nature of those interactions> If the people responsible for a system don’t know their system then there’s a more fundamental knowledge problem that needs solving before any of the collaboration challenges can be properly addressed. The System Architect should know the system’s position within the landscape of systems. The Product Manager should also know the system’s position within the landscape, but they don’t need to know the technical detail of any system interactions. The Product Manager needs to know about the other systems as the other systems, or the people that own them, are potential customers or stakeholders to this system that the Product Manager is responsible for.
The other scenario is that this problem requires skills that are only present in another group of people. The people that are responsible for an Agile Release Train should know what skills their Agile Release Train possesses and therefore whether they may need to be asking for help from other Agile Release Trains to solve the challenges that they are facing. With large systems it’s not uncommon to find ARTs arranged around skills; organising ARTs within a large system is discussed in Organizing around Value : Development Value Stream Patterns and the trade-offs involved.
Fig 3 : Multiple ARTs with different skill-sets support the system
Within SAFe cross-cutting work is represented by an Epic; Epics are discussed in Writing Better Epics in SAFe and as part of the long running blog series On The Nature Of Lean Portfolios. This cross-cutting nature means that Epic Owners are often best placed to help with the coordination.
Once one Agile Release Train knows that it will need to interact with another Agile Release Train then the next step is to ensure that both Agile Release Train’s have…
Aligned Backlogs
Product Managers need to align to ensure that coordinated work gets planned into the same PI, this entails alignment between the backlogs.
Fig 4 : Product Managers need to align their backlogs
Capabilities are the brute-force approach for ensuring that alignment. In the formal Pre-Planning meeting held before PI-Planning and attended by all the central representatives of the ARTs within a Solution Train the Capabilities are split into Features and go straight into the ARTs’ prioritisation sessions for the next PI. Splitting capabilities into Features shouldn’t be difficult, they’re already expressed in the same format as Features and represent business needs. All that splitting a capability entails is to say “the bit that this team can do” which is driven by their skills and knowledge, things they should intrinsically know about.
Fig 5 : Capabilities split easily into the parts that an ART can do
| Anti-pattern: Extending the work hierarchy | |
|---|---|
| One common mistake is to use Capabilities to extend the work-item hierarchy. People crave order, which is understandable given that engineering and problem solving can be quite chaotic, not all problems are solvable. | |
| Sometimes there is a desire to use Capabilities to group together a set of independent Features that serve a common purpose, often a defensive tactic because they want all of these Features and worry that if the Features were fed into the economic prioritisation WSJF then they won’t get all of their desired Features. This in itself is breaking the goal of Lean, Chasing Value, because a less valuable Feature is being done in preference to a more valuable one. Learn to properly slice Features along the lines of value and then the valuable Features will rise to the top and the Features that are niceties will sink to towards the bottom. | |
| Sometimes there is a desire to use Capabilities to group together a set of Features that aren’t independent because they’ve been badly sliced. If the Features don’t come along all at once then the value won’t be present at all. This breaks the purpose of Features which should be independent, potentially releasable, points of value. | |
| Think of Capabilities as a grouping mechanism, to group together a set of Features that have to be planned together but can’t be a single Feature because the necessary skills or changes are in separate ARTs and one of the defining characteristics of a Feature is that it must be achievable by a single ART. | |
But alignment doesn’t need Capabilities nor any formal pre-planning meeting, it could just be Product Managers agreeing priorities together around the coffee machine. That related Features are going into the same planning interval.
Fig 6 : Linking features together with notes
Linking Features together doesn’t have to be formal either. Whilst tooling can help, don’t fixate on the tools. A simple note added to the Feature saying that “ART X has Feature Y that supports this Feature.” is enough to trigger a team to pick up the phone during PI planning and start the negotiations with the other Train/Team. It worth noting that a note on the feature isn’t dictating the collaboration to the team, it’s prompting them to negotiate with another team, it’s promoting self-organisation.
Fig 7 : Epic Owners trigger cross-ART collaborations
Epic Owners are often best placed to prompt the Product Managers that they need to collaborate, it is just a prompt the actual collaboration needs to happen between the Product Managers themselves, this promotes empowerment, they have to self-organise between themsevles. Epic Owners would participate as stakeholders in any collaborative road-mapping sessions for the ARTs that are supporting their Epic, these session block out at a macro-level when activities might happen, which begins to outline any sequencing that may need to occur across ARTs.
Synchronisation
In order of for one train to be able to talk to another train, to negotiate the collaboration, both trains must be planning at the same time. Planning Intervals need to be synchronised to start and stop at the same time. SAFe Principle #7: Apply cadence, synchronise with cross-domain planning.
A lack of synchronisation would mean that the negotiations can’t happen in real-time, which would impact planning and ultimately lead to incomplete or unaligned plans.
If the collaborations are negotiated in advance of PI Planning then the train’s ability to adjust its plans within planning is compromised. The pre-negotiated collaborations become constraints that can’t be moved regardless of whether they are the highest priority because there is no way of letting the other train know that the collaboration has to be moved. This is a violation of SAFe Principle #3: Assume variability, preserve options. Preparing for PI Planning is not about starting the planning early, but ensuring that all the information that feeds into the planning process, namely the backlog of Features, is the best that it can possible be.
| Anti-pattern: Lack of synchronisation | |
|---|---|
| We were with one client where an Agile Release Train had ended up running two weeks behind the other Agile Release Trains because most of their work was solicited from those other Agile Release Trains rather than being new and unique to them. The optimisation made sense to the organisation: this train gets all of it’s work from the other trains, therefore we let them plan to determine what the work is and then this train can do it’s planning, however it had unintended consequences that were causing serious harm. Because the train was planning behind the other trains it didn’t have the opportunity to negotiate back, any commitments that the other trains had made were now being imposed upon it, regardless of whether this train could achieve them or not. PI Planning was not about negotiating the collaborations and determining an optimal sequence of the work, it was looking at what was being imposed upon it and assessing just how hellish the next few months were going to be in order to meet someone else’s commitments. The engineers were revolting†. | |
| The fix was to get them back onto the same cadence as the other ARTs, get them planning in parallel and giving them the opportunity to negotiate back. To adjust timings, to push back if there was more work than they could physically do. Morale improved, as did the deliveries. Another significant part of the fix was to get the Product Management and System Architecture staff of the other trains to think about the Features they were putting into their backlog and to think hard about whether they would need support from this train, didn’t need the solution upfront, but did need to get a request into this train so it could manage a prioritise it’s backlog and understand the sort of collaborations they would be facing in the upcoming PI and therefore be in a position to negotiate them with the other ARTs within PI Planning. | |
|
†: Inciting revolution and threatening to quit, rather than being malodourous. |
|
ARTs must be planning at the same time; possibly in different big rooms, possibly on different continents, but they must be planning in parallel. If one ART does their PI Planning ahead of another ART that they are collaborating with, then the leading ART imposes it’s commitment on the ART planning later because the trailing ART can’t negotiate back because the plans, and commitment to those plans, have already been made.
PI Planning
- One Team pulls a Feature from the backlog.
- They see the note on the Feature notifying them that it’s linked to another Feature in another ART.
- They call the other ART, who are planning at the same time, and therefore in a position to negotiate.
- The collaboration is negotiated.
- Both Teams put stories are put into their backlogs and plans to: hold discussions, do the work, transfer the results, whatever is needed by the collaboration.
- Objectives are created that, once aggregated into the ART objectives, can be broadcast to adjacent ARTs to allow those ARTs to cross-check that the negotiated work is planned to be done.
PI Planning Boards should have a row at the bottom to represent external collaborations; collaborations with other ARTs can be visualised in this row. Some organisations take this slightly further and have a separate row for collaborations that are internal to the organisation but external to this ART, as well as the row for true “external to the organisation” collaborations. For Solution Trains where there are expected to be a lot of cross-ART collaborations then there may even be explicit rows for individual ARTs. What’s important is to visualise the collaborations so that they can be seen; if they can be seen they can be managed, if you can’t see them you won’t even know that they need to be managed.
The planning board is often reviewed during the Management Review, this would look at the cross-ART collaborations; the visualisation might trigger conversations: should the organisation be thinking about Flow Accelerator #3 Minimize Handoffs and Dependencies? Would a better ART structure allow less collaborations and more self-ownership to get stuff done end-to-end; typically quicker.
Solution-Trains have their own level of Management Review, that occurs after the -ART management reviews, one of the topics that the Solution level will look at explicitly is the cross-ART collaborations.
Execution
Ultimately the teams just need to collaborate with each other: have the conversation, transfer the knowledge, pass over the artefacts. Closing the accountability loop on whether the collaboration is actually happening is the responsibility of the facilitators, the SMs and RTEs. They shouldn’t be doing the work on behalf of the teams but encouraging the team to self-organise to do the work.
Outside of a large solution scenario there are no formal meetings for RTEs to get together, such formality isn’t always necessary, a water cooler chat to check that one train is collaborating with another is enough. Again, the Portfolio is well positioned to help with cross-ART collaborations; the Portfolio Sync is one place that cross-ART collaborations could be discussed if the RTEs are present.
Fig 8 : The feedback loop maintaining alignment across ARTs
Anti-patterns
Anything that breaks empowerment and self-organisation is an anti-pattern. Watch out for central roles imposing solutions on the teams, telling them exactly what to do, rather than triggering the engineering staff to self-organise.
Anything that stops one engineer collaborating with another engineer. Watch out for central roles getting in the way of direct conversation, often because the central roles feel that that’s how they can maintain control of the situation, but it actually leads to delays, miscommunication and un-empowerment of the engineering staff.
Conclusions
Cross team collaboration is about…
Centralise Strategy, Localise Execution : Prompts through notes on the Features, negotiating during planning, is setting up the Strategy for the collaboration, it started centrally and has been progressively decentralised out towards the teams and engineers within then teams. Ultimately, an engineer on one team is going to have to interact with an engineer on another team, engineer to engineer; the hierarchy within the ARTs has helped set that interaction up but the interaction should not run through the hierarchy.
Close the accountability loop : Whilst we want the engineers to be talking directly to each other, the hierarchy needs to check that the interactions have taken place. This is the closing of the accountability loop, the central point checking that the decentralised decisions and activities, have happened and make sense. Planning is the first closure of the loop, does it look like the necessary collaborations have been factored into the plan? Scrum-of-scrums is the next closure of the loop, Release Train Engineer asking if the teams that are planning to collaborate are preparing for it to happen, i.e. reserving time in calendars and booking rooms or conference calls, for those team that have been, or were supposed to be, collaborating are there any impediments? Finally, the System Demo should close the loop and demonstrate the value received from the collaboration: knowledge transferred, artefact received, access granted.
I hope that provides some insight into Practical Cross-ART Collaborations, watch out for the further blogs!
Need help with any of these concepts?