Help, My Organisation is Doing SAFe!

[Andreas Schliep]

You have given everything. You have shown in countless meetings, conversations and intranet articles why it makes sense for an organisation to become agile, what being agile means, why defined process protocols don't make sense in a complex context. You have assisted agile teams to formulate a challenging Definition of Done, and helped alleged Product Owners, to contribute as requirements specialists on a team. You insisted that the management take Lean thinking to their heart, you have put a lot of effort into our change, transition or transformation team. Finally everybody agreed that organisations need to become agile nowadays. There even was a big talk by your management with images of oil tankers and speed boats.

And now that: External consultants convinced your management that SAFe - Scaled Agile Framework - is exactly the right solution for your company. You do not just want isolated Scrum or Kanban teams - agile needs to me the measure for the entire development. Instead of starting on a blank page, you rather should take an approach that already contains instructions for any kind of challenge. Aligned planning? Release trains! Reasonable architecture? Architect roles! Many projects? Portfolio Kanban! Isnt't it correct that SAFe is built upon Lean and Agile? Everything is there: Sprints, user stories, product owners, meetings with sticky notes...

Isn't it reactionary and counter-productive to listen to this small voice inside your head, that tells you that you do not become more sportive by building a fitness center? That SAFe with all its contents and fancy posters just appears like an oil tanker with lots of speed boat pictures on the hulk? SAFe experts, often classical project management consultants who managed to stay awake through a three day powerpoint marathon, ensure you that this is not the truth about SAFe. You do not have to use everything from SAFe. The most important things are alignment and compliance to the shared approach, the focus on delivery capability.

It everything was so easy. SAFe lends heavily towards planning. If we just knew what to produce, and planned it extensively, the rest would just fall into place. SAFe is so good, that it does not requrire empirical process control - although this is the fundamental element of many agile approaches like Scrum. If necessary, you can update SAFe to the latest version. This does not only sound like a classical approach like RUP or SAP. It is the same business model. Promise an organisation a clear, simple solution for their complex problems. Place loads of consultants. Make the organisation dependable on your approach. If it does not work in the first place, bring in more consultant. Rinse and repeat.

And now you're deep into trouble. You consider looking for a new job. This is not the flavor of agility you have been dreaming of. No fun. As agile coach you surely find another company where you can place your talents and skills. But not everything is lost! There are three ways that might lead to more understanding and readiness for being agile. I call these ways resistance, conformity and responsibility.

Resistance

Form a resistance group. Whenever management introduces a new role, be ready to question it. Tolerate what makes sense to you, and fight what does not make sense. If you can't fight it, find workarounds. You want overall retrospectives? An improvement backlog? Communities of practice? Just do it! Agility arises inspite of the introduced processes. Breaking the rules becomes the valid rule. Just like in Waterfall before, you as agile coach ensure that your teams can deliver, that they are in close contact to the business experts, that learning is put into the foreground. You just need to be aware of one thing: If your counter measures actually work, people will claim that SAFe is working. If your counter measures fail, it is your fault. Be prepared to look for a new job.

Conformity

Just as capitalism destroys itself, SAFe will eventually fail and collapse. All you have to do is to ensure that SAFe is played by the book, according to the blue print. Oh, there is a role missing? Not all developers joining the planning meeting? Enact as process police that you reach a 100% alignment to the SAFe framework. Avoid all inoffical communication relationships. Only do as prescribed. This will eventually expose the dysfunctionality of SAFe. And cause your projects to hit the wall. Or you could actually cause SAFe to work as intended. If not, your management might not blame SAFe but the people. Everybody prepare to look for new jobs, then.

Responsibilty

"Come on", you might say, "I am not responsible for introducing SAFe, that was our management!" Are you sure you're not talking about "blame" here? Opposed to popular thinking, the way of responsibility is not about finding the responsible person. Also not about reproach for yourself - "I could not stop them from chosing SAFe". And especially not just to put up with the conditions and enact work-to-rule. Taking responsibility means that your continuously reflect about your own position, intention and possible contribution. If you are responsible, you are able to find the best reaction or response to a given situation. Taking responsibility opens up opportunities you might not have thought about before. For yourself, your team and your environment. Use your influence, your voice, your experience and the respect for your people around you. Here are some examples:

