Talk:Scaled agile framework

New section on challenges of scaling

Now restructured the lead/lede paragraph to provide a more holistic overview, and introduced a new section on the challenges of scaling that SAFe seeks to address, which is the context for most of the criticisms. This means the article now includes more criticism, and there are more cited references for all the points. The 3 level vs 4 level section still needs sorting out, because it is based on SAFe v4.0. But that can be for another editor or another day. Davidjcmorris  Talk  17:48, 27 November 2017 (UTC)

Capitalization of frameworks

The MOS:CAPS states that "only words and phrases that are consistently capitalized in a substantial majority of independent, reliable sources are capitalized in Wikipedia". Software development frameworks such as Disciplined Agile Delivery (DAD), Large-Scaled Scrum (LeSS), and the Scaled Agile Framework (SAFe) are either formal trademarks or recognized and used in the form of capitalization. These terms should be expressed in this way. The exception being the article title, which I already rest to Scaled agile framework (ie, with leading capital only). Davidjcmorris  Talk  22:03, 27 November 2017 (UTC)

Is that really the case? I will revert. Walter Görlitz (talk) 23:48, 27 November 2017 (UTC)

Proposed improvements to introduction

Hi, I'm Jerry and I'm here to propose updates to this Wikipedia article on behalf of my employer, Scaled Agile Inc. Some other company representatives have posted to this discussion page before, but I will be the only employee proposing updates for the time being.

I'd like to start by suggesting some clarifications to the text in the introduction.

First paragraph

• I recommend splitting the opening sentence into two: "The Scaled Agile Framework (abbreviated as SAFe) is a knowledge-base of organization and workflow patterns. SAFe's content is made freely available while being a registered trademark of Scaled Agile, Inc.
• In the third sentence (starting "Along with…"), I propose changing "this is one of a growing number of frameworks that seek to address" to "SAFe is one of a growing number of frameworks that seeks to address".

Some minor edits made. We need to limit the use of the SAFe abbreviation, lest it become a noise word. Davidjcmorris  Talk  19:03, 8 May 2018 (UTC)

Third paragraph (starting "The primary…")

• I propose changing "product management" to "portfolio and product management".
• I propose removing "through governance".
• After "portfolio management", I propose adding, ", to Agile program teams, to Agile development teams, out to customers".

With these changes, the sentence would read: "The primary reference for the scaled agile framework was originally the development of a big picture view of how work flowed from portfolio and product management, to Agile program teams, to Agile development teams, out to customers."

The portfolio concept is a scaling of products or programs, so instead I introduced other stakeholders as a source of work. In my opinion governance should remain as an important form of oversight -- this is implemented in different ways depending on the the level of SAFe, so governance is broad enough to cover them all in an abbreviated form. Davidjcmorris  Talk  19:03, 8 May 2018 (UTC)

In the same paragraph, I propose replacing "With the collaboration of others in the agile community, this was progressively refined and formalized, then included in a 2007 book. Since then, the framework has continued to be developed and released into the public domain, also supported by an academy and an accreditation scheme for third-party consultants" with the following content:

"SAFe has been progressively refined and formalized through collaboration of others in the agile community. Early concepts of the framework were described in 2007 and 2010 books. Since then, the framework has continued to be developed and released publicly. SAFe is also supported by an accreditation program for internal enterprise professionals and third-party consultants."

This corrects existing language by noting both books (see 2010 book info here) and replacing mention of an academy with the accreditation program. This page might be helpful for providing a better understanding of the agile community.

Changed to progressively refined and then first formally described in a 2007 book (I recommend considering if there is utility in referencing the later book to support other sections). Changed to shared publicly. Replaced third-party consultants with those who seek to implement, support, or train others in the adoption of SAFe. This should covers anyone (whether internal or third-party) and removes the snark in referencing consultants. Davidjcmorris  Talk  19:03, 8 May 2018 (UTC)

Last paragraph

Finally, the last sentence of the introduction currently says, "Although SAFe has been recognised as the most common approach to scaling agile practices, it has been criticised for being too top-down and inflexible." I propose expand this to say:

"There are over 40 published case studies describing the application and results from applying SAFe in multiple industries. Although SAFe has been recognized as the most common approach to scaling agile practices across the enterprise, it has been criticized for being too top-down and inflexible."

Information about case studies can be found here.

Are there any volunteer editors who are willing to review and discuss these proposed changes? Your help is appreciated. Thanks. JB at Scaled Agile (talk) 15:03, 2 May 2018 (UTC)

@Davidjcmorris and Walter Görlitz: I see you've both contributed to this talk page in the recent past. I'm inviting you to participate in this discussion, if you'd like, in case you don't "watch" this page. Thanks. JB at Scaled Agile (talk) 17:15, 8 May 2018 (UTC)

I saw the additions, but I don't see a problem with the content as it currently stands. I'll review it when I have a chance. Walter Görlitz (talk) 17:35, 8 May 2018 (UTC)

