A very interesting (and sad) piece of news made headlines in Spain recently that provides some lessons about agile product development and incremental delivery. Through its national rail line Renfe, Spain paid €258 million to design 31 trains. After design work was well underway, it was discovered the requirements listed the wrong track measurements, which resulted in designs for trains that would be too large to fit through the tunnels on their route. Consequently, the delivery of the trains is delayed for a few years due to the fact that the designs that were delivered are for the wrong size of trains. All because of a misunderstanding about the necessary track size needed for the service area.
How did this happen?
Officials involved in this project made a revealing series of comments about the situation.
“We don’t go and measure the tunnels; we simply take measurements from the company that owns the infrastructure and include them in the specifications of the contract,” sources from Renfe told local newspaper La Nueva Espana.
From the news reports, this was the chain of events: In 2019, the national passenger rail company Renfe published a tender for a contract to acquire 31 trains to renew the fleet in its commuter and medium-distance network. In 2020, train manufacturer CAF secured the contract to build the stock. Renfe passed along the technical details of the trains required to the designers, later saying that it took the measurement specifications from technical information gleaned from a report by the rail track company Adif that included details about the track and tunnel infrastructure.
Renfe — facing criticism for including specifications revealed to be inaccurate — issued a statement that ran, “The problem is that the ‘official’ measurements of the tunnels do not correspond to reality,” pointing the finger at Adif.
Adif hit back, saying it is not responsible for the contract specifications Renfe provided. Everyone involved seems to be pointing the finger at someone else for the error.
In response to the botched project, a political official from the region the trains will serve is quoted as saying, “When a project is launched, one assumes the company in charge knows what it has to provide.”
Not always a safe assumption, it turns out.
It’s easy to pin the blame for this project going off the rails (so to speak) by pointing at the contract requirements document and ascribing blame. But I think the problem runs a little deeper than that.
The reality is that sometimes requirements are wrong. Sometimes the customer doesn’t know what they need. Agile teams face these problems all the time.
Designing and building new products is complex. Requirements change—technology changes. We might have a poor understanding of our customer’s needs. You only know if something will work once you try it.
A predictive approach to solution delivery can be too restrictive and rigid in complex environments or when we are creating something new. It can result in some unpleasant surprises when the product finally arrives.
Fortunately, there is a better way.
Agile organizations accept that they don’t know everything. Instead, they use uncertainty for the customer’s benefit. Could Spain have avoided its predicament by using an agile approach? Let’s look at a few examples as a thought experiment.
Step into Agility with transparency during design
Agile is an umbrella term that we use to describe an unlimited number of frameworks and practices that enact the principles and values of the Agile Manifesto. One of the most popular Agile frameworks is Scrum, which relies upon the three pillars of empiricism (transparency, inspection and adaption) to harness change for the customer’s benefit. Today, 87% of agile teams use Scrum (16th Annual State of Agile report from Digital.ai). Teams use Scrum to build all kinds of complex products, from aircraft to infrastructure. We can even use Scrum to deliver train designs.
If the designers had used Scrum to deliver the plans for the 31 trains, they would have met with Renfe and other stakeholders at least once per month to discuss what was done and to request feedback. This event is called a Sprint Review and it likely could have revealed the error much, much sooner.
At the Sprint Review, Renfe and it’s stakeholders would then have the opportunity to correct any mistakes (such as any errors around the track or train size) and to provide additional suggestions for improvements. This back-and-forth would have ensured a better outcome during the design process.
Expand the use of Scrum beyond just design
An even better approach might be to expand the use of Scrum beyond just design. Scrum can be used to remove impediments and focus on continuous improvement for the organization which supports Agile teams. It can even be used to identify and test changes to physical products such as jet planes. This approach is used in aerospace to design and build new planes and to improve existing designs. This iterative approach results in better design because changes can be identified and tested in a relatively short amount of time.
Conclusion
New product development is a complex process with many ups and downs. To help ensure that your project does not go off the rails, consider using Scrum to harness the power of change for your customer’s benefit and to embrace frequent inspection and adaptation to prevent costly misunderstandings.
Learn more by joining Rebel Scrum at an upcoming Applying Professional Scrum course. It really is Scrum 101! For more information about how to get started with Scrum, check out Rebel Scrum’s How to roll out Scrum in your organization (rebelscrum.site).
Join us for Scrum Day 2023 in Madison, Wisconsin
Join us to engage with those at the forefront of Scrum and uncover new ways to unleash human creativity to deliver more value.
Scrum Day features thoughtful discussions and short, interactive training on the Scrum framework. There is no better, more affordable opportunity to learn from Scrum experts and colleagues.