• Facilitation: Ensure that your meetings are not dominated by electronic tools. Bring in a high level of collaboration. Collaboration fosters agility - better relationships improve actionability.
• Simplicity: De-scaling is more difficult than scaling. But you can help to simplify your organisation. For instance by reducing roles outside of teams. That works by conviction, practice and results.
• Transparency: Remember the Scrum foundations. If one agile rule gets violated by the outside, make the effects visible. Radical transparency is the natural enemy of dysfunctional decision making.

Take responsibility. At the end of the day, what counts is how much your organisatzion has internalizied the principles of focus on people, real value creation and continuous improvement. Do not get sucked in pointless trench fights, but do not give up your passion for real agile work and life. SAFe will eventually pass.

Andreas Schliep
Scrum Alliance Certified Scrum Trainer
Scrum Alliance Certified Enterprise Coach

DasScrumTeam AG
Bahnhofstrasse 21
6304 Zug
Schweiz
Executive Partners: Emanuel Obrist, Peter Beck, Andreas Schliep, Kai Simons

phone:  +41 435 080 987
mobile: +49 151 223 666 26

@andreasschliep

andreas...@dasscrumteam.com
www.dasscrumteam.com

[Alan Dayley]

Andreas,

I don't think of the email list as a way to publish blog posts. I think this email list is intended as a conversational channel, not for broadcasting.

Alan

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

[Andreas Schliep]

Am Sonntag, 20. November 2016 21:28:42 UTC+1 schrieb Alan Dayley:

Andreas,

I don't think of the email list as a way to publish blog posts. I think this email list is intended as a conversational channel, not for broadcasting.

Alan

Thank you for reading the long post anyways. I am indeed curious about the conversations that can follow.

Best

Andreas 

[Michael de la Maza]

--

You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@googlegroups.com.

[Alan Dayley]

I didn't read it all. It quickly felt like a blog post, not a conversation request, so I stopped reading.

Alan

--

You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@googlegroups.com.

[Kevin Shine]

Hi

I am doing SAFe and it is working and helping teams with their scrum work. If you just do scrum eventually you find you need management support....thats all safe is saying/trying. You cant just optimize the team, you need to optimize the whole.  

If you try and waterfall with a SAFe framework you will fail just as hard as if you try and waterfall with plain scrum. 

andreas.schliep@dasscrumteam.com
www.dasscrumteam.com

[Ron Jeffries]

Kevin,

On Nov 22, 2016, at 4:11 AM, Kevin Shine <kevs...@gmail.com> wrote:

If you just do scrum eventually you find you need management support....thats all safe is saying/trying.

That is quite far from all that SAFe is saying. Quite far.

You cant just optimize the team, you need to optimize the whole.  

Agreed. SAFe is a way of trying to optimize. It’s not a very Agile way, in my opinion, but that’s not to say it might not give some decent results sometimes.

Ron Jeffries

ronjeffries.com

If it is more than you need, it is waste. -- Andy Seidl

[Kevin Shine]

Hi Ron

Agree, SAFe says a lot of things, but I think at its core it is trying to connect the initiation of "projects" to the execution in an agile kanban way. My view is that SAFe is asking those top execs to rather take a financial view of things and break things down into iterative delivery parts (features and so on) based on value. Work is ordered on a KanBan wall (and personally I will take that over a gantt any day)  rather than fighting about dates. SAFe encourages teams and collaboration and communication (as does scrum). We are now talking about and measuring value rather than dates and thats a  hella step closer to where we want these folks minds to be. :-) 

Sooooo....we are moving from a fascination and obsession around dates to business value. HIGH FIVE!!! :-)

That should help scrum teams a whole lot. We are now talking the same language again. Value. For all its faults, if you seem to find some, at least the core is the same religion. 

[Pierre Neis | We&Co]

why not calling it AgileITIL?

PierreNEIS
Senior Lean Agile Coach | Associate
M: +352 / 661 727 867
UK: +44 / 203 239 52 60
wecompany.me | You can book me

Actually Scrum Coach for S4HANA/Hybris Billing @ SAP SE

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.

[Ron Jeffries]

Kevin,

On Nov 22, 2016, at 9:44 AM, Kevin Shine <kevs...@gmail.com> wrote:

