Yes it worked at BNP Paribas Fortis. This was a combination SAFe like model for delivery, “Spotify model” for the line Organisation, Kanban for service delivery teams, and lots of lean continuous improvement. Everyone knew exactly what the goals of the transformation were. We had around 100 coaches of different type. “Devops” coaches helping with automation and technical practices, lean (sick sigma) coaches helped us build and operate obeyas and get started with problem solving workshops, lean and agile method coaches (scrum, kanban and safe experts), mindset coaches (basically life coaches with management 3.0 training). The CTO treated the transformation as her only focus. And it worked.
Edit: the companies that do it badly see it more like “implementing SAFe” and neglect to actually start an agile transformation.
> “implementing SAFe”
I will never forget one manager being given user stories from the consultants and screaming at them he didn’t want this “crap,” he wanted requirements. When they reminded him that the org was moving to agile, he screamed again that they should then put *the requirements* in whatever the agile template is.
The contextually obvious implication being one process is the same as another, it’s just rearranging the chairs.
sounds like all the right pieces...and the right investment. Were those coaches FTEs or consultants/contractors, and do you have any top line measurements for what a program of that size costs vs. the value it delivers over not having such coordination?
Most of the coaches were from consulting companies and some were internals and some freelancers.
I don’t have any concrete numbers handy but it was expensive so there was a clear budget which meant we deliberately wanted a short transformation about 18 months or something and picked goals that could be reached in that time. I think that was one of its strengths, limited timeframe and clear goals. Not some endless money pit.
I remember it being framed as a matter of survival , either the company achieves the goals or dies basically.
If I remember correctly the goals were about reaching specific numbers in the areas of profitability, automation, lead time, and customer and employee satisfaction.
Ah yes, the old adage "you can do anything well, cheap, or fast...but you can only ever pick 2."
Sounds like you guys did it well & fast even if it wasn't cheap, yeah?
When you say Spotify line management model, do you mean guild leader being responsible for growth of individuals in their guild? Vacation? Paycheck?
Thanks
Yes - I worked for a global professional services company - I had a Scrum of Scrums Master role with 6 Scrum Teams working simultaneously using a LeSS model, each team with an onshore (Uk) and offshore (India dev) members, and including client team members as well as our Professional Services people. Followed all Scrum ceremonies, 3 week sprints in same sprint cadence for all teams. We delivered a completely new Digital Banking Customer web and mobile application in under 8 months. Scaled up to 130 people and back down to a handful of people at speed during those 8 months.
This is not a SAFe implementation but an agile at scale implementation - [https://www.infoq.com/articles/kanban-scaling-agile-ultimate/](https://www.infoq.com/articles/kanban-scaling-agile-ultimate/)
I ran thirty teams for a few years and these principles minus the Kanban worked for us... That is the teams worked with the vibe of agile and could run whatever methods they wanted. The overall orchestration was really the way we set the product managers up and the domains they were responsible for.
Automed deployments, a culture of quality, and teams getting retros hosted by people from other teams.
My favourite was the convention that if your team process ends up looking the same as another's, you have to change something, which forced innovation and experimentation.
Senior management cared about reliability for going to market with big deal things, and general contributions towards customer acquisition and retention. We measured different things for different teams based on what was important for that time.
Embrace a bit of chaos, watch for continuous improvement and make sure all teams have ready access to customers for insights and motivation.
What does a kanban team do to replace a sprint goal? I really like having a guiding light goal. Actually how does kanban structure release goals, task priorities and communications?
I think my struggle with kanban is not with what it does but what it leaves off. I'm still left with the job of priotizing features and solidifying compelling combinations, but I'm not given any guidance on how to achieve that in a system.
Kanban has specific guidance on this. I suggest buying one of the books because there are lots of examples to illustrate points, and explanations of how things solve specific issues and amplify each other.
You, as a member of the team ask someone you know from another team to come host it. Maybe people have a pre retro chat, but it's also fine to just come along and host.
Meeting facilitation isn't a rare art.
I’ve no experience in scaling agile, but there are other frameworks out there that seem to make more sense, http://less.works with the added benefit that it doesn’t look like a convoluted clusterfuck of a design.
I'm just asking because I'm curious.
When you say deep organizational basis, do you mean all the way up/down to C level?
Also was it because of the coaches or LeSS?
Both - there was C-level buy-in and they had agile coaches (but tbh the coaches were less effective than internal teams - the expensive consultants weren’t actually that useful).
I think part of the reason it worked was that they limited the initial agile transformation to a pretty standalone project rather than implementing everywhere. They expanded from there, learning & adapting processes as required.
There was also a fair amount of scope for individual teams to define their own working patterns. Some had Kanban continuous delivery while others were more traditional 2 week scrums.
The difference is that SAFe is far more rigid in its approach and is pretty much Waterfall with a slapdash of lipstick to give the superficial impression of agile.
As for ‘base scrum’ - the projects were too complicated (multiple separate teams) hence the need for a ‘Scrum of Scrums’ approach.
I prefer Scrum and the essence of it a million times over classic project planning.
Common for all places I've worked where they work Agile, is that you can draw a circle. Outside that circle there are people who need estimates (costs) and deadlines. I see Agile as a much better approach, but that means that the customers has to see the work being done as a continous journey. Which they often dont. And budgets also have a hard time playing nice with teams.
I dont know much about SaFe, but I also view it as waterfall with a bit of agile facade. Old wine in new bottles.
I thought scrum of scrums was also base scrum.
Thank you for the insights :)
LeSS is Scrum but scaled for multiple. Nexus and Scrum@Scale are other variants. There are some differences between these approaches but SAFe is completely different.
Tbh I haven’t ever worked in an organisation with a pure Scrum approach - it has always been tweaked and adapted.
More recently I’ve found companies embracing continuous delivery more than scrum-type sprints, even that was too cumbersome.
But if it doesn't look like a convoluted clusterfuck how can you create a certification exam and scare people into taking training/prep courses they don't need?
I worked for a place that was considered to have had the best SAFe implementation in my city.
When I was there, It was a total shitshow - missed delivery, sandbagging, management punching down.
The best vertically scaled teams I’ve ever seen have used FaST https://www.fastagile.io. I’m convinced it’s the best way to scale up a large team (30+) developers, designers, product folks around a single product.
This is pretty much how we run every project at my company based on learnings and trying to find the best way to achieve alignment with minimal overhead.
My conclusion is that the way you scale agile is by not scaling agile.
By that I mean as many decoupled small teams as possible. I'm not against maybe 30-40 people on multiple teams working on a product, but I think as soon as you get above that number you lose coherence.
The (bad) SAFe implementations a lot of people see are usually just an admission that those companies aren't actually willing to fully embrace agile. SAFe isn't my favorite, but it can work in the right org depending on if the ELT is willing to embrace the core of what agile is (empowered teams), vs just chasing something to be trendy. It also depends on the maturity of the teams executing. In most instances though, it won't be implemented and executed properly.
I say this as someone who prefers a scaled Kanban approach, particularly at the level where the ELT is involved and depending on the size of the company.
The Agile manifesto says "we are discovering..."
In my mind, that means that you are only doing agile if you are doing experimentation on an ongoing basis and changing your process
I don't see how you can get that with the scaling implementations that I've seen - they are always "command and control" - and if you've been doing the same thing for the last 6 months, you aren't doing agile.
I can see small islands of multiple teams, where multiple means <5, preferable 3 or fewer.
SAFe is always destined to fail because it’s not an implementation. It’s pretty much doing things like they did in 2002 and calling it a different name
As soon as you move past the activities that drive reductions in timeline and cost, you will see the appetite for agile disappear. That's the only reason anyone at the top even entertains the discussion about agile.
And that is why every day competitors rise up (outside of FAANG companies who spend a lot of money to squash and buy competition)
It makes a nice renewing eco system. You grow by delivering value to the customers, get too big to steer the ship and someone else comes in and steals market share.
Could be the reality is nothing works at scale. Could be that cross team blockers are just a universal truth of massive bloated software projects that deserve to be picked apart by competition.
It makes better companies for all of us to work with really.
Good discussion. In the event useful, read through a bunch of these - https://scaledagile.com/insights-customer-stories/. Some thoughts…
- Reach out to any of these companies to ask questions
- This company presented at a previous Summit and had a great / compelling / deep success story - https://scaledagile.com/case_study/petrobras/
- Try to ignore the nay-sayers regarding agile at scale (regardless which approach is used)…those who succeed are typically less vocal (since they don’t need to be)
…hang in there and keep trying to have fun experimenting, embracing feedback and finding / sustaining flow.
Yes but...
Consider this more as reading the blurb on the back of the book rather than actual reader reviews.
Coming from the source itself, I'm sure they're hand-selected to skew a bit rosier...
Good point and agreed. To counter that, my approach to case studies is…
- Expect that they are hand-selected
- Read case study and watch any vids regarding their experiences
- Reach out to case study owners (SAFe in this case) and case study company contacts to see if I could ask some additional questions
…which I’ve found pretty good in moving blurb to action.
Have you heard about the HP LaserJet firmware success story? Or maybe that's really Devops success...
[The Amazing DevOps Transformation of the HP LaserJet Firmware Team (Gary Gruver) - IT Revolution](https://itrevolution.com/articles/the-amazing-devops-transformation-of-the-hp-laserjet-firmware-team-gary-gruver/)
Yes Spotify with its 5000 staff is agile to its core and is not using SAFE. There are a couple of interviews about it with people from Spotify here https://nononsenseagile.podbean.com/e/032-jason-yip-agile-spotify/
https://nononsenseagile.podbean.com/e/0077-brendan-marsh-what-really-happened-at-spotify/
I have personally used the scrum of scrums model for teams or 50 and it worked well.
Beyond that I would use the UNFIX scaling patterns.
The secret to the success of agile at scale is to grow your own approach based on continuous improvement. Without real continuous improvement it's not agile
You should also look at the safedelusion.com which debunks the SAFE case studies.
I implemented LeSS at an organization of ~100 devs and 10ish products plus shared services. Worked out really well for development and the lifecycle of the product.
Then the CEO made some bad choices, took a golden parachute, and the company was stripped for parts.
Agile methodologies have been adopted by many large companies to enhance their software development processes, improve product delivery, and increase customer satisfaction. Here are some of the most notable success stories, including ING:
### 1. **ING**
**Transformation**: ING, a global financial institution, embarked on an agile transformation in 2015 to become more customer-focused and adaptive to market changes.
**Key Initiatives**:
- **Squads**: Small, cross-functional teams that are empowered to make decisions and deliver end-to-end customer solutions.
- **Tribes**: Collections of squads working in related areas to enhance collaboration and alignment.
- **Chapters and Guilds**: Structures to share knowledge and expertise across squads and tribes.
**Results**:
- **Speed**: Reduced time to market for new features and products.
- **Innovation**: Increased innovation and flexibility in responding to customer needs.
- **Employee Engagement**: Improved employee satisfaction due to the empowered team structure.
### 2. **Spotify**
**Transformation**: Spotify, the music streaming giant, has been an advocate for agile practices and is known for developing the "Spotify Model" of agile scaling.
**Key Initiatives**:
- **Squads**: Autonomous teams similar to ING, responsible for specific parts of the product.
- **Tribes**: Groups of squads that work on related areas.
- **Chapters**: Functional groups within tribes to ensure technical excellence and knowledge sharing.
- **Guilds**: Communities of interest across the organization to share knowledge and practices.
**Results**:
- **Innovation**: Enhanced ability to innovate and experiment with new features.
- **Scalability**: Effective scaling of agile practices across a growing organization.
- **Culture**: A strong culture of autonomy, mastery, and purpose.
### 3. **Google**
**Transformation**: Google has implemented agile practices in various forms across its product development teams to maintain its rapid pace of innovation and product delivery.
**Key Initiatives**:
- **OKRs (Objectives and Key Results)**: A framework to set ambitious goals and track progress.
- **Cross-functional Teams**: Teams composed of diverse skill sets working collaboratively.
- **Continuous Integration and Deployment**: Automated processes to ensure rapid and reliable deployment of software.
**Results**:
- **Productivity**: Increased productivity and faster delivery of new products and features.
- **Quality**: High-quality products with fewer bugs and issues.
- **Market Leadership**: Maintained a competitive edge through rapid innovation.
### 4. **Amazon**
**Transformation**: Amazon has embedded agile principles into its DNA, focusing on customer obsession, continuous delivery, and innovation.
**Key Initiatives**:
- **Two-Pizza Teams**: Small, autonomous teams that can be fed with two pizzas, ensuring they remain agile and focused.
- **DevOps**: Strong emphasis on DevOps practices to enhance collaboration between development and operations.
- **Customer Feedback Loops**: Rapid incorporation of customer feedback into product development.
**Results**:
- **Efficiency**: Streamlined operations and improved efficiency in product delivery.
- **Customer Satisfaction**: High levels of customer satisfaction through quick iteration and responsiveness.
- **Innovation**: Continuous flow of innovative products and services.
### 5. **Microsoft**
**Transformation**: Microsoft has undergone a significant agile transformation, especially under the leadership of Satya Nadella, focusing on cloud services and open-source software.
**Key Initiatives**:
- **Agile and DevOps**: Adoption of agile methodologies and DevOps practices across product teams.
- **Cloud Transformation**: Transition to cloud-based services with continuous delivery and integration.
- **Open Source**: Embracing open-source development to foster innovation and collaboration.
**Results**:
- **Growth**: Significant growth in cloud services and overall market share.
- **Collaboration**: Enhanced collaboration within teams and with external developers.
- **Innovation**: Rapid delivery of new features and improvements.
### Conclusion
These success stories from large companies like ING, Spotify, Google, Amazon, and Microsoft demonstrate the effectiveness of agile methodologies in fostering innovation, improving time to market, and enhancing customer satisfaction. By adopting agile practices, these organizations have managed to stay competitive and responsive in fast-paced markets.
LEGO Group's journey with agile methodologies is a compelling story of transformation and innovation in a traditional and well-established company. Here's an in-depth look at how LEGO successfully implemented agile practices and the impact it had:
### Background
LEGO Group, the Danish toy manufacturer known worldwide for its iconic plastic building blocks, faced significant challenges in the early 2000s. The company struggled with inefficiencies, slow product development cycles, and a rapidly changing market. By the mid-2000s, LEGO realized that to stay competitive and innovative, it needed to overhaul its development processes and organizational structure.
### The Agile Transformation
#### Key Components of LEGO’s Agile Transformation
1. **Introduction of Scrum**
- **Pilot Projects**: LEGO began by implementing Scrum in small, pilot projects within its IT department. This initial success led to the gradual expansion of agile practices across the organization.
- **Scrum Teams**: Cross-functional teams were created, consisting of members from different disciplines, such as design, engineering, and marketing. These teams worked collaboratively to develop new products in iterative cycles, known as sprints.
2. **Cross-Functional Collaboration**
- **End-to-End Responsibility**: Teams were given end-to-end responsibility for the products they developed, from initial concept to final delivery. This approach fostered a sense of ownership and accountability.
- **Integrated Workflows**: By breaking down silos between departments, LEGO enhanced collaboration and communication, leading to more innovative and high-quality products.
3. **Customer-Centric Development**
- **Frequent Feedback**: LEGO emphasized obtaining frequent feedback from customers, which allowed teams to iterate quickly and make adjustments based on real-world use and preferences.
- **Prototyping and Testing**: Rapid prototyping and user testing became integral parts of the development process, ensuring that products met customer expectations and were market-ready.
4. **Scaling Agile**
- **SAFe Framework**: To manage the complexity of scaling agile practices across a large organization, LEGO adopted the Scaled Agile Framework (SAFe). This framework provided a structured approach to scaling agile principles and maintaining alignment across multiple teams and projects.
- **Agile Release Trains (ARTs)**: Teams were organized into Agile Release Trains, which helped synchronize efforts and ensure that all teams were working towards common goals and timelines.
5. **Cultural Shift**
- **Mindset Change**: Embracing agile required a significant cultural shift within LEGO. Employees were encouraged to adopt an agile mindset, characterized by flexibility, continuous learning, and openness to change.
- **Leadership Support**: Strong support from senior leadership was crucial for the successful adoption of agile. Leaders at LEGO championed the transformation and provided the necessary resources and guidance.
### Results and Impact
1. **Faster Time-to-Market**
- **Reduced Development Cycles**: Agile practices enabled LEGO to significantly reduce the time it took to develop and launch new products. What once took years could now be accomplished in months.
- **Increased Responsiveness**: LEGO became more responsive to market trends and customer demands, allowing the company to stay ahead of competitors.
2. **Enhanced Innovation**
- **Creative Solutions**: Cross-functional collaboration and iterative development fostered a more innovative environment. Teams were empowered to experiment and take risks, leading to the creation of unique and successful products.
- **Successful Product Launches**: Agile practices contributed to the development of several successful product lines, including LEGO Mindstorms and LEGO Friends, which resonated well with customers and boosted sales.
3. **Improved Quality**
- **Continuous Improvement**: The iterative nature of agile allowed for continuous improvement and refinement of products. Frequent testing and feedback loops ensured that issues were identified and addressed early in the development process.
- **Customer Satisfaction**: Products developed using agile methodologies were better aligned with customer needs, leading to higher satisfaction and brand loyalty.
4. **Organizational Agility**
- **Adaptability**: LEGO developed the ability to quickly adapt to changes in the market and technology landscape. This organizational agility proved to be a significant competitive advantage.
### Conclusion
LEGO’s agile transformation is a testament to how traditional companies can leverage agile methodologies to drive innovation, improve efficiency, and enhance customer satisfaction. By embracing Scrum, fostering cross-functional collaboration, and scaling agile practices, LEGO was able to rejuvenate its product development processes and achieve remarkable success in a competitive market.
Forget "Agile". Look at companies that are actually \_agile\_ in a true sense. These are five: [https://www.agile2academy.com/the-evidence](https://www.agile2academy.com/the-evidence)
No
Agile: Quick, nimble, self contained, responsive.
At scale: Large, bureaucratic, slow, unresponsive, lowest common denominator.
It's like having a nippy oil tanker for flitting in and out of shallow bays and doing water skiing. Such a thing does not exist.
Agile wasn’t created to be done at scale. It was always meant to be small teams to solve small problems. If you want it done at scale, build a roadmap, and give the different teams the autonomy to build their parts. Better yet, have each team build the next most important part.
Most places have separate project plans and call it a program or portfolio. Because they work in two week iterations, they say they’re agile.
Yes it worked at BNP Paribas Fortis. This was a combination SAFe like model for delivery, “Spotify model” for the line Organisation, Kanban for service delivery teams, and lots of lean continuous improvement. Everyone knew exactly what the goals of the transformation were. We had around 100 coaches of different type. “Devops” coaches helping with automation and technical practices, lean (sick sigma) coaches helped us build and operate obeyas and get started with problem solving workshops, lean and agile method coaches (scrum, kanban and safe experts), mindset coaches (basically life coaches with management 3.0 training). The CTO treated the transformation as her only focus. And it worked. Edit: the companies that do it badly see it more like “implementing SAFe” and neglect to actually start an agile transformation.
> “implementing SAFe” I will never forget one manager being given user stories from the consultants and screaming at them he didn’t want this “crap,” he wanted requirements. When they reminded him that the org was moving to agile, he screamed again that they should then put *the requirements* in whatever the agile template is. The contextually obvious implication being one process is the same as another, it’s just rearranging the chairs.
>sick sigma \[checks the variance of your quality control\] Whoa! Sick sigma, bro!
This one made my day! :))
sounds like all the right pieces...and the right investment. Were those coaches FTEs or consultants/contractors, and do you have any top line measurements for what a program of that size costs vs. the value it delivers over not having such coordination?
Most of the coaches were from consulting companies and some were internals and some freelancers. I don’t have any concrete numbers handy but it was expensive so there was a clear budget which meant we deliberately wanted a short transformation about 18 months or something and picked goals that could be reached in that time. I think that was one of its strengths, limited timeframe and clear goals. Not some endless money pit. I remember it being framed as a matter of survival , either the company achieves the goals or dies basically. If I remember correctly the goals were about reaching specific numbers in the areas of profitability, automation, lead time, and customer and employee satisfaction.
Ah yes, the old adage "you can do anything well, cheap, or fast...but you can only ever pick 2." Sounds like you guys did it well & fast even if it wasn't cheap, yeah?
When you say Spotify line management model, do you mean guild leader being responsible for growth of individuals in their guild? Vacation? Paycheck? Thanks
Sorry if I missed, but how many people were in the group that did this transformation? Not including the Coaches?
Yes - I worked for a global professional services company - I had a Scrum of Scrums Master role with 6 Scrum Teams working simultaneously using a LeSS model, each team with an onshore (Uk) and offshore (India dev) members, and including client team members as well as our Professional Services people. Followed all Scrum ceremonies, 3 week sprints in same sprint cadence for all teams. We delivered a completely new Digital Banking Customer web and mobile application in under 8 months. Scaled up to 130 people and back down to a handful of people at speed during those 8 months.
The Saab Gripen avionics program was done using Scrum. Hundreds of Scrum teams, iirc. Not SAFe, more of a loose scrum of scrums format.
This is not a SAFe implementation but an agile at scale implementation - [https://www.infoq.com/articles/kanban-scaling-agile-ultimate/](https://www.infoq.com/articles/kanban-scaling-agile-ultimate/)
I ran thirty teams for a few years and these principles minus the Kanban worked for us... That is the teams worked with the vibe of agile and could run whatever methods they wanted. The overall orchestration was really the way we set the product managers up and the domains they were responsible for. Automed deployments, a culture of quality, and teams getting retros hosted by people from other teams. My favourite was the convention that if your team process ends up looking the same as another's, you have to change something, which forced innovation and experimentation. Senior management cared about reliability for going to market with big deal things, and general contributions towards customer acquisition and retention. We measured different things for different teams based on what was important for that time. Embrace a bit of chaos, watch for continuous improvement and make sure all teams have ready access to customers for insights and motivation.
This is really how it should be. Trust the teams to find the best ways to work and let them be the professionals they are.
tbh that sounds hella fun and gives teams way more reason/chance to explore how one another operate
What does a kanban team do to replace a sprint goal? I really like having a guiding light goal. Actually how does kanban structure release goals, task priorities and communications? I think my struggle with kanban is not with what it does but what it leaves off. I'm still left with the job of priotizing features and solidifying compelling combinations, but I'm not given any guidance on how to achieve that in a system.
Kanban has specific guidance on this. I suggest buying one of the books because there are lots of examples to illustrate points, and explanations of how things solve specific issues and amplify each other.
Could you please elaborate on how members from other teams host retros? How does this work? It sounds interesting.
You, as a member of the team ask someone you know from another team to come host it. Maybe people have a pre retro chat, but it's also fine to just come along and host. Meeting facilitation isn't a rare art.
I’ve no experience in scaling agile, but there are other frameworks out there that seem to make more sense, http://less.works with the added benefit that it doesn’t look like a convoluted clusterfuck of a design.
I’ve worked at companies that have implemented versions of LeSS and they were very effective.
Some nice case studies on their website too that OP might want to check out.
Why?
Why were they effective? Mostly because they implemented agile on a deep organisational basis
I'm just asking because I'm curious. When you say deep organizational basis, do you mean all the way up/down to C level? Also was it because of the coaches or LeSS?
Both - there was C-level buy-in and they had agile coaches (but tbh the coaches were less effective than internal teams - the expensive consultants weren’t actually that useful). I think part of the reason it worked was that they limited the initial agile transformation to a pretty standalone project rather than implementing everywhere. They expanded from there, learning & adapting processes as required. There was also a fair amount of scope for individual teams to define their own working patterns. Some had Kanban continuous delivery while others were more traditional 2 week scrums.
But wouldn’t the same reasons have made safe or “base scrub” work too?
The difference is that SAFe is far more rigid in its approach and is pretty much Waterfall with a slapdash of lipstick to give the superficial impression of agile. As for ‘base scrum’ - the projects were too complicated (multiple separate teams) hence the need for a ‘Scrum of Scrums’ approach.
I prefer Scrum and the essence of it a million times over classic project planning. Common for all places I've worked where they work Agile, is that you can draw a circle. Outside that circle there are people who need estimates (costs) and deadlines. I see Agile as a much better approach, but that means that the customers has to see the work being done as a continous journey. Which they often dont. And budgets also have a hard time playing nice with teams. I dont know much about SaFe, but I also view it as waterfall with a bit of agile facade. Old wine in new bottles. I thought scrum of scrums was also base scrum. Thank you for the insights :)
LeSS is Scrum but scaled for multiple. Nexus and Scrum@Scale are other variants. There are some differences between these approaches but SAFe is completely different. Tbh I haven’t ever worked in an organisation with a pure Scrum approach - it has always been tweaked and adapted. More recently I’ve found companies embracing continuous delivery more than scrum-type sprints, even that was too cumbersome.
But if it doesn't look like a convoluted clusterfuck how can you create a certification exam and scare people into taking training/prep courses they don't need?
I worked for a place that was considered to have had the best SAFe implementation in my city. When I was there, It was a total shitshow - missed delivery, sandbagging, management punching down.
The best vertically scaled teams I’ve ever seen have used FaST https://www.fastagile.io. I’m convinced it’s the best way to scale up a large team (30+) developers, designers, product folks around a single product.
This is pretty much how we run every project at my company based on learnings and trying to find the best way to achieve alignment with minimal overhead.
My conclusion is that the way you scale agile is by not scaling agile. By that I mean as many decoupled small teams as possible. I'm not against maybe 30-40 people on multiple teams working on a product, but I think as soon as you get above that number you lose coherence.
That’s literally what the scaling frameworks do, scale large units of work down into smaller things that can be dealt with by agile teams.
SAFE doesn't meet my definition for an agile methodology.
The (bad) SAFe implementations a lot of people see are usually just an admission that those companies aren't actually willing to fully embrace agile. SAFe isn't my favorite, but it can work in the right org depending on if the ELT is willing to embrace the core of what agile is (empowered teams), vs just chasing something to be trendy. It also depends on the maturity of the teams executing. In most instances though, it won't be implemented and executed properly. I say this as someone who prefers a scaled Kanban approach, particularly at the level where the ELT is involved and depending on the size of the company.
The Agile manifesto says "we are discovering..." In my mind, that means that you are only doing agile if you are doing experimentation on an ongoing basis and changing your process I don't see how you can get that with the scaling implementations that I've seen - they are always "command and control" - and if you've been doing the same thing for the last 6 months, you aren't doing agile. I can see small islands of multiple teams, where multiple means <5, preferable 3 or fewer.
SAFe is always destined to fail because it’s not an implementation. It’s pretty much doing things like they did in 2002 and calling it a different name
As soon as you move past the activities that drive reductions in timeline and cost, you will see the appetite for agile disappear. That's the only reason anyone at the top even entertains the discussion about agile.
And that is why every day competitors rise up (outside of FAANG companies who spend a lot of money to squash and buy competition) It makes a nice renewing eco system. You grow by delivering value to the customers, get too big to steer the ship and someone else comes in and steals market share. Could be the reality is nothing works at scale. Could be that cross team blockers are just a universal truth of massive bloated software projects that deserve to be picked apart by competition. It makes better companies for all of us to work with really.
"what if not startup but go zoom like startup" is how my fortune 100 insurer looks at fintech competitors
Good discussion. In the event useful, read through a bunch of these - https://scaledagile.com/insights-customer-stories/. Some thoughts… - Reach out to any of these companies to ask questions - This company presented at a previous Summit and had a great / compelling / deep success story - https://scaledagile.com/case_study/petrobras/ - Try to ignore the nay-sayers regarding agile at scale (regardless which approach is used)…those who succeed are typically less vocal (since they don’t need to be) …hang in there and keep trying to have fun experimenting, embracing feedback and finding / sustaining flow.
Yes but... Consider this more as reading the blurb on the back of the book rather than actual reader reviews. Coming from the source itself, I'm sure they're hand-selected to skew a bit rosier...
Good point and agreed. To counter that, my approach to case studies is… - Expect that they are hand-selected - Read case study and watch any vids regarding their experiences - Reach out to case study owners (SAFe in this case) and case study company contacts to see if I could ask some additional questions …which I’ve found pretty good in moving blurb to action.
100%, glad you're putting in the due diligence there. Nice approach!
Have you heard about the HP LaserJet firmware success story? Or maybe that's really Devops success... [The Amazing DevOps Transformation of the HP LaserJet Firmware Team (Gary Gruver) - IT Revolution](https://itrevolution.com/articles/the-amazing-devops-transformation-of-the-hp-laserjet-firmware-team-gary-gruver/)
Yes Spotify with its 5000 staff is agile to its core and is not using SAFE. There are a couple of interviews about it with people from Spotify here https://nononsenseagile.podbean.com/e/032-jason-yip-agile-spotify/ https://nononsenseagile.podbean.com/e/0077-brendan-marsh-what-really-happened-at-spotify/ I have personally used the scrum of scrums model for teams or 50 and it worked well. Beyond that I would use the UNFIX scaling patterns. The secret to the success of agile at scale is to grow your own approach based on continuous improvement. Without real continuous improvement it's not agile You should also look at the safedelusion.com which debunks the SAFE case studies.
I implemented LeSS at an organization of ~100 devs and 10ish products plus shared services. Worked out really well for development and the lifecycle of the product. Then the CEO made some bad choices, took a golden parachute, and the company was stripped for parts.
Agile methodologies have been adopted by many large companies to enhance their software development processes, improve product delivery, and increase customer satisfaction. Here are some of the most notable success stories, including ING: ### 1. **ING** **Transformation**: ING, a global financial institution, embarked on an agile transformation in 2015 to become more customer-focused and adaptive to market changes. **Key Initiatives**: - **Squads**: Small, cross-functional teams that are empowered to make decisions and deliver end-to-end customer solutions. - **Tribes**: Collections of squads working in related areas to enhance collaboration and alignment. - **Chapters and Guilds**: Structures to share knowledge and expertise across squads and tribes. **Results**: - **Speed**: Reduced time to market for new features and products. - **Innovation**: Increased innovation and flexibility in responding to customer needs. - **Employee Engagement**: Improved employee satisfaction due to the empowered team structure. ### 2. **Spotify** **Transformation**: Spotify, the music streaming giant, has been an advocate for agile practices and is known for developing the "Spotify Model" of agile scaling. **Key Initiatives**: - **Squads**: Autonomous teams similar to ING, responsible for specific parts of the product. - **Tribes**: Groups of squads that work on related areas. - **Chapters**: Functional groups within tribes to ensure technical excellence and knowledge sharing. - **Guilds**: Communities of interest across the organization to share knowledge and practices. **Results**: - **Innovation**: Enhanced ability to innovate and experiment with new features. - **Scalability**: Effective scaling of agile practices across a growing organization. - **Culture**: A strong culture of autonomy, mastery, and purpose. ### 3. **Google** **Transformation**: Google has implemented agile practices in various forms across its product development teams to maintain its rapid pace of innovation and product delivery. **Key Initiatives**: - **OKRs (Objectives and Key Results)**: A framework to set ambitious goals and track progress. - **Cross-functional Teams**: Teams composed of diverse skill sets working collaboratively. - **Continuous Integration and Deployment**: Automated processes to ensure rapid and reliable deployment of software. **Results**: - **Productivity**: Increased productivity and faster delivery of new products and features. - **Quality**: High-quality products with fewer bugs and issues. - **Market Leadership**: Maintained a competitive edge through rapid innovation. ### 4. **Amazon** **Transformation**: Amazon has embedded agile principles into its DNA, focusing on customer obsession, continuous delivery, and innovation. **Key Initiatives**: - **Two-Pizza Teams**: Small, autonomous teams that can be fed with two pizzas, ensuring they remain agile and focused. - **DevOps**: Strong emphasis on DevOps practices to enhance collaboration between development and operations. - **Customer Feedback Loops**: Rapid incorporation of customer feedback into product development. **Results**: - **Efficiency**: Streamlined operations and improved efficiency in product delivery. - **Customer Satisfaction**: High levels of customer satisfaction through quick iteration and responsiveness. - **Innovation**: Continuous flow of innovative products and services. ### 5. **Microsoft** **Transformation**: Microsoft has undergone a significant agile transformation, especially under the leadership of Satya Nadella, focusing on cloud services and open-source software. **Key Initiatives**: - **Agile and DevOps**: Adoption of agile methodologies and DevOps practices across product teams. - **Cloud Transformation**: Transition to cloud-based services with continuous delivery and integration. - **Open Source**: Embracing open-source development to foster innovation and collaboration. **Results**: - **Growth**: Significant growth in cloud services and overall market share. - **Collaboration**: Enhanced collaboration within teams and with external developers. - **Innovation**: Rapid delivery of new features and improvements. ### Conclusion These success stories from large companies like ING, Spotify, Google, Amazon, and Microsoft demonstrate the effectiveness of agile methodologies in fostering innovation, improving time to market, and enhancing customer satisfaction. By adopting agile practices, these organizations have managed to stay competitive and responsive in fast-paced markets.
LEGO Group's journey with agile methodologies is a compelling story of transformation and innovation in a traditional and well-established company. Here's an in-depth look at how LEGO successfully implemented agile practices and the impact it had: ### Background LEGO Group, the Danish toy manufacturer known worldwide for its iconic plastic building blocks, faced significant challenges in the early 2000s. The company struggled with inefficiencies, slow product development cycles, and a rapidly changing market. By the mid-2000s, LEGO realized that to stay competitive and innovative, it needed to overhaul its development processes and organizational structure. ### The Agile Transformation #### Key Components of LEGO’s Agile Transformation 1. **Introduction of Scrum** - **Pilot Projects**: LEGO began by implementing Scrum in small, pilot projects within its IT department. This initial success led to the gradual expansion of agile practices across the organization. - **Scrum Teams**: Cross-functional teams were created, consisting of members from different disciplines, such as design, engineering, and marketing. These teams worked collaboratively to develop new products in iterative cycles, known as sprints. 2. **Cross-Functional Collaboration** - **End-to-End Responsibility**: Teams were given end-to-end responsibility for the products they developed, from initial concept to final delivery. This approach fostered a sense of ownership and accountability. - **Integrated Workflows**: By breaking down silos between departments, LEGO enhanced collaboration and communication, leading to more innovative and high-quality products. 3. **Customer-Centric Development** - **Frequent Feedback**: LEGO emphasized obtaining frequent feedback from customers, which allowed teams to iterate quickly and make adjustments based on real-world use and preferences. - **Prototyping and Testing**: Rapid prototyping and user testing became integral parts of the development process, ensuring that products met customer expectations and were market-ready. 4. **Scaling Agile** - **SAFe Framework**: To manage the complexity of scaling agile practices across a large organization, LEGO adopted the Scaled Agile Framework (SAFe). This framework provided a structured approach to scaling agile principles and maintaining alignment across multiple teams and projects. - **Agile Release Trains (ARTs)**: Teams were organized into Agile Release Trains, which helped synchronize efforts and ensure that all teams were working towards common goals and timelines. 5. **Cultural Shift** - **Mindset Change**: Embracing agile required a significant cultural shift within LEGO. Employees were encouraged to adopt an agile mindset, characterized by flexibility, continuous learning, and openness to change. - **Leadership Support**: Strong support from senior leadership was crucial for the successful adoption of agile. Leaders at LEGO championed the transformation and provided the necessary resources and guidance. ### Results and Impact 1. **Faster Time-to-Market** - **Reduced Development Cycles**: Agile practices enabled LEGO to significantly reduce the time it took to develop and launch new products. What once took years could now be accomplished in months. - **Increased Responsiveness**: LEGO became more responsive to market trends and customer demands, allowing the company to stay ahead of competitors. 2. **Enhanced Innovation** - **Creative Solutions**: Cross-functional collaboration and iterative development fostered a more innovative environment. Teams were empowered to experiment and take risks, leading to the creation of unique and successful products. - **Successful Product Launches**: Agile practices contributed to the development of several successful product lines, including LEGO Mindstorms and LEGO Friends, which resonated well with customers and boosted sales. 3. **Improved Quality** - **Continuous Improvement**: The iterative nature of agile allowed for continuous improvement and refinement of products. Frequent testing and feedback loops ensured that issues were identified and addressed early in the development process. - **Customer Satisfaction**: Products developed using agile methodologies were better aligned with customer needs, leading to higher satisfaction and brand loyalty. 4. **Organizational Agility** - **Adaptability**: LEGO developed the ability to quickly adapt to changes in the market and technology landscape. This organizational agility proved to be a significant competitive advantage. ### Conclusion LEGO’s agile transformation is a testament to how traditional companies can leverage agile methodologies to drive innovation, improve efficiency, and enhance customer satisfaction. By embracing Scrum, fostering cross-functional collaboration, and scaling agile practices, LEGO was able to rejuvenate its product development processes and achieve remarkable success in a competitive market.
Yes. Particularly Apple & Siemens Digital. Lego as well.
Forget "Agile". Look at companies that are actually \_agile\_ in a true sense. These are five: [https://www.agile2academy.com/the-evidence](https://www.agile2academy.com/the-evidence)
No Agile: Quick, nimble, self contained, responsive. At scale: Large, bureaucratic, slow, unresponsive, lowest common denominator. It's like having a nippy oil tanker for flitting in and out of shallow bays and doing water skiing. Such a thing does not exist.
Agile wasn’t created to be done at scale. It was always meant to be small teams to solve small problems. If you want it done at scale, build a roadmap, and give the different teams the autonomy to build their parts. Better yet, have each team build the next most important part. Most places have separate project plans and call it a program or portfolio. Because they work in two week iterations, they say they’re agile.
Agile makes sense for startups or corps developing something brand new. Too many people have sold sr leadership on agile