Talk:Scaled agile framework/Archive 1
 | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
| Archive 1 | Archive 2 |
Criticism in the introduction section
The majority of the introduction section is criticism from SAFe's detractors. It should be moved to the criticism section, and the introduction section should be expanded (eg with some historical context).
63.241.111.230 (talk) 17:49, 2 February 2017 (UTC)
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
- ^ http://www.scaledagileframework.com
- ^ Bloomberg, Jason. "Scaling Agile Development for Digital Transformation". Forbes. Forbes.
- ^ Leffingwell, Dean (2007). Scaling Software Agility: Best Practices for Large Enterprises (First ed.). Addison-Wesley. ISBN 978-0321458193.
- ^ Leffingwell, Dean (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise (First ed.). Addison-Wesley. ISBN 978-0321635846.
- ^ Linders, Ben. "Lean and Agile Leadership with the Scaled Agile Framework (SAFe)". InfoQ. Retrieved 12 January 2015.
- ^ Crain, Anthony. "Cracking the SAFe: An expert's take on the Scaled Agile Framework". Tech Beacon. HPE. Retrieved 20 October 2015.
Deanleffingwell (talk) 22:01, 16 March 2016 (UTC)Dean Leffingwell
Levels section needs work
The Levels section as currently written says that Teams use eXtreme Programming, but doesn't mention either Scrum or Kanban methodologies, while the actual SAFe whitepaper says "Teams employ Scrum (primarily) or Kanban methods. Each of these methods is augmented by built-in quality practices. Many software quality practices are derived from eXtreme Programming, while hardware and system quality practices are derived from contemporary Lean product development practices." There's also needless detail about architectural vs "System Team" (mixed caps for some reason) rather than just focusing on what the actual purpose/structure of the teams are in a general case.
SAFe itself seems to provide confusing guidance about the distinction between 3- vs 4-level, as the 4th level is the optional "Value Stream level", per their white paper, but the Portfolio level (common to both 3- and 4-level) "organizes and funds a set of value streams", which does not make sense to me if the Value Stream level is optional. I will not modify this section of the wiki page since it matches what SAFe has published, but if someone more familiar with this can add clarity to the organization that would be helpful.
Words from the author of SAFe (Dean Leffingwell)
WRT to Wilhemp comments: Value streams are the fundamental organizational metaphor in SAFe. A SAFe portfolio is considered to consist of a set of value streams, each of which contains all the people and steps necessary to define, develop and deliver a set of products, solutions or services to a customer. Value streams are realized by one or more Agile Release Trains, a cross-functional team of agile teams and other stakeholders fully capable and committed to delivering some or all of a value stream solution. Small value streams can be delivered by a single ART of 50-125 people. In this case three-level SAFe is all this is needed. Larger value streams typically require more rigor of solution intent, as well as additional cross-ART coordination roles, responsibilities, and events. The optional SAFe Value Stream level is designed for this purpose.
WRT architecture. There is no architecture team in SAFe. Architects participate as members of individual ARTs, though they also typically participate in larger Communities of Practice. They may reside with the system team, and participate in planning and the events. In this case, they are simply part of an Agile team, like everyone else. SAFe Agile teams apply Scrum (primarily) or kanban. Many apply a hybrid: Scrum for roles and events, a kanban board for flow and identification of bottlenecks. All SAFe teams apply build in quality practices. Most software quality practices are derived from XP. Hardware and other teams use practices derived from lean system development.
Deanleffingwell (talk) 16:56, 5 December 2016 (UTC)