Agree, SAFe says a lot of things, but I think at its core it is trying to connect the initiation of "projects" to the execution in an agile kanban way. My view is that SAFe is asking those top execs to rather take a financial view of things and break things down into iterative delivery parts (features and so on) based on value. Work is ordered on a KanBan wall (and personally I will take that over a gantt any day)  rather than fighting about dates. SAFe encourages teams and collaboration and communication (as does scrum). We are now talking about and measuring value rather than dates and thats a  hella step closer to where we want these folks minds to be. :-) 

I’m not very troubled by the portfolio management level of SAFe, except insofar as it may still encourage doing too much, and may encourage less effective team structures. That this happens may be evidenced by the ludicrous red-thread game.

Sooooo....we are moving from a fascination and obsession around dates to business value. HIGH FIVE!!! :-)

I don’t see much in SAFe that pushes back against dates but if it does that in favor of value, that might be good. We note that dates are not always unimportant.

That should help scrum teams a whole lot. We are now talking the same language again. Value. For all its faults, if you seem to find some, at least the core is the same religion. 

The core of Agile is a heck of a lot more than “focus on value”. I’d suggest a look at the values and principles of the Manifesto. It is those values and principles that SAFe does not encourage as much as it might, and that’s why I think it might be useful but isn’t particularly Agile.

Ron Jeffries
www.XProgramming.com
Sometimes you just have to stop holding on with both hands, both feet, and your tail, to get someplace better. 

Of course you might plummet to the earth and die, but probably not: you were made for this.

[Kevin Shine]

Ah yes. The ludicrous red-thread game indeed. It does however show you that you may have way too many connections to actually manage work well and that the teams and structures may need some work. The more red the more things are not going so well and we dont have good team structures. Its a nice way to actually show people not doing the work, the communication and coordination problems. The more visible we can make issues the easier they are to solve.

I agree the manifesto includes many things and SAFe leans heavily on these. See what I just did there. lol. 

Thanks for the interesting chat. :-)

[Ron Jeffries]

Kevin,

> On Nov 22, 2016, at 4:46 PM, Kevin Shine <kevs...@gmail.com> wrote:
>
> Thanks for the interesting chat. :-)

Yes. You won the conversation. Well done.

Good luck in the future.

R

[Kevin Shine]

Was I winning or whining? In reflection it becomes unclear to me. ;-)

[Alan Dayley]

We each, individually, have to decide what way we want to help people enjoy work and make great stuff.

If the leaders of an organization wants to go from current whatever to a scaled agile, they will likely not hire someone that argues for a different path. So, the Agile Coach Consultant Super Star is left in a quandary: Does she reject this request because she believes there is a better way? Or does she accept the request thinking SAFe (or scaled whatever) will be better than where they are now?

It is a mistake, I think, to say that SAFe is poison and terrible and disastrous in all cases it could be applied. It is also a mistake to say that consultants who help with SAFe are evil and are selling snake oil.

It is good to keep asking these questions and seeking better answers that lead to better questions.

Alan

[Kevin Shine]

Totally agree

On Wed, 23 Nov 2016 at 5:34 PM Alan Dayley <ada...@gmail.com> wrote:

We each, individually, have to decide what way we want to help people enjoy work and make great stuff.

If the leaders of an organization wants to go from current whatever to a scaled agile, they will likely not hire someone that argues for a different path. So, the Agile Coach Consultant Super Star is left in a quandary: Does she reject this request because she believes there is a better way? Or does she accept the request thinking SAFe (or scaled whatever) will be better than where they are now?

It is a mistake, I think, to say that SAFe is poison and terrible and disastrous in all cases it could be applied. It is also a mistake to say that consultants who help with SAFe are evil and are selling snake oil.

It is good to keep asking these questions and seeking better answers that lead to better questions.

Alan

On Wed, Nov 23, 2016 at 9:59 AM, Kevin Shine <kevs...@gmail.com> wrote:

Was I winning or whining? In reflection it becomes unclear to me. ;-)

On Tue, Nov 22, 2016 at 11:57 PM, Ron Jeffries <ronjeff...@gmail.com> wrote:

Kevin,

> On Nov 22, 2016, at 4:46 PM, Kevin Shine <kevs...@gmail.com> wrote:
>
> Thanks for the interesting chat. :-)