Likewise. The case studies are of interest, but are all published on the Scaled Agile website. Wikipedia recommends citing authenticated independent sources over primary sources. If you have third-party material that substantiates this point, then it could be worth including. However the point is already well made that SAFe is the most common approach. Davidjcmorris  Talk  19:03, 8 May 2018 (UTC)

Thanks for the feedback and for making some changes to the article. JB at Scaled Agile (talk) 21:39, 14 May 2018 (UTC)

Addition of background?

Hello again. I am back with another proposal for improving this Wikipedia article. The article as is jumps straight to the "Challenges of scaling agile principles and practices" section, which seems like it might be confusing for readers who are trying to learn more about the framework. I think the article could be improved by providing readers with background information about the framework first, then discussing challenges later in the article.

I'd like to suggest adding a new "Background" section with a brief and simple overview of the framework:

The scaled agile framework (SAFe) was originally developed by Dean Leffingwell, and is now owned by Scaled Agile Inc., a company he co-founded in 2011. Leffingwell continues to serve as the chief methodologist for SAFe. Scaled Agile is based in Boulder, Colorado, and expanded into a larger office space in early 2018.

Since the initial launch of SAFe 1.0 in 2011, Scaled Agile Inc. has provided four major updates, culminating in the current version 4.5 as of 2018. The network's adoption rate increased by approximately 50 percent between 2014 and 2015. As of 2017, SAFe had become the most used method framework for scaling agile, adopted by up to 45 percent of enterprise level companies, according to cPrime's 2017 report on scaling agile.

References

I'm open to suggestions, and can answer questions here. Like before, I am submitting this request on behalf of Scaled Agile Inc. and won't be editing the article directly. Thank you to volunteers for considering and discussing this request. JB at Scaled Agile (talk) 22:50, 14 May 2018 (UTC)

It reads more like an ad for Scaled Agile Inc. to me, but I'll let others comment. Walter Görlitz (talk) 23:07, 14 May 2018 (UTC)

Happy that some of that would add to the information already on this article, but it would need to be toned down to avoid being a company promotion page. Any other thoughts. Davidjcmorris  Talk  20:08, 15 May 2018 (UTC)

@Davidjcmorris and Walter Görlitz: Thanks. Can you clarify which parts should be toned down? With some pointers I can try to propose some alternate wording. JB at Scaled Agile (talk) 19:37, 17 May 2018 (UTC)

Anything that is trying to sell the product rather than just describe it encyclopedicly describe it could be stripped. Walter Görlitz (talk) 19:45, 17 May 2018 (UTC)

There are different comments on different subsets of your suggestion:

• All the information about Dean and the office location is not appropriate on this page. If you want, you could create a page on Dean Leffingwell (or even on Scaled Agile, Inc). If you want examples of how that can be done, check out the page on Dave Snowden.
• Not sure what you mean by "the network's adoption rate", there is no mention of a network up to this point.
• We could legitimately add the reference for 45% saturation to the existing commentary about its market position. I just added it.
• The remainder of the points are fairly well covered in the remainder of the article. Davidjcmorris  Talk  01:30, 21 May 2018 (UTC)

@Davidjcmorris: Thanks for your help here. JB at Scaled Agile (talk) 20:52, 22 May 2018 (UTC)

Proposed updates to the SAFe framework section

Hello. Once again, I am back with suggestions for this Wikipedia article for editors to consider. This time, I'd like to revisit a discussion a colleague of mine had previously tried to bring to this page: updating the article to better reflect SAFe 4.5. Given that "The SAFe framework" section appears to be based on 4.0, it is no longer accurate about the types of implementation and levels.

The major changes between 4.0 and 4.5 are the following:

• Adding "Essential SAFe" as the new most basic configuration of SAFe
• Other configurations build upon Essential SAFe to add features that might be needed by organizations with more complex or specific needs, including:
  • Portfolio Level, which adds to Essential SAFe to configure as Portfolio SAFe and incorporates portfolio concerns, such as strategy and investment funding, lean budgeting, value stream definition and mapping, innovation across multiple value Streams, and lean governance
  • Large Solution SAFe adds Large Solution Level to Essential SAFe: it does not include Portfolio but is structured for enterprises and projects requiring contribution of multiple Agile Release Trains (ARTs) and Suppliers
  • Full SAFe includes Essential SAFe plus Portfolio Level and Large Solution Level, for very large enterprises building large products / solutions
• Addition of Lean Startup model and Lean UX process to guide through creating a final solution, via a minimum viable product or minimum marketable feature, respectively
• Addition of Scaleable DevOps and continuous delivery pipeline; DevOps helps enterprises break down silos and empower each Agile team, ART, and Solution Train to continuously deliver new features to end users
• Finally, 4.5 has an implementation roadmap that provides a pattern for organizations adopting SAFe. The Roadmap consists of an interactive graphic linked to a series of articles that describes the major activities that have proven to be effective in successful SAFe implementation

The full details of the differences in 4.5 are shown here

Unlike my previous requests, I don't have prepared material to add here, as I'm wondering how editors want to address this. What's the best way to try to update this section? Should the existing details be replaced entirely with ones specific to 4.5? Thanks. JB at Scaled Agile (talk) 19:41, 23 May 2018 (UTC)

