Multi Modal Delivery with SAFe 4.0
SAFe 4.0 provides the constructs to integrate workstreams across multiple organisational units and methodologies into a single Solution Delivery.
As enterprise-scale organisations transition towards Agility, it is unrealistic to expect all software delivery groups to change in lock step. Deliveries – even those led from Agile advocates – that involve multiple groups inevitably need to integrate Agile and old-world methods. This is further complicated where some of those groups belong to different organisational entities, even external suppliers. SAFe 4.0’s Value Stream layer provides the constructs needed to do this while keeping the Agile Train on the tracks.
As we work with large scale, risk-averse customers in regulated industries, we find that they are increasingly dissatisfied with traditional methods of systems delivery, and increasingly open to Lean & Agile ways of thinking and working. However, as they try to do this with common, team-level constructs such as Scrum, they find that they struggle to make it work across organisational boundaries. A primary factor in this is that they understand that moving all systems delivery to new ways of working at the same time presents a significant burden on their capability to manage and absorb change, as well as a significant risk. This is perfectly understandable and correct – even change programmes need to consider the impact of excess WiP and control queues.
This is not to say that Bi/Multimodal IT is a desirable target state of affairs, but as large organisations move towards Agility, it’s an interim reality in the transformation period, which may be anything up to a decade.
1 – Source: Actuation consulting 2015 Study of Product Team Performance
At any given time, therefore, some parts of an organisation will be adopting Agile thinking and practices, and some parts of an organisation will not. This will often follow the standard technology adoption curve, playing out in a similar pattern to the wider industry. Within the organisation there will be teams and groups of innovators, early adopters, the majority and laggards. Often, the most customer facing, disruption-prone teams such as mobile and web will be amongst the most enthusiastic adopters of change, while traditionally minded, harder to change areas such as mainframe will be slowest. External suppliers will also pull forwards into the new world.
The realities of business and customer needs however do not stop and do not respect organisational boundaries nor cultural appetites for change. The disruptive nature of even conservative industries such as banking drives demand for apps that bring together many components, irrespective of where they live and how they’re delivered.
This presents a headache for the Agile-minded delivery leader, struggling to integrate deliveries from a hyper-Agile Lean UX/Lean Startup-minded mobile apps supplier with mainframe waterfall, linked in the centre by an Agile Release Train for the process layer, where each of those has its own independent delivery value stream, running from Concept to Cash in its own context.
Commonly found Architecture supporting Credit Product Applications.
To create an integrated system that actually creates value for customer and business takes capabilities that take trips piercing multiple layers, touching multiple systems, each with their own ingest and delivery model for new functionalities. In the example above, generated from a real customer situation, the process layer comprises a team of teams that in itself operates as an Agile Release Train. However, this needs to be timing orchestrated and technically integrated with deliveries from other groups. The customer facing front ends are delivered by an external supplier who is running traditional Scrum on a 2 week iteration cadence, while the back end Mainframe Services delivery has not yet transformed, and is operating on a traditionally planned project basis.
SAFe 4.0 provides the conceptual model that integrates all these delivery Value Streams. While the centre may be running fairly textbook SAFe in a Release Train, nobody else is. To minimise the systems-level problems that are only visible when the whole system is brought together, and to ensure a shared planning basis, the Process Layer’s Programme Management defines a cadence as follows:
This being the closest layer, it is the easiest to control. It is comprised of a team of teams, so runs classic SAFe as an Agile Release Train, with team-level demos and planning every two weeks, with a Program Increment Planning every quarter – this aligns to the bank’s release cycle which at present only has 4 release windows a year, and it supports the Branch Network and Contact Centre’s understanding of their transaction costs related to training on new versions.
It’s reasonable to argue that this window should be more frequent and that the transaction costs should be reduceable with smaller change sets, but this discussion is ongoing.
Depending on cumulative total size, these may join the Process Layer’s ART, or if the total is greater than approximately 120 practitioners, it will be necessary to split the Value Stream into two parallel ARTs that work fairly closely together, co-operating particularly strongly for integrated demoes every two week iteration.
Alternatively, if the organisational boundaries are strong, they may be independently planning and delivering teams whose workload is only partially made up of this system’s capabilities. In SAFe terms, each separate unit should be considered a Supplier Value Stream, which operates similarly to the External Interactive Components
These are delivered by third parties, who run their own cadence. Being front-end based, iterative and incremental delivery is normal for them, and generally they will run one week or two week length sprints.
The objective here is to plan and deliver a release together and discover user behaviour in real life use, to be able to iteratively improve the user experience.
This is its own Supplier Value Stream, but will deliver and integrate code much more frequently than the release cadence. We can give a high level plan for their sprints via PI planning, and inject stories for the front end affordances to process functionality via their Sprint Planning, reflecting actual progress and availability of process features. This means that our sprint System Demoes can be driven as actual user experiences from both internal user and external customer perspectives, and we can conduct private user testing with a real, working system on a more rapidly iterating cadence than the release.
In our example, these are still delivering in a Waterfall approach. Our immediate aim is to break down the batch size and encourage smaller but still releasable chunks of functionality, integrated into the whole solution..
In SAFe 4.0 terms, we are treating them as an external supplier, running in their own Value Stream. How they work internally is their own concern, but we kindly request that they deliver to the whole solution in a series of successive 12 week projects, synchronised with the PI cadence of our Process Value Stream.
Naturally we will invite them to PI planning to help contextualise their work, and ensure that we are able to understand and meet any dependencies they have.
It’s also likely that around week 6-8 of a 10-12 week Planning Increment, these teams will have pre-test code available. While there is a strong risk of internal Mainframe defects still existing at that time, it’s often helpful to have this available for early Integration Testing, to form an early view of where systems level problems exist. We therefore have to continually communicate that we understand and expect there to be outstanding defects, and will have a very forgiving nature to them at this point in the cycle; it’s our end and how it hooks together that we’re testing.
We would like to encourage them into the Agile mindset, so we will additionally extend a standing invitation to all demoes and retrospectives. As we build a trust relationship with them, we will also encourage them to split a Release (12 weeks) length project into two, with an interim release to internal stakeholders for early feedback, and ask for milestone deliveries with increasing frequency. Can they pull API work forward? Can they stage more frequently?
We will also request that – wherever possible – they apply a consistent group of technical practitioners to working with us. All this will not only make this delivery more effective, but will also lower the threshold of change when they are deciding whether to take the step into Agility.
Like the Mainframe group, these are treated as Supplier Value Streams, invited to all Solution Level ceremonies and the main PI Planning event, and requested to deliver in 12 week projects, with a true end to end Field Test in a model office before release to use with real customers. As we gain trust with them, we aim to increase the integration and FAT frequency.
“[This is] exactly the way we started when I worked for big insurance. Started with treating Mainframe as suppliers since “they” weren’t interested. Over time, when they saw the cubicle walls come down and people talking everyday, they started imitating. And then asked for coaching.
From a delivery stand point, we had old fashioned big visible charts that mirrored story cards plastered on the wall. It became focal point for conversations about dependencies, feature-focused value delivery and the like.
Subtle influence over management mandate won the day.”
By using SAFe 4.0’s Value Stream constructs & ceremonies, we are able to co-ordinate multiple organisational groups working in multiple delivery methodologies into a single, aligned, Agile Solution. As those groups evolve individually towards Agility, the whole solution will accelerate and start truly Sprinting together.