Yes. You won the conversation. Well done.

Good luck in the future.

R

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.

To post to this group, send email to scruma...@googlegroups.com.
Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.

To post to this group, send email to scruma...@googlegroups.com.
Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.

[miked]

SAFe helps the middle world of the organization move from the academic surity of time management to the relative insecurity of value and clarity. The feedback I get from the Scrum Team and Product Owners on the ground in SAFe efforts is feedback loops that are too long. The range of impact goes from minimal with legacy to impossible with mobile apps.
Most SAFe folks I know tell me SAFe works only when teams on the ground do Scrum well.

[Ron Jeffries]

Hi Alan,

On Nov 23, 2016, at 10:34 AM, Alan Dayley <ada...@gmail.com> wrote:

If the leaders of an organization wants to go from current whatever to a scaled agile, they will likely not hire someone that argues for a different path. So, the Agile Coach Consultant Super Star is left in a quandary: Does she reject this request because she believes there is a better way? Or does she accept the request thinking SAFe (or scaled whatever) will be better than where they are now?

I hesitate to make this comparison but it’s a good one. In a context of people joining the new administration, I read a very interesting article pointing out that the lesser of two evils is still an evil, and that entering into that arena, hoping to help from the inside, exposes one to a number of dangers.

Mind you, SAFe is not evil. However, even with Scrum, which is pretty darn good, we have Dark Scrum happening very frequently: lip service to Scrum, but used in an oppressive fashion. Now if you read the SAFe descriptions carefully, they say all the right things about focus on people, etc etc. And if you take the SAFe course from the same people I did, you see them doing the exact opposite. Our instructor shouted at the group, berated them, pushed them. Then she made some comment about how she was doing it because “acting” or some such excuse.

Any scaling approach is on a short fuse to doomed, because every Agile effort requires that people really adopt the Manifesto values and/or the Scrum values. A scaled agile effort is by its nature huge and the number of people who don’t have those values starts out huge, and they’ll only shift over when the get trained and then get good experience with the new way. SAFe rather explicitly allows for hierarchic management, with a bit of self organization down by the leaves. 

There are really very few examples of larger organizations that successfully went Agile. I think that LeSS, and Mike’s approach, have a prayer. I think that SAFe may not even have that much.

I’d like to be wrong … but I’m not.

It is a mistake, I think, to say that SAFe is poison and terrible and disastrous in all cases it could be applied. It is also a mistake to say that consultants who help with SAFe are evil and are selling snake oil.

As far as I know, no one has said either of those things. 

Ron Jeffries

ronjeffries.com

In times of stress, I like to turn to the wisdom of my Portuguese waitress,
who said: "Olá, meu nome é Marisol e eu serei sua garçonete."

[Ram Srinivasan]

Jeff Sutherland was talking about scaling at Give Thanks for Scrum yesterday. This is what he had to share (see image) comparing SAFe and doing Scrum well.

Some other quotes by Jeff - "If you remove all the waste from SAFe, you essentially end up with Scrum", "If you do scrum well, you should see that time to market is about 80% faster, defects should go down by 80% and cost also should go down by 80%" 

[Ram Srinivasan]

On Wed, Nov 23, 2016 at 4:59 PM, Ron Jeffries <ronje...@acm.org> wrote:

 

Any scaling approach is on a short fuse to doomed, because every Agile effort requires that people really adopt the Manifesto values and/or the Scrum values. A scaled agile effort is by its nature huge and the number of people who don’t have those values starts out huge, and they’ll only shift over when the get trained and then get good experience with the new way. SAFe rather explicitly allows for hierarchic management, with a bit of self organization down by the leaves. 

 

There are really very few examples of larger organizations that successfully went Agile. I think that LeSS, and Mike’s approach, have a prayer. I think that SAFe may not even have that much.

I’d like to be wrong … but I’m not.

The way SAFe is designed with hierarchy and multitude of roles makes it easier to achieve less communication saturation which IMHO leads to higher probability of failure.  To quote Neil Harrison  and James Coplein 

What is the impact of low communication saturation? A low saturation rate indicates that roles are not communication with one another. In many cases, this is appropriate;certain roles may be more or less independent. In fact, larger organizations probably have evolved towards role specialization as a way to handle their complexities. However, such a condition may increase the risk that critical information does not reach the tight person or that the information is not received in a timely manner.

