Talk:Scaled agile framework/Archive 2.

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)


 * @Grahamatwp I am confused, on 12 April 2016‎ I added some criticism. So criticism of SAFe already existed in the article when you added this on 8 June 2016. In fact the wording was not acceptable because as it was constructed it breaches WP:PSTS "". -- PBS (talk) 21:14, 11 September 2017 (UTC)


 * @Grahamatwp As a source for criticism, you can use https://www.forbes.com/sites/stevedenning/2015/07/22/how-to-make-the-whole-organization-agile/#487c78d85841 --5.116.171.208 (talk) 08:34, 17 September 2017 (UTC)

Needs updating - SAFe is now at version 4.5
This page needs to be cleaned up and updated. The Scaled Agile Framework is now at version 4.5. This includes a configurable big picture to accommodate different use cases. This article highlights some of the changes in the new version: http://www.scaledagileframework.com/blog/safe-4-5-goes-live-top-5-reasons-to-update/

50.246.205.57 (talk) 00:13, 6 September 2017 (UTC)Melissa Reeve

WP:STRUCTURE
I originally added the criticism to the introduction and am disappointed to see that some editors have decided first to move the criticism into a ghetto section at the bottom of the article and then to summarise the quotes.

I think moving the criticism into its own section at the bottom is a breach of the NPOV policy specifically the section WP:STRUCTURE that says:

I think it a mistake to try to summarise the quotes as the style of wording used by the critics is reasonably succinct and the quotes help readers to appreciate the tone and nuances of people in most cases notable enough to have thier own articles on Wikipedia.

Therefore I think that the criticisms should be addressed early on so that people who read the whole article can judge for themselves if when reading the details of the method if those criticisms are worth considering. -- PBS (talk) 21:03, 11 September 2017 (UTC)


 * Agree. Sections labeled "Criticisms" are flame-bait; pro-subject editors jump in to counter each critique with the TRUTH, which leads to counter-counters, and on it goes.  I've seen this happen many times; the result is an embarrassment for WP.  Only if enough dedicated less POV-ish editors join in can this eventually be smoothed out into balanced, encyclopedic, informative prose of notable pros and cons.  That's now what we have here.  Thanks.  --A D Monroe III (talk) 17:08, 12 September 2017 (UTC)


 * Agreed. The criticism in the lede outweighed the initial description, so appeared imbalanced at that point. That said, would agree on the issues highlighted about it being in a section marked criticism. Have now moved those criticisms into the section (history). As a personal note of action, I will now be taking this advice on to other articles with separate criticism sections. Thanks. Davidjcmorris  Talk  07:09, 9 October 2017 (UTC)

Then the thing to do is to increase the initial description rather than decrease the criticism. I also think that many of the changes made since I last edited the piece are not helpful:
 * The lead should be a summary of the content. If it is it does not need citations to support the content of the lead.
 * From to  . This change now means that a point of view is being expressed in the passive narrative voice of the editorial. (see WikiVoice]]
 * from to  The first sentence is not perfect. In point of fact SAFE will not work/be cost effective if the number of people on an Agile Release Train (ART) is less than about 100 people although their documentation states 50 would be the lower limit (so go with that). That is about five Agile teams of eight each and another teams worth to administer the ART process. The trouble with the replacement wording is "claims" (see WP:CLAIM) and that it implies that there is no lower limit. Basically if the number of people is too low the overheads of running an ART probably costs more than the benefit. (That is not to say that cherry picking some of the ideas from the methodology would not benefit any organisation with two or more agile teams (eg cadence)).

