Case studyTransportation

Instantiation and tailoring across mixed life cycles

Two waterfall projects, four SAFe® endeavors, hardware teams carrying functional safety obligations the software teams did not — and agile teams that depended on teams which were not agile at all.

Sector
Transportation
Life cycles
Waterfall, iterative and SAFe® in parallel
Constraint
Functional safety on some systems only
Engagement
Instantiation and tailoring in Applied SAFe®
In short
  • The organization did not have a methodology problem to solve by picking one. It had several methodologies that were all correct for their own work and had to stay in sync.
  • Instantiation gives each endeavor its own tailored version of the process, which is what let waterfall, iterative and SAFe® teams work simultaneously without a shared lowest common denominator.
  • The result was reached without a process engineering specialist: instantiation is intuitive enough that someone new to process engineering can tailor it to their team.

The challenge

The client is in the transportation industry and had begun implementing SAFe®, with teams already using different methodologies. Two projects were running waterfall and four other endeavors on SAFe®, and the two had to be synchronized. Some teams worked on hardware and others were pure software, so their processes had genuinely different needs — parts of the work had to fulfil functional safety requirements and parts did not.

From the beginning the client was worried the transformation would hit large hurdles, because the agile teams had dependencies on teams that were not agile. The goal was a solution that bridged the gap and let different working styles and life cycles stay in sync — not one that made everybody work the same way.

The problemAgile teams had dependencies on teams that were not agile.
Four endeavors on SAFe®Pure software teamsSome working kanban, others scrum. No functional safety scope.
dependencies both ways
Two projects on waterfallHardware teamsParts of the work had to fulfil functional safety requirements.
The solutionInstantiationEach individual project has its own tailored version, reflecting what it actually does — and it is the base for situative tailoring.
  • Waterfall, iterative and SAFe® working simultaneously
  • Common documentation, different ways to get there
  • Full functional safety where it applies, none where it does not
  • Agile and traditional contracting both in place

The goalBridge the gap and let different working styles and life cycles stay in sync — all teams and elements incorporated, agile or not.

What it delivered
30%
less waste, with all needed artifacts in place
55%
less discussion time interpreting what an aspect means
−2/3
ramp-up time, cooperation between business units optimized
3
life cycles kept in sync across six endeavors — waterfall, iterative and SAFe®

What was done

Instantiation, built into Applied SAFe®, gives each individual project its own tailored version reflecting what that project actually does. That is what allowed teams working in waterfall, iterative and SAFe® life cycles to work simultaneously. Instantiation is also the base for situative tailoring, so an individual endeavor can adapt without the baseline being forked.

  • Eliminate unnecessary work — running hardware tests on projects that have no hardware, for instance.
  • Optimize commonly used deliverables so they synchronize across different life cycles, with the main focus on documentation: a common documentation was necessary, but different ways of getting there were as well.
  • Adjust processes to how teams actually work — some using kanban, others scrum.
  • Let some systems prove full compliance with functional safety while others prove none.
  • Work smoothly with both traditional and agile suppliers, since agile and traditional contracting were both explicitly required.

Every team and element could be incorporated into Applied SAFe®, agile or not. In the past the client had tried out different ways of governing the transformation, and the back and forth frustrated employees. With one platform, team members have far more clarity about what they have to do and how they work with each other — and, more importantly, about what everyone else is doing and how it connects to their own role.

What changed

  • Reduction of waste: good engineering practices and aligned deliverables across waterfall and agile cut waste by 30% while keeping every needed artifact in place.
  • Increased team collaboration: hardware teams could focus on the processes belonging to their work and software teams on theirs, while still connecting where they had to.
  • No more treasure hunt: everything in one platform improved the clarity of SAFe® with 55% less discussion time spent interpreting what an aspect means, and faster ramp-up for new hires.
  • Increased flexibility and speed: teams no longer arrange their working style around methodology, so the company can focus on the programmes with the most value rather than the ones most friendly to a SAFe® implementation.
  • Cooperation between business units optimized and ramp-up time reduced by two thirds.
  • The solution-oriented “skeleton approach” to documentation proved the right measure for combining existing documentation with new.

See this against your own operating model.

A walkthrough starts from your structure, your existing processes and the obligations you actually carry — not from a general case.