Communication appears to be critical to success;highly productive organizations have high communication saturation. The cost inherently in communication, however, makes it prohibitively expensive for organizations with many roles to achieve high communication saturation. None of the projects with large number of roles had high communication saturation, and none were highly productive, leading us to conclude that complex organizations would benefit from reduction in the number of roles they have

Reference - Patterns of productive software organizations - Bell Labs Technical Journal, Summer 1996  - paper available here

Corollary to this, please also see Distribute work evenly , and Fewer Roles

The hierarchical nature of flow of work in SAFe increases coupling which increases latency - "An organizational structure that causes information to flow through many roles not only increases latency (delay), but can cause loss of information fidelity. Like light, as information passes through many filters, it loses definition and accuracy." 

Also, the very fact that multiple roles exists makes it relatively easy people to relabel their current role to a new one without having to change their behavior, i.e. from a systems thinking perspective, the underlying structures would remain the same effectively precluding any meaningful organizational change. 

It is a mistake, I think, to say that SAFe is poison and terrible and disastrous in all cases it could be applied. It is also a mistake to say that consultants who help with SAFe are evil and are selling snake oil. 

As far as I know, no one has said either of those things. 

Ron Jeffries

ronjeffries.com

In times of stress, I like to turn to the wisdom of my Portuguese waitress,
who said: "Olá, meu nome é Marisol e eu serei sua garçonete."

[Howard Sublett]

Alan, 

Very week said.  

One day, I'll be wise like you!!

Howard Sublett

Cell: 501.622.7929

Sent from my iPhone

[Mark Levison]

Ron - inline

On November 23, 2016 at 3:59:52 PM, Ron Jeffries (ronje...@acm.org) wrote:

There are really very few examples of larger organizations that successfully went Agile. I think that LeSS, and Mike’s approach, have a prayer. I think that SAFe may not even have that much.

Yes many organizations will fail to evolve significantly. Unfortunately the market will eventually replace them with more effective organizations that have grown from the ground up being Agile in their DNA. We’re rapidly moving into a game of change or die.

Cheers

Mark

[Alan Dayley]

Yes, the lesser of two evils is still evil. My point is that we consultants (and coaches and ScrumMasters and change agents), we dance the art of the possible. In that dance, we each choose the possibilities that we can live with and leave the possibilities we can't live with. Andreas and maybe yourself cannot live with SAFe as part of your dance. And that's OK, even great. Hopefully those who do work with SAFe will do so in a way that pushes the possibilities in the Agile direction rather than other evil applications of SAFe structures.

I went to the extreme in my statements about poison and snake oil. I am sorry. Andreas obviously wrote an opinion against SAFe. I reacted too strongly on behalf of those of us working within organizations attempting SAFe.

Alan

[Mark Levison]

On November 23, 2016 at 8:20:07 PM, Alan Dayley (ada...@gmail.com) wrote:

Yes, the lesser of two evils is still evil. My point is that we consultants (and coaches and ScrumMasters and change agents), we dance the art of the possible. In that dance, we each choose the possibilities that we can live with and leave the possibilities we can't live with. Andreas and maybe yourself cannot live with SAFe as part of your dance. And that's OK, even great. Hopefully those who do work with SAFe will do so in a way that pushes the possibilities in the Agile direction rather than other evil applications of SAFe structures.

I went to the extreme in my statements about poison and snake oil. I am sorry. Andreas obviously wrote an opinion against SAFe. I reacted too strongly on behalf of those of us working within organizations attempting SAFe.

Alan - I figure there only a limited number of organizations I can seriously help in the next 10 years. I’m not interested in engaging with organizations that won’t make systemic change. My experience says that orgs that choose SAFe are choosing it to avoid dealing with the real issues. That’s their call. I’m interested in helping organizations that wish to thrive in the new era.

Cheers

Mark

[mj4s...@gmail.com]

On Nov 23, 2016, at 6:24 PM, Mark Levison <ma...@agilepainrelief.com> wrote:

I figure there only a limited number of organizations I can seriously help in the next 10 years. I’m not interested in engaging with organizations that won’t make systemic change. My experience says that orgs that choose SAFe are choosing it to avoid dealing with the real issues. That’s their call. I’m interested in helping organizations that wish to thrive in the new era.