User:Davidjcmorris you write "The criticism in the lede outweighed the initial description" yet the lead 2 October 2017 before you edited did not have any criticism in it. You added the wording of criticism to the lead (on which I have already commented on in this post.

If you meant the initial section which you have renamed history (not sure why), I find it odd User:Davidjcmorris, that you chop back the wording of both the pros and cons in that section. I think that the previous wording was much better than what is currently there, although things like those I mentioned about the size in the third bullet point above should be added to help with balancing the article. I do not think we should be paring back either part of the text.

-- PBS (talk) 19:44, 11 October 2017 (UTC)


 * Some time ago, there was a separate criticism section which was way down the page. Someone removed that and added a slightly edited version of the criticism to the lede. However, that resulted in a lede which looked to be 80% criticism. Not a balanced approach. I initially replaced these edited criticisms with a reference to the fact that there was criticism, and moved them back into their own section, albeit higher in the article (just under the existing history section). Reading further commentary on this talk page, I noted that some editors felt that consigning criticism to its own section was not encyclopaedic, so I merged them into the existing history section in an appropriate chronological position. Rather than simply revert the whole thing, though, let's collaborate on refining the words to retain some of that earlier sense you admired while achieving the aim of moving all the criticism out of the lede. Davidjcmorris  Talk  04:22, 12 October 2017 (UTC)
 * I think we are talking across each other. By lede do you mean lead? If so on Wikipedia lead has a specific meaning see WP:LEAD. -- PBS (talk) 05:38, 12 October 2017 (UTC)
 * "Lede" is an alternate spelling of "lead", and is less ambiguous. Walter Görlitz (talk) 05:55, 12 October 2017 (UTC)
 * It is not the spelling I am enquiring about, but the specific usage (see WP:LEAD). -- PBS (talk) 05:59, 12 October 2017 (UTC)
 * Usage would be identical. What exactly is your concern? Walter Görlitz (talk) 06:10, 12 October 2017 (UTC)
 * User:Davidjcmorris seems to me to be using "lede" to mean something other than WP:LEAD, but User:Walter Görlitz please wait and let User:Davidjcmorris answer my questions. -- PBS (talk)
 * Sure. . You're up. Walter Görlitz (talk) 18:03, 12 October 2017 (UTC)
 * My use of lede is an historic writer's device to avoid confusion with the the metal lead (Pb). Hopefully it doesn't distract too much. According to the WP:LEAD definition, "articles should start with introductory text (the "lead"), which establishes significance, includes mention of significant criticism or controversies, and make readers want to learn more" (my emphasis). I was concerned that 100% of the criticism had been moved to the lead ; hence I moved it out and replaced it with a mention. The lead should continue to be developed; as the article takes on more substance, it should probably head toward the 4 paragraphs. Davidjcmorris  Talk  18:56, 12 October 2017 (UTC)
 * The first sentence in LEAD states "" As I wrote above (here) it was you who introduced criticism in to the lead. So are you writing about the first section that you renamed "History" or the lead? -- PBS (talk) 07:48, 13 October 2017 (UTC)
 * My word, we have been talking at cross-purposes. My apologies. I mistakenly thought you said I had removed the criticism quotes from the lead, whereas I had originally removed them from the old Introduction section (where you put them). Reviewing the page now, you will see the trimmed quotes are back where there were, it's just that the section is now called History. To your other point, I certainly did add mention of the criticism in the lead, which follows the Wikipedia guidance you referenced. Hope that clears it up. Davidjcmorris  Talk  04:17, 14 October 2017 (UTC)

@User:Davidjcmorris Ok now that we have our terminology sorted out lets start talking about the text.
 * See my comments of the 19:44, 11 October 2017 (linked here).
 * I think that the name "introduction" is preferable to "history".
 * I had already pared down the quotes and I think that your further paring of them is unhelpful. I agree that the section is unbalanced, but I think the way to fix that is to increase the text in the section to balance the quotes not to remove information. -- PBS (talk) 13:47, 17 October 2017 (UTC)
 * Sure. Or maybe 'Overview'? In any case, I think the bulk of what is in that section could go up in the lede/lead. Still not sure we should quote the criticisms in this way; it lends the overall article an odd argumentative feel; especially as there are no quotes from any SAFe supporters. I know people 'out there' get hot under the collar about this, but that is not encyclopaedic; we should be able to present and report without buying in to either school. Unless you can show other examples where this has been done, I think we would be better served by summarising the points and linking to the original sources. Incidentally, I like the comment below about restructuring the article. I will be looking at that when I am back (have been on holiday). <b style="color:#666">Davidjcmorris</b> <b  style="color:#FFF;background:#666"> Talk </b> 15:06, 28 October 2017 (UTC)
 * Amended heading back to Introduction; reconsidering other points from an encyclopedic perspective. As may be noted from my comment at the top of the talk page, I tagged the article as needing more balance, as it was overly positive in March 2016. Now seeking to redress the weight of the criticism to bring it back into balance again. <b style="color:#666">Davidjcmorris</b> <b  style="color:#FFF;background:#666"> Talk </b> 20:15, 29 October 2017 (UTC)

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. <b style="color:#666">Davidjcmorris</b> <b  style="color:#FFF;background:#666"> Talk </b> 17:48, 27 November 2017 (UTC)

Small Glitch
I noticed that in "Levels / 3-level SAFe / Portfolio" references "value streams" although this term never shows up in the smaller levels (Team and Program). I assume we can safely replace "value streams" by "programs" here, but wanted to check since I am by no means SAFe expert. Rklmm, 14:55 UTC, 17 October 2017
 * No, value streams are important (and the levels at which they're ignored). It's one of the places where SAFe drifts away from better Agile methodologies.
 * Sadly I'm not familiar enough with SAFe (I'm an Agile developer instead) to expand further, or source, this. Andy Dingley (talk) 15:22, 17 October 2017 (UTC)
 * Digging around in here might turn something up: http://www.scaledagileframework.com/value-streams/
 * The problem, and it's even worse with "Agile Release Trains", is that SAFe is Waterfall, dressed as Agile. It can't get away from its one-big-drop timescale planning, and massive hogtying with process. To SAFe, "adding value" is so exceptional an event that they have to plan some giant "stream" around it at a high level, and do nothing at a low level. For Scrum or Lean, "adding value" is just "what you do" all day. Everything in Scrum is based on doing the smallest amount of work to do one identifiable, measurable, tested and working unit of added value. It's the smallest piece of anything. It's not some additional process you put on top. Andy Dingley (talk) 15:28, 17 October 2017 (UTC)
 * Not sure whether my point came across very well. This is more on the language level: the section references a term that has not been used in preceding text so the reader cannot connect the dots properly.  Either we should replace the term "value streams" in this section or add an explanation further up.  Rklmm, 15:52 UTC, 17 October 2017
 * Oh, I think I get it.
 * The problem is that SAFe is valueless. Only once you start doing the super-complicated, super-huge 4-level version of it (restricted only to Lensmen and Ascended Thetans) do you start creating value with this "value stream" mechanism. The more common levels of SAFe do not have such a concept of adding value.  In Agile systems instead, "adding value" is a key task that takes place at the very smallest level upwards.  Fundamentally this is because SAFe isn't about creating deliverable value for customers, it's about process dogma. Andy Dingley (talk) 16:24, 17 October 2017 (UTC)
 * http://www.scaledagileframework.com/# → http://www.scaledagileframework.com/value-streams/ I don't think you ought to confuse a value stream with adding value. The concept behind Agile is that your costs are by and large fixed IE you have a number of employees who you are not going to fire because all employees are interchangeable bits used by the power tool that is the organisation. What agile does is present a methodology that allows them to work in a more productive way (as the cost of the agile team members does not alter radically very much and presumably if they become self managing they need less management to mange them). — This is a difficult concept for people who consider software projects to be like large building projects where individuals join an organisation to do a specific project and then move on to another project in another organisation. This is thinking of the software equivalent of building the chunnel once done the tunnellers move on and leave the running of trains to those who do that job. Instead SAFe like Agile in general, assumes that the organisation even if doing project work will stay in existence and move as a whole organisation onto the next job, eg once the chunnel is finished it is on to another tunnelling job with the same personnel just a different location.  Keep the second model in your head and then see if the link to value-streams makes more sense.


 * To answer your question about the article structure, I think it needs a rewrite to describe what SAFe is today not now it got there. Basically what they did was start with was "how do we organise multiple agile teams to work together?" which is basically describing scrum of scrums with bells and whistles. From there they moved up and down a typical organisation until they had an answer for "What can SAFE do for me" for people at all levels of an organisation. I think that trying to explain it by how they got there is confusing as exemplified by this this sentence . -- PBS (talk) 19:04, 17 October 2017 (UTC)
 * That's why SAFe has different levels. 4-level is only for really big projects.
 * But why does SAFe have no concept of value in 3-level projects? Value just isn't really part of SAFe, because customers aren't part of SAFe, they're merely an annoyance to the bureaucracy, its real function. SAFe is not Agile - one reason why (of several) is that it ignores concepts of value and customer delivery in favour of just being another set of process-bound waterfall first and foremost - the opposite of Agile.
 * If you learn Scrum (well), you learn from the squirrelburger upwards; to quote SAFe itself, "Lean-Agile methods both focus intensely on continuous value delivery, where value is achieved only when the end user, customer, or internal business process receives the business benefit of some new solution or Capability." which isn't a bad way of putting it. Lean is similar, distinguishing value from muda. But SAFe does none of this - it ignores "value", until you get up to 4-level and the massive burden of value streams - which are still not the same thing as adding value. Andy Dingley (talk) 19:42, 17 October 2017 (UTC)
 * Actually, this is a fundamental misunderstanding of the term value stream. My reading of SAFe is that value is delivered as often as required, because the core of SAFe at the delivery team level is still Scrum and XP. While SAFe might have regular planning ceremonies (eg. on a quarterly basis), this is not tied to when product increments are released. Teams release whenever the product owner / organisation sees fit ... many times per day, at the end of every sprint, or maybe after a few sprints. This is typically tied to how complex the integration is, delays due to dependencies and legacy systems, and pauses for regulation / governance / tradition. The term value stream merely denotes an end-to-end process that covers all activities from getting a requirement from a customer to putting it into the hands of their end-users. This covers more than the delivery team (ie. including the work of the rest of the organisation). The fact that the term only appears in four-level SAFe is because they wanted to call the upper level something different; they appropriated value stream because it arguably better supports the notion of integrating multiple programs of work (and, yes, even from waterfall teams, if an organisation still uses that for some components). The terms could have been better chosen, but they are what they are. <b style="color:#666">Davidjcmorris</b> <b  style="color:#FFF;background:#666"> Talk </b> 14:28, 28 October 2017 (UTC)

LAFABLE
The Large Agile Framework Appropriate for Big, Lumbering Enterprises parody website that Mike Cohn released as an April Fool's joke some years back has made an appearance as an ostensibly valid link on the Scaled Agile Framework page and in the template for Template:Software development processes. I have removed these with appropriate comments. Let's watch out for this coming back. <b style="color:#666">Davidjcmorris</b> <b  style="color:#FFF;background:#666"> Talk </b> 19:19, 14 November 2017 (UTC)