Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Scrum, Strategy
Has your organization implemented a scaled agile or scaled scrum approach?
Network:2146



Has your organization implemented a scaled agile or scaled scrum approach? Please share your thoughts and/or experiences.
Sort By:
Network:1794



I am in charge to implement SAFe and DevOps in my organization. Previously we work with Disciline Agile but the organization decide about SAFe. If you ask me, SAFe, DevOps, Scrum@Scale are the most usefulness things people can find. While we are scaling? I was the leader of the transformation thru Agile. But time after, the organization decide to use a method and took the method some people in software development used: Scrum (by the way, is a framework not a method). Because of that now the organization decide to use Scrum for everything we do. But the genesis of the initiative was using Agile as it was born: at enteprise level from strategy formulation to strategy implementation, from top to bottom and bottom to up.
Network:2146



Thanks, Sergio. To be sure I understand you correctly, you do not find it necessary to scale at all, simply based on the fact that with Scrum as a framework, its 'scalability' is inherent.
...
1 reply by Sergio Luis Conte
Mar 17, 2019 8:19 AM
Sergio Luis Conte
...
You are welcome. Just to add a comment about my personal experience with the only aim that people understand my position is not academic only let me say I was part of the genesis of Agile (software and non software) and then I have to put it in practice from 1995 up to date. Agile (like Lean for example - while are not the same) is something to use at enterprise wide and the decision to use it is because the strategy definition. Then, when you use Agile, is nothing to scale. My experience is that when you scale is because a group into the company used some agile based method mainly to create software products and today, because all the information there, they decide to use it expanding it to other places into the company including it for non software products. Unfortunatelly this is a movement pushed by Scrum framework creators. You can take a look to LeSS too. The first one was Nexus (Schwaber), then Scrum@Scale (Sutherland) and when you read it are really "wasted". You do not need it, including you do not need SAFe (when you experienced SAFe you will find is anti-agile). On the other side, just in case you use things like XP or DSDM and you use things like DAD as a complement you will find that the evolution from bottom to up is more natural. So, is nothing to scale if you use Agile in the right way (perhaps right is not the word I will use in spanish) or "natural way". But just in case for any reason that is not the case forget about to use a framework to scale and after understanding what Agile realy is you will find the way to expand it to the whole organization. As you see in my previous comment I was not successful to demonstrate it in my actual organization.
Network:1794



Mar 17, 2019 8:08 AM
Replying to Andrew Craig
...
Thanks, Sergio. To be sure I understand you correctly, you do not find it necessary to scale at all, simply based on the fact that with Scrum as a framework, its 'scalability' is inherent.
You are welcome. Just to add a comment about my personal experience with the only aim that people understand my position is not academic only let me say I was part of the genesis of Agile (software and non software) and then I have to put it in practice from 1995 up to date. Agile (like Lean for example - while are not the same) is something to use at enterprise wide and the decision to use it is because the strategy definition. Then, when you use Agile, is nothing to scale. My experience is that when you scale is because a group into the company used some agile based method mainly to create software products and today, because all the information there, they decide to use it expanding it to other places into the company including it for non software products. Unfortunatelly this is a movement pushed by Scrum framework creators. You can take a look to LeSS too. The first one was Nexus (Schwaber), then Scrum@Scale (Sutherland) and when you read it are really "wasted". You do not need it, including you do not need SAFe (when you experienced SAFe you will find is anti-agile). On the other side, just in case you use things like XP or DSDM and you use things like DAD as a complement you will find that the evolution from bottom to up is more natural. So, is nothing to scale if you use Agile in the right way (perhaps right is not the word I will use in spanish) or "natural way". But just in case for any reason that is not the case forget about to use a framework to scale and after understanding what Agile realy is you will find the way to expand it to the whole organization. As you see in my previous comment I was not successful to demonstrate it in my actual organization.
Network:1391



Andrew -

my current client (a large Canadian bank) first tried to transform delivery practices using the DAD process decision making framework but didn't really address the organization structural and support group (e.g. procurement, finance) changes needed to succeed with the transformation. They then went with a mashup of SAFe, LeSS, Nexus and DAD practices leveraging Scrum nomenclature and key ceremonies but have invested in the enterprise changes. It's a year in and there have been some optimistic signs but it is still a long way to go. I just completed a "census" of titled agile roles and we have ~150 Scrum Masters and Coaches (FT and contract) across the organization...

My constant advice on scaling agile is not to attempt it until there have been some successful, repeatable attempts of "small scale" agile.

Kiron
...
1 reply by Andrew Craig
Mar 17, 2019 6:19 PM
Andrew Craig
...
Thank you, Kiron. Agreed. Those organizations that decide to move toward these approaches can come in a bit strong and overly optimistic, setting themselves up for more challenges than originally bargained for.