Me too.  About a year ago I quit a steady income source to focus on organizations that are serious about fundamental change.  Initially it was a bit scary, but at least at the moment I’m getting a decent amount of that kind of work.

While I am concerned that SAFe is a retrograde force against Agility, I wonder whether it would even exist if we weren’t “certifying” people in Scrum without really checking to see whether they understand its principles.  It’s possible we are doing more harm than good by inoculating people against real agility. 

(Here’s what I wrote on the trainer’s list a while ago.)  

Two fundamentally different ways I’ve seen Scrum used in organizations.  The first is the most common:

Agile Toes: Scrum is the “implementation" layer underneath a hierarchy of defined roles, which may loosely correspond to the original org structure (despite different names).  There are potentially many people called "Product Owner,” often middle managers who would have been called some flavor of PM the week before.  Various methods — sometimes resembling traditional project/program management — are used to synchronize and align them.  While lip service is paid to empowerment, coordination is mostly outside the teams and self organization is mostly contained within teams.  “Scrum Masters” are not expected to transform the outer organization, but they might act as coordinators since they were probably PMs before anyway. Coaches try in vain to “change the culture” of the organization.  Things are somewhat better than they were before.

Agile Everything: A real Product Owner sets priorities (in *one* Product Backlog, per the Scrum Guide) and vision, and it’s team self organization underneath that, even if there are multiple development teams.  Previously unthinkable responsibilities eventually move into the realm of team self organization.  The teams need to be truly cross functional feature teams, as connected to real customers as possible.  XP skills are paramount.  Teams of teams self organize and collaborate across team boundaries in one Sprint, with one integrated product at the end of each Sprint.

Here’s why I haven't had to do many certification classes this year: The main client I’ve been working with lately is moving from Agile Toes to Agile Body.  They are expanding Scrum’s reach to DE-scale all the defined roles, hierarchies, and specialization.  They realize they need less crap in the middle.  Even key people in their HR department have acknowledged the damage their policies have caused.  The senior exec who brought me in travels with me to every class and most coaching sessions.  He's already experienced what’s usually sold as an “Agile transformation” and understands that Scrum of Scrums and Fibonacci numbers don’t even begin to tackle the real issues.  I’d rather try and maybe fail at this than teach a bazillion certification classes.

While I’ve been influenced by Craig’s ideas since 2003, and Bas since 2007, their third LeSS book "Large-Scale Scrum: More with LeSS” has been worth its weight in gold.  I know these guys have annoyed a lot of people and I know their first two book collaborations were too thick for most people to read, but pretty much every page of the third book gets to the real issues organizations have in “doing Scrum” and practical (if tough) steps in dealing with them.  If people are interested I’ll write more specific details about that later.  The LeSS book and class are recommended for trainers/coaches who are tired of hearing “Thanks for the certification but we can’t do Scrum because of XYZ underlying reason.”

—mj

(Michael)

[mj4s...@gmail.com]

Footnote to this: I took a Nexus class from Richard Hundhausen and Mike Vincent, and also found it reasonably aligned with Scrum and Agile (at least compared to SAFe).  So I’m hoping the people who are reluctantly teaching SAFe will become aware of alternatives over the next year.

[Kevin Shine]

Hi Mike

I agree. The main focus for me is always the team and scrum. Safe or not safe I don't know if that really matters. It seems to me like people are all upset about safe when in fact they should just worry mostly about scrum in the team. If you get that right then having a portfolio kanban wall is great. You don't have to do everything safe has in the framework. Rather know why certain things have been said and make a fit that suits the organisation. Maybe the real key is customisation and seeing all of these frameworks as pointers to things you can try that worked before in other places for specific reasons.

On Wed, 23 Nov 2016 at 11:51 PM miked <miked...@gmail.com> wrote:

SAFe helps the middle world of the organization move from the academic surity of time management to the relative insecurity of value and clarity.  The feedback I get from the Scrum Team and Product Owners on the ground in SAFe efforts is feedback loops that are too long.  The range of impact goes from minimal with legacy to impossible with mobile apps.
Most SAFe folks I know tell me SAFe works only when teams on the ground do Scrum well.

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.