This is an account of the results obtained by companies
adopting a heavy-weight scaled Agile framework
instead of pursuing Agility at scale,
or migrating to a heavy-weight off-the-shelf software platform
instead of pursuing technical excellence.
Feels free to copy and distribute this post as you please. Get in touch to suggest any improvements.
Compare this account with How large successful companies achieved Aglity at scale.
Both FitBit and Volvo Cars, for about two years, went through an Agile transformation to scale Agile using a heavy-weight scaled agile framework.
YNAP and Co-Op Insurance both tried to migrate their strategic and core systems developed internally to a heavy-weight off-the-shelf platform.
Heavy-weight scaled agile framework here is intended, for example, as one with a guide of several hundred pages (instead of few tenths), that requires configuration and tailoring-down (instead of being simple and partially incomplete to fit loosely to leave room for adaptation and manoeuvre), with roles that increase the deep of the hierarchy and the hands-over (instead of flattening the hierarchy and supporting self-organisation).
Heavy-weight off-the-shelf platforms and out-of-the-box configurable white label products here is intended, for example, as overcomplicated and rigid third-party products that end-up requiring significant rewriting work, huge and complex data migration, and are hard and difficult to customise to fit the always changing and evolving market requirements.
For FitBit, YNAP and Co-Op Insurance this had a very tangible and negative impact on their business. No tangible impact can currently be measured at Volvo Cars (it is too early to say at the time this post is written).
FitBit and Volvo Cars case studies don’t show signs of a strong focus on tech excellence. The technical approach at YNAP and Co-Op was shattering.
None of the four companies shows any sign of alignment to the Agile mindset (that is considered a fundamental ingredient of any successful Agile adoptions), or any sign of autonomy of teams.
Ar the end of this post, there is also an account of a session at a summit that mislead attendees to believe that Microsoft adopted a heavy-weight scaled “agile” framework to successfully achieve Agility at scale. This is a testimony of the aggressive marketing of Scaled frameworks that go beyond genuine and authentic sharing of lessons and learnings. For the real story of how Microsoft pursued Agility at scale, follow the link at the beginning of this post. For another PR stunt from the aggressive marketing of Scaled frameworks, see the USAF notes following the link at the end with comments from experts.
These stories shared below provide good learnings about things that did not work well for these companies. Correlation does not imply causation, so use these learnings to inform and inspire the experimentation in your company with an experiment-learn-adapt-evolve approach.
Fitbit Inc. is an American company founded in 2007 with the headquarter in San Francisco. It now has about 15 offices around the world. In 2019 Fitbit reported to have sold more than 100 million devices and have 28 million users.
Between 2015 and 2016 FitBit adopted a heavy-weight scaled Agile framework to scale their Scrum effort. They started in 2015 with 12 Scrum teams, that in 2016 worked at the release of four new products. That is an average of four teams per product.
Damian Brown, Sr. Director of Program Management Office, describes the adoption of the scaled framework as a success story. He describes such success highlighting these results:
The first three points seem to describe success in traditional predictive planning and processes terms such as delivering on-time and on-budget, etc. They are not representative of a paradigm shift or an Agile mindset.
The last two points are more troubling. Marked data and statistics available online seem to contradict both of them. The growth rate of the number of employees started to decline in 2016 and then got worse. This is hardly growth. In 2016 the stock price of FitBit did fall more than 75% and has yet to recover as today. This is hardly a success.
Analysts explain the downward spiral due to lower margins and increasing competition. A series of earnings reported feature vast increases in spending and weak guidance. All these signs are congruent with other comments about a lack of innovation in FitBit.
So fare there are no tangible and long-lasting benefits for the business coming from the adoption of the scaled framework.
Furthermore, the case study does not suggest there has been any focus on teams autonomy and strong engineering culture.
Volvo Cars was founded in 1927. It is headquartered in Gothenburg, Sweden. it has around 40,000 employees and produces around 700,000 cars per year.
In software development, it employs about 10,000 people with about 150 million lines of code per car. Nowadays cars are steadily becoming “computers on wheels”.
Volvo Cars went through 2 years and a half Agile transformation phase to scale Agile with a heavy-weight framework. That effort has been completed in December 2019. Anna Sandberg, Head of Continuous Improvement & Change at Product Creation, says Volvo Cars Agile journey will continue after this phase.
Volvo Cars for some years had a bottom-up Agile movement. There were individuals and software teams that had been attracted to Agile for many years. But Volvo Cars hadn’t managed to scale those efforts. This Agile transformation had the intent to scale such effort across the software community, and the whole product range, both hardware and software. Volvo Cars felt the need to develop the software and hardware at the same time in an integrated fashion. Because they knew that things were going too slowly compared to changes in the automotive world.
Now just after the transformation is finished. It is too early to say if there are tangible and lasting benefits for the business, or if innovation/flexibility/resilience have improved. Or if this change will be sustainable and will stick.
In the transformation a huge amount of time and money have been spent on scaled Agile training: “We spent more than 150,000 manhours in training people in different aspects of Agile. We also trained around 2,000 leaders”.
The interview to Anna Sandberg leads to assuming the absence of a strong focus on removing technical dependencies and technical debt to support the scale and the speed, instead the focus has been on accommodating existing technical dependencies: “we can identify dependencies and see whether actions and resources match with commitments”.
When asked about mindset, this is the language used in the answer: “We *need* to realize that doing Agile at scale requires … *protect* the principles … I don’t know how to do Agile at scale without some kind of framework and *hierarchy* that helps us to decide and prioritize.”
The interview also shows through a focus on processes, and the hierarchy with a traditional top-down approach. While there is no signs of focus on the Agile mindset.
The lack of focus on the Agile mindset is highlighted also by two academic case studies from the Chalmers University Of Technology.
The first study is titled: The role of the First Line Manager in a Scaled Agile organization A case study at Volvo Cars Corporation. It reveals that Volvo Cars retains a very tall hierarchy even after the transformation. The study says Volvo Cars appears to have scaled Agile vertically by implementing Agile practices throughout the management hierarchy.
The same case study states that at Volvo Cars the Product Owner is not really considered part of the team. While the Scrum Master role is a less important role compared to the first line manager role (FLM as in the picture below) and ti is fading or taking a smaller role in the organisation, with less authority and responsibilities, as a consequence of scaling Agile. These interpretations of the Scrum Master and Product Owner roles differ from the original interpretation in Scrum, and not necessarily for the better.
The case study adds that as a consequence of the transformation, the first line manager role (FLM) has not changed significantly and that its supervising role had only strengthened because of its position in “systems of external, hierarchical supervision”. Even so, the theory and results from the interviews suggest that Volvo let managers stay in the same position.
The study also comments on the inflexibility of the scaled Agile framework adopted mentioning two disadvantage a) its inflexibility in the implementation, and b) it potentially preventing from finding solutions outside of the framework.
The tall hierarchy, the lack of authority and consequently autonomy of SM, PO and the teams, are all clearly misaligned with an Agile mindset.
The title of the second case study from the Chalmers University Of Technology is: Large-scale agile transformation A case study of Volvo Cars’ transformation process. It highlights the perceived success factors of Volvo Cars Agile transformation, in the image below.
At the top of the list of success factors, there is the very old school traditional RACI concept, while some of the key aspects of Agile, such as the incremental and experimental approach, are at the bottom of the list. That also suggests a lack of alignment with the Lean and Agile principles and the Agile mindset.
In 2015 Yoox and Net-a-Porter merge created YOOX Net-a-Porter Group (YNAP), an Italian online fashion retailer. Yoox was founded in Milan in 2000. Net-a-Porter was founded in London in 2000.
Yoox concept is to buy up overstocked or unsold items from previous seasons and sell them online at discounted outlet prices. Net-a-Porter was developed from the concept of a magazine in website format where users could ‘click’ to buy while trying to source products online for a fashion shoot.
The group in 2018 had about 5000 employees.
Prior to the merge, both Yoox and Net-a-Porter were adopting Agile ways of working and trying to improve the technical quality of their platforms to support their growing number of customers and to match the evolving expectations of the tech-savvy customers. At that time a strategic decision was taken to build a single technology platform that would be shared across all the group’s subsidiaries.
Prior to the merger a decision was made to bring in IBM as a partner, and Chief Technology Officer Alex Alexander, hired for his understanding of IBM’s software, was tasked with leading the transformation. The goal was to migrate the exiting platform to IBM products such as:
– IBM Sterling Order Management
– IBM WebSphere – Open Commerce Express
Third-party off-the-shelf platforms like these come with hidden costs of configuration, customisation, and migration. They typically area monolithic and have their roots in old technologies and outdated philosophies, so the migrations tend to be similar to old-style big-bang waterfall type of initiatives, with all the well-known downsides that go with it. These overcomplicated and rigid third-party platforms make it harder and slower to keep up with continuous changes and improvements and regular technology upgrades that are a necessity for e-commerce businesses in a fast-moving market.
Other fash-tech companies have faced the same challenges while adopting similar third-party off-the-shelf old products (e.g. Oracle Retail, etc.) with help from large, slow, and traditional consulting companies. Bernstein analyst Luca Solca wrote: “Mega-brands — who dominate the luxury industry today — have little to gain long-term from feeding ‘winner-takes-all’ third-party distribution platforms,”
The project was ambitious in both scale and scope, but the full extent of the troubles at the luxury e-commerce platform, was not made clear until mid-May 2019. The trouble with the digital transformation started more than three years ago and has cost hundreds of millions of euros. The growing costs stemming from the global technology and logistics platform migration were estimated at €200 million ($221 million) for the fiscal 2019 year alone. Sources close to the operations suggest that the company will end up spending far more than the €500 million it originally budgeted.
For 12 months after the launch, The Outnet (one of the online shops of the group) saw year-over-year sales decline every month. Richemont, that acquired the group in 2018, announced its financial results for the previous fiscal year as its weakest profit margin in more than a decade, taking analysts by surprise.
The new platform made it difficult also for shoppers to easily navigate the site and perform basic functions.
In December 2017 one New York-based shopper wrote on Complaintsboard.com “I don’t know how and why, but now it works more terrible than it used to be”, “Now it’s absolutely uncomfortable to use it… I don’t understand what was the point of this nonsense.”
The re-platforming has sparked complaints also from senior executives. There has been a talent exodus within the group. In the past three years, at least 20 of the group’s senior executives have left. Many of their direct reports have departed as well. Complains of mismanagement and scapegoating has eroded the morale and affected the company culture.
In conclusion investors, customers and employees have faced tangible and lasting negative consequences from a digital transformation that tried to solve a complex problem ignoring technical excellence and the engineering culture, outsourcing and delegating the responsibility in the search for the mythical silver bullet, damaging the company culture and alienating employees and customers.
Co-op Insurance with the trading name of Co-op Insurance Services Limited is based in Manchester and was founded in 1867.
It currently offers business, home, motor and pet insurance products.
Co-op Insurance is part of the Co-operative group that has more than 100,000 employees.
Co-op Insurance started a transformation programme to migrate from the legacy IT infrastructure to a new, modern insurance platform for powering the insurance company’s operations.
The solution pitched and sold by IBM consisted of an out-of-the-box configurable white label Insurer Suite.
In January 2015 Co-op Insurance and IBM signed a £155m Agile project intended for IBM to deliver what promised silver bullet.
After that brilliant sell from IBM, it rapidly emerged that the out-of-the-box configurable white label Insurer Suite silver bullet was a platform that had been written specifically for the US insurance market, not the UK insurance market, and so it had to be substantially rewritten and re-developed. The platform needed significant work to be fit for use in the UK market.
Additional problems were caused also by the data migration.
Unsurprisingly, 15 months after its deadline the contract had not been delivered. In December 2017 a lawsuit was filed by Co-Op Insurance against IBM.
In addition to the unrealistic promises made to close the sale, there have been many serious mistakes in applying an Agile methodology:
In conclusion, to close the sale promising a silver bullet, IBM largely minimised and underestimated the changes and the work requires to deliver the solution.
As it commonly happens in such situations, also the complexity, the effort, and the time required for the data migration have also been largely underestimated.
On top of this, for the project, IBM has adopted an Agile methodology even if the fundamentally misunderstood even the basic aspects and the essential elements of Agile Sofware Development.
There are many public unanimous accounts from different sources about Microsoft journey to Agility at scale. They all agree that Microsoft has grown internally their ways of working without following or taking inspiration from any scaled framework.
At a summit of one of the scaled frameworks, one session misled some of the attendees to believe that Microsoft employed a scaled framework for its journey to Agility.
If the public accounts were not enough to prove wrong such narrative, sources with direct knowledge of several teams at Microsoft confirmed that they do not use any scaled frameworks and did not use them to scale Agility in Microsoft.
In the whole Microsoft only one team from a small peripheral service division, Supply Chain Engineering (SCE), used a scaled framework. It is not clear if that division has been acquired by Microsoft while already adopting practices from a scaled framework, or if the division used the autonomy granted to the teams to make such a decision. It is peculiar that the scale in such a department does not seem to call for a scaled framework.
In any case, it has been confirmed that Microsoft doesn’t and did not use scaled frameworks for its Agile journey.
Since the publication of this report from USAF that lists the flaws of SAFe and advice against it (see here at the end of the post), Scaled Agile Inc offered to work for USAF to address the criticism. After that, a couple of publications seemed to imply that the comments have been addressed and SAFe was ready to be adopted by USAF.
Instead, Nicolas M. Chaillan clarified: “my memo on SAFe still stands regarding my take on SAFe with DevSecOps. Until the issues mentioned in the memo are fully addressed with a released update of SAFe, SAFe is still not recommended to be used in conjunction with DevSecOps.” (link).
And later in March 2021, Nicolas M. Chaillan clarified again that the previous criticisms still stand (link): “SAFe is still anti DevSecOps. Not allowed in my teams.”
I personally find the PR stunt above from Scaled Agile inc. troubling and it raises questions on their professional competence or integrity.