There is a consideration of scaling down before scaling up. That seems to align with you that to ensure success in smaller teams then take it forward.
Network:213



Andrew
Since agile has become an industry buzzword, throughout many layers of our organizations, people have been putting forth efforts as to how it can be applied. The core of our business is large scale manufacturing which has some inherent limitations as some decisions are cost prohibitive to change once a certain milestone is reached.

I get to lead or participate in a variety of projects including hardware, software, processes and tools, and anything else requiring a problem solver with a toolbox of approaches. As such I'm constantly asking myself which method is best suited for the application.

One of the biggest challenges I face in applying agile principles in large functional based organization is resource management. While it could be vastly more efficient to sequester people for a period of time to solve a specific problem, we traditionally segment our days into 30-90 time periods to work between projects. One of my biggest challenges as a PM is scheduling time to get the right people together.

With projects that get high level stakeholder support, it's easier to get peoples' time, however there is the constant distraction that there are many activities ongoing in the background that typically fill the 30-90 minute time slots, some of which are critical to the core business. The methodology typically involves which method would be best suited for the problem type, combined with which method is practicable in the current business environment.

Keith
...
1 reply by Andrew Craig
Mar 17, 2019 6:27 PM
Andrew Craig
...
Thanks, Keith. Good points. Another challenge faced when influencing these changes bottom up. When organizations buy in at the top-level, it is easier to have a tone set that will better enable resourcing teams, and keeping more of a long-term outlook and push for continuity.
Network:2146



Mar 17, 2019 10:24 AM
Replying to Kiron Bondale
...
Andrew -

my current client (a large Canadian bank) first tried to transform delivery practices using the DAD process decision making framework but didn't really address the organization structural and support group (e.g. procurement, finance) changes needed to succeed with the transformation. They then went with a mashup of SAFe, LeSS, Nexus and DAD practices leveraging Scrum nomenclature and key ceremonies but have invested in the enterprise changes. It's a year in and there have been some optimistic signs but it is still a long way to go. I just completed a "census" of titled agile roles and we have ~150 Scrum Masters and Coaches (FT and contract) across the organization...

My constant advice on scaling agile is not to attempt it until there have been some successful, repeatable attempts of "small scale" agile.

Kiron
Thank you, Kiron. Agreed. Those organizations that decide to move toward these approaches can come in a bit strong and overly optimistic, setting themselves up for more challenges than originally bargained for.

There is a consideration of scaling down before scaling up. That seems to align with you that to ensure success in smaller teams then take it forward.
Network:2146



Mar 17, 2019 2:04 PM
Replying to Keith Novak
...
Andrew
Since agile has become an industry buzzword, throughout many layers of our organizations, people have been putting forth efforts as to how it can be applied. The core of our business is large scale manufacturing which has some inherent limitations as some decisions are cost prohibitive to change once a certain milestone is reached.

I get to lead or participate in a variety of projects including hardware, software, processes and tools, and anything else requiring a problem solver with a toolbox of approaches. As such I'm constantly asking myself which method is best suited for the application.

One of the biggest challenges I face in applying agile principles in large functional based organization is resource management. While it could be vastly more efficient to sequester people for a period of time to solve a specific problem, we traditionally segment our days into 30-90 time periods to work between projects. One of my biggest challenges as a PM is scheduling time to get the right people together.

With projects that get high level stakeholder support, it's easier to get peoples' time, however there is the constant distraction that there are many activities ongoing in the background that typically fill the 30-90 minute time slots, some of which are critical to the core business. The methodology typically involves which method would be best suited for the problem type, combined with which method is practicable in the current business environment.

Keith
Thanks, Keith. Good points. Another challenge faced when influencing these changes bottom up. When organizations buy in at the top-level, it is easier to have a tone set that will better enable resourcing teams, and keeping more of a long-term outlook and push for continuity.
...
1 reply by Keith Novak
Mar 17, 2019 11:20 PM
Keith Novak
...
I think you touched on a very key point. Organizations saying they buy in at the top level is very different from embracing that at a working level. Disruption is all well and good until it impinges our day to day cadence.
Network:213



Mar 17, 2019 6:27 PM
Replying to Andrew Craig
...
Thanks, Keith. Good points. Another challenge faced when influencing these changes bottom up. When organizations buy in at the top-level, it is easier to have a tone set that will better enable resourcing teams, and keeping more of a long-term outlook and push for continuity.
I think you touched on a very key point. Organizations saying they buy in at the top level is very different from embracing that at a working level. Disruption is all well and good until it impinges our day to day cadence.

Please login or join to reply

Content ID:
ADVERTISEMENTS

I did this thing on the Ottoman Empire. Like, what was this? A whole empire based on putting your feet up?

- Jerry Seinfeld

ADVERTISEMENT

Sponsors