Talk:Scaled agile framework

Greater balance

I have tagged this page as requiring clean-up as it is written from an overly positive point of view (reads like marketing or a quote from a book). Please note (in the interest of full disclosure), I strongly believe that SAFe is an important and positive contribution to product development. However; this page has been created at least twice before (to my knowledge) and has been deleted for the same reason. There are many parties (rightly or wrongly) who dispute the effectiveness or efficiencies claimed for SAFe, so to be more encyclopaedic, the article should strike a more balanced note. Davidjcmorris  Talk  21:28, 26 March 2016 (UTC)

Following words from author of SAFe (Dean Leffingwell)

HI Vinpinhari. Thank you for creating this page. As the author and creator of the Scaled Agile Framework, there are several points of clarification that I recommend to create a more accurate and comprehensive page.

Please let me know what follow up questions you might have. References follow the recommendations.

Replace: After every 5 iterations, a train delivers a potentially shippable increment (PSI). A demo along with Inspect and Adapt sessions will be held. Also, planning will begin for the next increment.

With:

Teams develop complete systems in short iterations, typically two weeks in length. The Program Increment is a larger, quantum measuring point, which typically occurs on a cadence of 3-5 development iterations, followed by one Innovation and Planning (IP) Iteration. Each PI concludes with a demo of all the functionality that has been developed through the course of the PI. This is accompanied by an Inspect and Adapt session that includes root cause analysis and identification of systematic improvements.

The Innovation and Planning iteration supports the dedicated time for PI system demo, innovation and face to face PI planning.

This describes the basic development cadence, which synchronizes teams to a common mission and cadence, and focuses on the frequent integration of the full system. However, Teams and Programs can release functionality at any time the market demands, including continuous delivery.

Replace There are two different types of SAFe implementation, 3-Level SAFe and 4-Level SAFe. 3-Level SAFe is for smaller implementation with 100 people or less whereas 4-Level SAFe is for larger solutions having 100 or more people

With 3-level safe is generally applied in enterprises with Agile Release Trains that have less than 100 or so practitioners, although there can be many such programs within an enterprise portfolio. So a single instance of 3-level safe can often handle many hundreds of practitioners.

4-level safe is designed for the largest systems builders, enterprises that build systems that require the cooperation of multiple Agile Release Trains. In some cases, 200-400 people, and even more, are required to build these largest systems.

In addition, the large enterprises typically deploy multiple SAFe instances, one for each business unit, division or significant product line. Within that portfolio, there may be implementations of both 3-level and 4-level SAFe.

Replace: A portfolio is a collection of programs which accounts for the whole part of budget going into software development.

With: A portfolio contains the value streams that sponsor the various solutions, which are realized by program-level Agile Release Trains. Portfolio fiduciaries fund value streams and apply lean-agile budgeting to eliminate much of the overhead and multiplexing caused by traditional project structures and project cost accounting.

References

Deanleffingwell (talk) 22:01, 16 March 2016 (UTC)Dean Leffingwell

How to get this article to be more wiki-acceptable?

Davidjcmorris wrote:

I have tagged this page as requiring clean-up as it is written from an overly positive point of view (reads like marketing or a quote from a book). Please note (in the interest of full disclosure), I strongly believe that SAFe is an important and positive contribution to product development. However; this page has been created at least twice before (to my knowledge) and has been deleted for the same reason. There are many parties (rightly or wrongly) who dispute the effectiveness or efficiencies claimed for SAFe, so to be more encyclopaedic, the article should strike a more balanced note. Davidjcmorris Talk 21:28, 26 March 2016 (UTC)

From the SAFe team: Who can we work with on the Wikipedia side to ensure that this article is factual and more encyclopaedic? Right now, the SAFe team is in agreement that the current article does not sufficiently represent SAFe. It also has some factual errors. The last couple of times that we tried to fix these items directly, the page was deleted. Is there someone in the wiki community that is willing to own this page? We are happy to provide that person information about SAFe and that individual can also research any reputable sources that may provide a counterpoint.

Criticism added

In the interest of NPOV I added some criticism. As a mature engineer and a devops working in a good scrum environment in which SAFe is about to be drafted in I am always apprehensive of new-fangled methods. Especially ones that regurgitate historic ones which are sometimes put to bed with good reason. Obviously a page written by the creator with a financial interest in the product's success is vulnerable to over optimism. It would be refreshing to see some self criticism. Oh and FYI "..we will work with wikipedia..." is not what Wikipedia is about. Wikipedia do not refine articles, that's down to readers, like me, who can see the obvious marketing. Grahamatwp (talk) 08:08, 8 June 2016 (UTC)

63.225.16.218 (talk) 15:18, 28 March 2016 (UTC)Melissa & The SAFe team