That entire section is sourced with a WP:PRIMARY source. It should probably be deleted unless as WP:SECONDARY source can be found. Walter Görlitz (talk) 19:43, 23 May 2018 (UTC)

I think the section is due some attention, but would counsel against removal so that the community can remediate it. Updating it to reflect the latest edition makes sense. I will pay this some attention this weekend. Davidjcmorris  Talk  22:31, 30 May 2018 (UTC)

"Some attention" is an understatement. If you want to work on this, go ahead and restore after you've found sources. If it hasn't been remediated until now, why would a few days matter? Grayfell (talk) 22:50, 30 May 2018 (UTC)

I guess we can work from that too. Why? Indeed. It was purely a suggestion. We had a three-day weekend, so I thought I would have time. I have nothing invested either way. Keeping chilled and moving forwards. Davidjcmorris  Talk  11:20, 3 June 2018 (UTC)

It's a pity when content is removed in spite of a request to collaborate. However, what is done is done. Reinstatement just risks tit-for-tat edits. That wouldn't be collegiate either. Focusing on the rump that has been left, it is now completely unreferenced and the remaining content is still out of date, referring as it does to SAFe 4.0. I will work on content to bring this up-to-date with 4.5. The worth of the removed content can reconsidered another day. Davidjcmorris  Talk  23:44, 4 June 2018 (UTC)

@Walter Görlitz, Davidjcmorris, and Greyfell: Would this book (specifically, pages 87-89) work as a source? If so, I've written the following content (and had some help with the formatting) that is supported by the book and could be used in place of the current section. I see that Greyfell has already removed much of the previous content, so this would replace the short paragraph that is there now.

Framework content

Framework As of 2018, the most recent version of the framework is SAFe 4.5, which was released in July 2017. This version added the following key extensions: Essential SAFe and Configurability Innovation with Lean Startup and Lean UX Scalable DevOps & Continuous Delivery Implementation Roadmap SAFe Configurations In version 4.5, there are four configurations of SAFe: Essential, Portfolio, Large Solution and Full. Essential SAFe is the most basic configuration. The starting point for implementing SAFe, it describes the most critical elements needed to realize the majority of the Framework's benefits. Portfolio SAFe is for enterprises that build solutions that also need to incorporate portfolio concerns. These may include strategy and investment funding, lean budgeting, value stream definition and mapping, innovation across multiple value streams, and lean governance. This configuration adds the Portfolio Level to Essential SAFe. Large Solution SAFe is intended for enterprises that are building large and complex solutions that require the contribution of multiple Agile Release Trains (ARTs) and Suppliers, but do not require portfolio considerations. It consists of Essential SAFe and the Large Solution Level. The Full SAFe configuration is for large enterprises who build large solutions and also require portfolio strategy and governance. It includes Essential SAFe, along with both the Large Solution and Portfolio levels. In the largest enterprises, multiple instances of Full SAFe can be deployed. Lean Startup and Lean UX SAFe's Lean startup guidance embraces the highly iterative, hypothesize-build-measure-learn cycle. Specifically, this model can be applied to any Epic-level initiative, whether it arises at the Portfolio, Large Solution, or Program level. No matter the source, the scope of an Epic calls for a prudent and iterative approach to investment and implementation via a minimum viable product (MVP). The MVP provides feedback on the decision to persevere with the Epic's remaining work, or pivot to something of more value. The Lean UX process starts with an outcome hypothesis: Agile Teams and UX designers accept that the 'right answer' cannot be known in advance. Rather, they apply Agile methods to avoid Big Design Up Front (BDUF), focusing instead on creating a hypothesis about what business outcomes to expect from a new 'minimum marketable feature' (MMF). Teams then implement and test the hypothesis incrementally. This results in faster feedback, which steers the solution toward success more efficiently. Scaleable DevOps and the Continuous Delivery Pipeline Scaleable DevOps and the continuous delivery pipeline help accelerate the build-measure-learn cycle to support faster innovation and more frequent releases. DevOps is a culture and a set of technical practices that provides communication, integration, automation, and close cooperation among everyone needed to plan, develop, test, deploy, release, and maintain a solution. DevOps helps enterprises break down silos and empower each Agile team, ART, and Solution Train to continuously deliver new features to end users. The SAFe Implementation Roadmap SAFe's Implementation Roadmap provides a pattern for organizations adopting SAFe. The Roadmap consists of an interactive graphic linked to a 12-article series that describes the major activities that have proven to be effective in successful SAFe implementations. These steps are based on SAFe adoptions from large enterprises across a various industries

If so, here is inline citation markup: <ref>{{Cite book|url=https://books.google.com/books?id=qppNDwAAQBAJ|title=Enterprise Agility for Dummies|first=Doug|last=Rose|publisher=John Wiley & Sons|date=February 2, 2018|pages=87-89}}</ref> Thank you, all. JB at Scaled Agile (talk) 14:37, 31 May 2018 (UTC)

The book looks fine like a reliable source, although I'm sure better ones could be found. Walter Görlitz (talk) 14:47, 31 May 2018 (UTC)