5 Success Stories That Will Make You Believe in Scaled Agile

Taking your company from Waterfall to Agile isn’t a trivial task. And it begins to look more like a “mission impossible” if we’re talking about large enterprises that have dozens of teams working towards a common goal.

Below we present five case studies that demonstrate just that – that scaling Agile is not only possible, but can also yield great benefits. We hope you’ll learn something new from these examples!

1. LEGO

Agile framework used: Scaled Agile Framework (SAFe)

Year started: 2015

LEGO began its journey to agility by introducing changes at the team level. There were 20 product teams working at the organization at the time. At first, just 5 teams were transformed into self-organizing Scrum teams. Then, bit by bit, the remaining 15 teams followed in their footsteps.

The result of that initial change was that although individual teams had become Agile, they still couldn’t cooperate effectively together. To make that happen, LEGO followed the SAFe framework pattern and added another level of abstraction – the program level.

At the program level, you’ve got a team of teams (also known as Agile Release Train, or ART for short). At LEGO, the team of teams was meeting every 8 weeks for a big room planning session, which lasted for one and a half days. During this meeting, teams showcased their work, worked out the dependencies, estimated risks, and planned for the next release period.

There’s also the portfolio level, which is the top layer of the system. This is where you’ve got long-term business plans, stakeholders, and top management. Such division into organizational levels is typical for the SAFe framework.

Results

• Once you’ve empowered developers to manage their own work, say goodbye to the army of “managers with spreadsheets.” You can stop doing excessive documentation and other unproductive practices.
• Developers now give more accurate estimates, and the outcomes have become more predictable. Previously, the person who shouted the loudest could get their work done faster. Now, with visibility taken to the extreme, decisions are based on real necessity.
• Nothing beats face-to-face communication and the positive effect it has on team morale. Especially the communication that occurs during LEGO’s big room events.

• Visual, almost gamified planning helps focus, makes things obvious and easier to resolve. Giving people independence also makes them more motivated, and they do better work.

2. Cisco

Agile framework used: Scaled Agile Framework (SAFe)

Year started: 2015

This case study has been written by Cisco’s Ashish Pandey. Please note that it concerns a specific Cisco product – the Subscription Billing Platform.

The project used to follow the Waterfall methodology. Cisco used to have separate focus teams responsible for design, build, test, and deploy. Defects were many, and deadlines were being frequently missed. People were working overtime.

Once they switched to SAFe in 2015, here’s what happened.

Cisco created three ARTs* (Agile Release Trains) for:

• Capabilities
• Defects/fixes
• Projects

*In the SAFe framework, an ART (Agile Release Train) is essentially a team of teams.

Every day, the team had a 15-minute meeting to determine work items. With SAFe, they attained greater transparency: each team knew what the other teams were doing and teams were able to manage themselves, promoting accountability through status updates/awareness.

They also combined it with the Scrum framework that was being used on another product – the WebEx app for Samsung. Some XP practices, such as test-driven development and continuous integration (CI), were used, too. The conclusion is that you can use one framework for one product and another Agile framework for another one within the same organization.

Results

Once Cisco started following the SAFe methodology, started to release often, and introduced Continuous Integration (CI), they got:

• A 40% decrease in critical and major defects.
• A 16% decrease in DRR (Defect Rejected Ratio).
• A 14% improvement in DRE (Defect Removal Efficiency) – thanks to CI and more interaction between international teams.
• There is no more overtime, and the product increment is delivered on time.

3. Agile Delivery at British Telecom

Agile framework used: Scrum + XP; 90-day delivery cycles

Year started: 2004

This is a case study by Ian Evans of British Telecom that talks about the company’s transition to Agile. In 2004, a new CIO arrived at British Telecom and decided to change the Waterfall process. The old model was causing a number of issues:

• Too many people were generating requirements; almost all requirements had a high priority; attempts were made to squeeze a maximum number of work items into the next release.
• There were too many intermediaries during the design stage and a painful approval process.
• Development deadlines were hard to meet; there was a lot of pressure on the developers and little time for QA.
• Deployment was a nightmare. Some releases or even entire programs were discarded as being “too late to the party,” being no longer economically viable or too buggy.

To solve these problems, British Telecom decided to adopt an Agile approach to software development and switch to shorter release cycles:

• Instead of documenting all requirements up-front, they decided do user stories and continuous delivery.
• Customers should be directly involved to facilitate approvals and ensure everyone is on the same page.
• They started doing smaller, more frequent iterations to improve quality and have more time for integrating increments into the whole.

Results

When two years passed since the transformation, no one at British Telecom was willing to go back to the old Waterfall model. These were some of the achievements:

• The delivery cycle went from 12 months to 90 days. It now starts with a three-day company-wide meeting, at which shareholders are also present.
• Everyone involved has agreed to set strict priorities and focus only on stories that drive business value.
• At the end of each cycle, the program is evaluated against a set of success markers. The team may be paid a bonus depending on the results.
• Doing things the Agile way has improved developer morale and motivation.

4. The National Bank of Canada

Agile framework used: Scrum of Scrums

Year started: 2012

This case study talks about the National Bank of Canada’s adoption of Agile. One of the key challenges for them was to balance compliance requirements and Agile practices to attain as much agility as they could. There were definitely tradeoffs to be made. There were many things that NBoC just couldn’t leave to chance.

Results

To reconcile the need for agility and the necessity of meeting certain compliance demands, NBoC arrived at some “middle-ground” decisions:

• Backlog requirements should get signed off before they can be selected for a Sprint.
• Sprint approvals were introduced.
• It was decided to create a long-term Sprint roadmap that reflected the company’s strategic plans.
• Architecture was made a deliverable, and it needed to be decided on early in the project (while Agile generally advises you to make major commitments as late as possible.)

Also, since they were heavily regulated, the NBoC arrived at an interesting, innovative method of getting a 2-month Spring approved. They call it the -30 (minus thirty) plan. According to this plan, a team starts gathering and getting approvals for future work items in the middle of the current sprint (30 days in advance, hence the -30 name.)

All in all, the transformation resulted in four major innovations:

5. PTC

Agile framework used: Disciplined Agile Delivery (DAD)

Year started: 2014

This case study talks about Dave Dame helping PTC attain agility by following the DAD (Disciplined Agile Delivery) approach. This method is meant for companies that have:

• Large teams
• Distributed teams
• Legacy code (according to statistics, about 90% of all Agile team are dealing with legacy code)
• A lot of complexity, organizational and otherwise (e.g. technical complexity)
• Regulatory compliance

All of these were true in Dave’s case. Before he took on PTC’s case, he got them to acknowledge that Agile was not a silver bullet and couldn’t be relied on to solve all of their problems.

The challenges

In many ways, PTC was facing the same challenges as the National Bank of Canada from the previous case study:

• It was a heavily regulated space, with a lot of regulatory compliance needed.
• In the beginning, they’d always have gaps between sprints because it was taking a long time to agree on work items and get them approved.
• Initially, they usually had “spillover” – unfinished work from a previous sprint that needed to be carried over.
•  It was difficult for developers and managers to agree on a common Definition of Done. Teams wanted their own DoD, but most of the time it was tricky to reconcile it with the enterprise-wide standard.

The results

What they did at PTC to solve the four above-described problems:

• To avoid getting approval for every tiny feature, Dave decided to differentiate between high-risk and low-risk stories. Low-risk stories do not require approvals, and teams can figure them out on their own.
• At first, a team would finish a sprint and would wait until they could start the next one. To address that, PTC created an Elaboration team. The team’s goal is to continually work on gathering features from customers/shareholders. They may be architects or salespeople. This helped eliminate pauses between sprints.
• To prevent work spillover, PTC figured they needed to do better planning and grooming. They also set aside time in every transition and included tackling technical debt into the planned work.
• It was decided to have 2 levels of DoD, where each team would have its DoD, but also there would be a company-wide DoD to help maintain a common quality.

In Conclusion

Let’s try to single out what the above case studies have in common. All of these companies that implemented scaled Agile frameworks observed:

• Better predictability
• Higher productivity
• Fewer bugs/product defects
• Greater employee happiness
• Faster time to market

Another interesting detail is that at least two companies had to create a dedicated team for collecting work items and planning future work while the current Sprint was still on.

You may also have noticed that pretty much each and every of these organization had tweaked the out-of-the-box framework to their specific needs.

Stay Agile, create better products, and may the Scrum force be with you!