Skip to main content

Reflecting on first few steps of SAFe's "implementation roadmap"

Last post 05:57 pm October 10, 2017 by Ian Mitchell
5 replies
11:08 pm September 7, 2017

I have been looking at SAFe's "Implementation Roadmap" (http://www.scaledagileframework.com/implementation-roadmap/) and reflecting on my own experiences standing up Scrum teams in large organizations. I am wondering if anyone has seen the pattern of somewhat forced middle management engagement as seen in the first few steps of the roadmap work in practice? By first few steps I am referring to everything prior to the "create implementation plan" step.

My gut tells me most of the managers will predictably distort the intent even with the forced engagement unless there is enough executive pressure, executive insight, and transparency mechanisms to avoid it. With enough executive buy-in it would seem leveraging a Scrum Studio with a much flatter reporting structure would be just as politically tractable and avoid so many of the problems SAFe doesn't address. 

Perhaps I am trying to understand what nuggets of useful advice can be gleaned from how SAFe approaches the change management problem, given that I am loath to blindly trust any of it which doesn't resonate with my own experience.

I am not asking a SAFe vs. Nexus question. I suspect most everyone on this forum recognizes the myriad of challenges with SAFe.

Presumed discussion baseline:

* Craig's Larman's laws of organizational behavior. (https://less.works/less/structure/index.html)

* Charles Bradley's nice list of SAFe critiques:

http://www.scrumcrazy.com/Is+SAFe(tm)+Bad%3F++Is+it+unsafe%3F++Is+it+Ag…

 


05:03 pm September 9, 2017

The "pattern of somewhat forced middle management engagement" you refer to is fairly well known and is sometimes referred to as the "frozen middle" or the "organizational permafrost".


02:15 pm September 29, 2017

Different question maybe.  

 

We also had started down the road of using SAFe, mostly I think because it seem to include the idea of some enterprise portfolio management approach, which would not be a big change to the before agile process.   Familiar to folks.    When I look at Nexus, is it's focus more at a product level on down?   Or some assumption that somehow the decision had been made to spend money?      I've been trying to figure out how you might want to try and sell why one might want to use Nexus vs SAFe, what are the main differences, what problems does one approach address versus the other. 


02:33 pm September 29, 2017

SAFe provides a big picture upon which organizations can try to map their existing practices and dysfunctions. Nexus puts an emphasis on integrated product delivery, which is more likely to require deep organizational change.


01:44 pm October 10, 2017

Hi Ian.   I think SAfe also asks for organizational change, even if you just limited it to mapping roles and responsibilities and didn't try to change approach.         


05:57 pm October 10, 2017

Is “mapping roles”, while avoiding matters of approach, likely to cause enough change for an organization to become agile?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.