Is our NetO approach "Scaled Agile," or Lean-Agile synergy at all scales?

Welcome to the Net Objectives Lean-Agile Portal Forums Net Objectives Consultants Coaching and Transformation Is our NetO approach "Scaled Agile," or Lean-Agile synergy at all scales?

This topic contains 8 replies, has 6 voices, and was last updated by  Max Guernsey 3 years ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #27816

    James Trott
    Keymaster

    Below is an email thread by Net Objectives leaders, about the idea of “scaling up” team-level Agile techniques, versus laying down a path for an organization to find its own, optimal way to how to work as a system while using Agile and other techniques as appropriate (but not as the main drivers).

    Below is the thread to this point in time (start at the bottom to read Al’s original, provocative question, and work up from there). Please feel free to post additional comments on this forum about “Scaled Agile” vs what we actually do.

    From: James Sutton
    Sent: Thursday, August 25, 2016 7:45 AM
    To: Rob Neppell ; Amir Kolsky ; Max Guernsey ; Al Shalloway ; DL NO Consultants Cc: Mike Shalloway
    Subject: RE: request for feedback

    I love the role you just played, Rob! Like Columbo, you are of course much more understanding than you are taking credit for.

    I agree with all you’ve said. Excellent.

    My main discomfort is, again, by using the same word (root) in two different contexts with different meanings, and allowing the context to determine which meaning applies, the potential for misunderstanding goes way up for those who haven’t gone through the kind of conversation we’ve just been having. Which includes essentially all our clients or potentials… And they think we’re doing one thing (“scaling Agile”) when we’re actually doing another (helping them discover their best path to their organization-as-a-system goals).

    I’d love it if we could disambiguate (one of my favorite words, and one I seldom get a chance to use…thank you everyone! LOL) the two meanings by using different words in each context. Though the fact that our industry now nearly universally uses the word “scale” and its variants freely in both contexts may make that difficult…

    To be clear, using “scale” as a synonym for “big” (as in “Scaled Agile”) is sloppy and misleading. Even if everyone in our industry uses it that way, it does our clients a disservice. If this didn’t have important implications to misleading them, I wouldn’t press the point. But it sets them up to think wrongly about what they’re trying to do…and that matters.

    From: Rob Neppell
    Sent: Thursday, August 25, 2016 10:32 AM
    To: Amir Kolsky ; Max Guernsey ; James Sutton ; Al Shalloway ; DL NO Consultants Cc: Mike Shalloway
    Subject: RE: request for feedback

    I’m one of the few here that aren’t deeply knowledgeable in this area of discussion, so let me see if my ignorance can be of benefit by asking for clarification. (And I don’t ask for my personal knowledge; I ask to ensure that the team has answers for a similarly ignorant client – and that they’re all the same).

    Amir’s last message reminded me of a distinction that became clear to me on my last trip down to Carlsbad where Al, you discussed your vision of our overarching approach to doing Agile at scale. The distinction was between the desired end state and the process of getting there. So a framework like SAFe might be a desired end state for an organization — but how you implement a process to get from where you are today to an organization that’s ‘doing SAFe’ is another thing entirely.

    If we’re talking to a client who (in Amir’s phrasing) has one team “being agile” and wants to “scale the agility across their organization”, am I correct in thinking that our collective view is that:
    1. Agility is a property that can be demonstrated by organizations at a small size, and it can also be demonstrated by organizations of large size. The fundamental properties of agility itself are the same at small scale as at large (definitionally).
    2. The process by which you achieve agility at a small scale and by which you achieve it at a large scale are not the same. Achieving large-scale agility is not a matter of simply doing “more” of what you do to achieve it at small scale: it requires different approaches entirely. The process of getting to large-scale agility has a difference of kind, not just degree, with the process of getting to small-scale agility.

    So I willingly risk being pilloried for my silly misunderstanding here; fire away if I’ve gone astray, but I start with an assumption that if *I’m* confused, it’s not implausible that our clients might be too, so willing to play the Dumb Interviewer asking leading questions where it might help…

    -Rob

    From: James Sutton
    Sent: Thursday, August 25, 2016 10:27 AM
    To: Al Shalloway ; DL NO Consultants Cc: Rob Neppell ; Mike Shalloway
    Subject: RE: request for feedback

    Hi, Max

    The operative phrase in your email is “without modifying it.” I did not say that. I said (or meant to say, at least), that there are two orientations: one is “scaling,” which is about looking for ways to expand what you’ve done on a small scale practically without limit. The other orientation is to find synergies that work at the larger scope…which doesn’t preclude tapping into things that worked at small scope, but it doesn’t start with the mentality of blowing up the micro into the macro.

    Finding synergies is congruent with complexity and systems thinking. “Scaling” is not.

    Amir, you’ve captured the difference and confusion between the two uses of the root word “scale” quite well. This confusion is widespread in our industry. Avoiding the potential for it is why I personally avoid the use of “scale” pretty much altogether.

    For anyone who’s interested, here’s a draft version of my blog post in which I talk about why scaling doesn’t work:

    Scaling – The Illusion
    https://1drv.ms/u/s!ArcMYkz9Fwzkgjgo7PwXnEMai8aA?wd=target%28Marketing%2FBlogs.one%7C39CF9AA9-2817-47B6-87FA-5E79E4CEA540%2FScaling%20-%20The%20Illusion%7C6B260474-847D-405B-BF6F-76E9CFAC4D91%2F%29
    onenote:https://d.docs.live.net/e40c17fd4c620cb7/Notebooks/NetO%20Collaboration/Marketing/Blogs.one#Scaling%20-%20The%20Illusion&section-id={39CF9AA9-2817-47B6-87FA-5E79E4CEA540}&page-id={6B260474-847D-405B-BF6F-76E9CFAC4D91}&end

    From: Max Guernsey
    Sent: Thursday, August 25, 2016 10:02 AM
    To: James Sutton ; Al Shalloway ; DL NO Consultants Cc: Rob Neppell ; Mike Shalloway
    Subject: RE: request for feedback

    There is scale, the place (as you said), and to scale, the verb, (as you said). There is also scalability, the adjective (or some kind of property).
    To scale does not imply keeping things the same but making them bigger – at least, not on the technical side. Instead, it implies that you have or get the appropriate amount of scalability to scale up to the scale you need.
    You can either do that by adding speculative scalability it by adding it just in time.
    Is that not true on the business side? Do people really mean “blow up a process without modifying it”?
    Get Outlook for Android
    ________________________________________
    From: James Sutton
    Sent: Thursday, August 25, 2016 9:56:40 AM
    To: Al Shalloway; DL NO Consultants
    Cc: Rob Neppell; Mike Shalloway
    Subject: RE: request for feedback

    I’m sure we believe the same thing.

    The confusion I see is that the word “scale” is used in two ways: One is as a synonym for “big.” The other is as an approach for taking something small and pumping it up to serve a much broader scope than that for which it was originally designed. Like “team Scrum” into “big-org Scrum.” LeSS would be perhaps the most clear example I know of the latter. (Not that LeSS can’t work in some contexts…just not as a general “solution” to “scaling Agile”.

    I know we at Net Objectives can do Agile in the first sense, on really big organizations. This requires, of course, our working in context of Lean and Systems Thinking (I’m convinced that Agile alone does not “scale” in general in the second sense), on which we have a strong mastery.

    Most people seem to use the word “scale” in the second sense though. That is what I disagree with. Rather than trying to “pump up” something that worked in small situations, I think applying the principles of Lean and Systems Thinking (e.g., through the filter of our Guardrails) gives automatic suiting to the scope of the organization doing the application. Their attention, then, is on their specific situation and needs, rather than “how to make Scrum ten times as big.” And so forth.

    To sum up, I disagree with the second use of “scale” (“pumping up”). And I avoid the first use of it because of the confusion between the two definitions. When I talk about size, whether large or small, I normally just say “scope” or “size.” Not “scale.”

    Does that address your question though?

    Jim

    From: Al Shalloway
    Sent: Thursday, August 25, 2016 9:24 AM
    To: James Sutton ; DL NO Consultants Cc: Rob Neppell ; Mike Shalloway
    Subject: RE: request for feedback

    Did you mean to imply that we no longer believe we can do Agile at scale? Can you elaborate?
    (actually I think you said that explicitly). I still believe we can.

    Al Shalloway, CEO
    425-269-8991. SPCT
    @alshalloway

    From: James Sutton
    Sent: Thursday, August 25, 2016 6:18 AM
    To: Al Shalloway ; DL NO Consultants Cc: Rob Neppell ; Mike Shalloway
    Subject: RE: request for feedback

    Good caveats. I totally agree about designing for value to the client, not for principles.

    I think our value to the client now is that we give them an algorithm for finding their own best path in their situation, regardless of their size. Inflection Points automatically adjust to the size of the organization (with a few caveats I realize). A large organization will tend to choose the “lily pads” that make the most sense for their size…as will a small one. Different lily pads, but same general kind of journey.

    The fact that we can help the client do this is a more powerful value proposition than are claims that we can scale up Lean or Agile for big organizations…something we no longer even really believe in (hence, our development of Inflection Points etc.), though old habits of speaking die hard.

    Max’s suggested name resonates for me. Add in our “secret sauce,” and I think a name that works and even invokes a sense of mystery and adventure (always attractive) might be:

    Journey to Effective Software Development, or

    Effective Software Development: The Journey

    Or perhaps, since the word “discovery” is also very powerful and it too reflects what we help people do, something like

    “Discovering Your Own Most-Effective Software Development”

    Or tapping into the “Walking Into” metaphor. You get the idea.

    Jim

    From: Al Shalloway
    Sent: Wednesday, August 24, 2016 11:32 PM
    To: James Sutton ; DL NO Consultants Cc: Rob Neppell ; Mike Shalloway
    Subject: RE: request for feedback

    Good points.

    To be clear I wasn’t talking about our branding – I was talking about the lean-agile course.
    The question is who is the course designed for – basically for larger organizations and therefore “at scale” However, I ike your thoughts and maybe the course should be designed around what’s possible at all scales.

    It is important when we design a course we have to design it around the value to the client – not the technique in used. Max suggested that we call the course Effective Software Development instead of Lean-Agile. Effective Software Develoment at Scale is different from Effective Software Development in smaller companies.

    The size of the development organization affects the practices to be used.
    I can see doing an effective software development where you have different segments for different sizes.

    I don’t see doing a course on just the principles – not a big enough market and not what people are looking for.

    Al Shalloway, CEO
    425-269-8991. SPCT
    @alshalloway

    From: James Sutton
    Sent: Wednesday, August 24, 2016 6:53 PM
    To: Al Shalloway ; DL NO Consultants Cc: Rob Neppell ; Mike Shalloway
    Subject: RE: request for feedback

    I have some reservations about branding us around scale.

    I realize that “at scale” is a popular phrase right now. The reality is, every single technique we (or anyone else) can use has a limited scope of application. The blog post I drafted last week gave the reason why “scaling” doesn’t work…the principle of hormesis. (I’m re-writing the blog and will have it out shortly for those who haven’t seen it yet.)

    Anything significant that one wants to do requires a system of elements whose synergy for the mission at hand provides the needed scope. Rather than upsizing or “scaling” anything. Just as an airplane is a collection of specialized parts that work together to achieve something greater than their sum, and doesn’t scale the fewer, simpler parts of the much-simpler model airplane.

    SAI has very effectively branded around scale…though even they don’t actually “scale.” They just have their own generic collection of pieces that they claim works for all software organizations pretty much regardless of context.

    I think we risk undercutting our powerful message about context-driven incremental improvement of the organization using Inflection Points and Guardrails if we followed SAI’s suit. It would put ourselves back into the same category as SAFe…with danger of being seen in the industry as an “also-ran” to SAI for branding territory they have already effectively staked out.

    From: Al Shalloway
    Sent: Wednesday, August 24, 2016 6:06 PM
    To: DL NO Consultants Cc: Rob Neppell ; Mike Shalloway
    Subject: request for feedback

    As most of you know we’ve been a bit coy in how we talk about SAFe so as not to antagonize the SAI.
    While we will still be respectful I am going to be discussing more of what we do (with SAFe or not).

    I have also announced a Lean-Agile online course that starts next month. In thinking about this shift of discussing what we do as well as the more pragmatic approach I’ve been trying to take it occurs to me that giving the Lean-Agile course more of a flavor of Lean-Agile at Scale may be better received and a better vehicle for us to promote what we do. In other words, people don’t really care about Lean-Agile per se, rather, what can they do with it.

    When this was originally designed I had intended it to be pragmatic but now see that there is still a lead with theory. I’m thinking I should change the design to be basically how we do lean-agile at scale. This shifts the course from being one on general Lean-Agile software to how we do it at scale. Since no one has registered for it yet – we can do this.

    Thoughts?

    Al Shalloway, CEO
    425-269-8991. SPCT
    @alshalloway

    • This topic was modified 3 years ago by  James Trott.
    • This topic was modified 3 years ago by  James Trott.
    • This topic was modified 3 years ago by  James Trott.
    • This topic was modified 2 years, 12 months ago by  James Trott.
    #27820

    Max Guernsey
    Keymaster

    Alistair’s article seems to address part of what this discussion is about.

    http://alistair.cockburn.us/Methodology+per+project

    #27840

    James Trott
    Keymaster

    It’s pretty safe to say that “Agile at scale” is an overloaded term. I’ve heard it used to mean several things, often more than one at the same time:

    1. Doing Agile in a large, complex organization.
    2. Doing Agile in a large, complex project.
    3. Expanding the number of Agile teams.
    4. Integrating Agile teams into the rest of the value stream.
    5. Re-forming the value stream to work better with Agile teams.
    6. Standardizing the Agile formula across teams.
    7. Leveraging Agile to become better at innovation.

    Obviously, any term with this many connotations is going to create confusion, and not just in academic conversations. In the most practical sense, people in the same organization will be working to solve different problems.

    Here’s another deficiency of the concept: some of these problems are extremely prosaic, while others are vast. Doing Agile in a large, complex project isn’t easy, especially at the beginning. However, it lends itself to fairly straightforward solutions. The mutual accommodations that Agile teams and the value streams are a much different matter.

    Ultimately, “Agile at scale” should aspire to address the final item on the list, getting better at innovation. (“If you’re going to take Vienna, take Vienna.”) That’s where the marriage of Lean and Agile is crucial. Agile doesn’t really provide any way of assessing whether you are getting better at innovation, in the Everett Rogers sense of the word. Agile creates the preconditions for being a better innovator, but you need some way of assessing the value created for consumers and producers of technology. You also need to apply the results of that assessment to the larger value stream, not just the team. For example, if you keep seeing problems rooted in the very definition of a product or project, the team may have very little control over that initial definition. Lean helps enormously in that situation, identifying the problems with project/product definition as sources of waste and obstacles to flow, among other bad consequences.

    P.S. I have a nagging feeling that I’ve forgotten a couple of connotations of “Agile at scale.” That’s another knock on the term, if it’s hard to recall all of its potential meanings.

    #27847

    Al Test
    Participant

    One thing I’ll add is that we’re using the same word to man two things, which doesn’t help things stay clear.

    “Agile” is a method, with a range of practices that can be specified, as well as principles those practices are based on. “Agile” is also a descriptor – an adjective that describes an ability – which may come from those principles or practices…or may not.

    #27848

    Max Guernsey
    Keymaster

    I think I agree. It feels like that declaration needs expansion.

    Is there an implied “and it’s not always clear which one someone means” or something?

    What’s our action for knowing this?

    • Be cognizant of it?
    • Identify and share a set of tripwires that we can use to detect when someone is using the wrong definition?
    • Have an alternative term locked and loaded for when an organization is deeply anchored in the wrong definition?
    #27854

    James Trott
    Keymaster

    Yet another indication that things do not scale is the abysmal record of “pilot projects.” Just because something works on a small scope does not mean much about it working on a large scope. Even if the idea is that a pilot project will be duplicated across multiple other such projects to the benefit of a whole program or value stream…systems thinking tells us that building a bunch of pieces (even *good* pieces) and sticking them together tells us little about how well or even whether the whole system afterwards will work.

    Rather than thinking in terms of “scaling up,” the only accurate way to think about building large working systems is finding the route to synergy. Things like Inflection Points, Lean-Startups, and sense-making all have a lot more to do with building successful systems (/organizations) than “scaling up” something little to work on something really big.

    I hope we will leverage that distinctive…because it truly is a distinctive; perhaps our greatest one (besides the wealth of great thinker/doers on our team).

    If it doesn’t hurt us marketing-wise, I’d love to see us make more of a point about this distinctive. As of now it is implicit in what we say about Inflection Points (primarily). Making our “discovering synergy, incrementally” distinctive an explicit message could be an exciting flare on the marketing horizon. As well as a possible flashpoint for SAI of course…

    • This reply was modified 3 years ago by  James Trott.
    #27859

    Al Test
    Participant

    I agree the distinction between “scaling up” and “synergy” is key – both for our customers and because improving synergy is at the core of our approach (which is because it is best for our customers).

    #28293

    Max Guernsey
    Keymaster

    “Discovering Synergy, Incrementally” sounds like the title of a blog entry, webinar, or Dr. Is In session…

    #28294

    Max Guernsey
    Keymaster

    …although maybe without the comma.

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.