Loading ...
Sorry, an error occurred while loading the content.

Re: Complex Adaptive Systems and Lean Software Development

Expand Messages
  • PAUL
    Hi Paul, That was very useful. Thanks. Paul.
    Message 1 of 84 , Oct 6, 2009
      Hi Paul,

      That was very useful. Thanks.


      --- In leanagile@yahoogroups.com, "pauloldfield1" <PaulOldfield1@...> wrote:
      > (responding to PAUL)
      > I'll give you a few of my views on the matter. I
      > hope they are of use.
      > > > So, when folk talk about Lean Software Development,
      > > > are they talking about being, explaining, or following
      > > > Lean Software Development?
      > >
      > > Good questions. I've been asking these questions for over
      > > a year. On the Kanbandev forum, I got various answers.
      > > From the practitioners (Rob Hathaway?), the answer I got
      > > was that they used Kanban is a wrapper around traditional
      > > Agile (XP). This fits with the toolbox idea, and Lean
      > > Software Development as a Management/Culture/Learning
      > > building tool. It also concurs with what I hear from Mary.
      > "I have seen the Elephant and it is like a rope" - We
      > each latch on to the bits that make sense in our context.
      > I can't say I have the whole picture, but my bits might
      > help.
      > > Alan and David on the other hand appear to be saying
      > > something else, and see Lean not just augmenting Agile
      > > (extending into Management and enterprise wide concerns
      > > like promoting a learning culture), but replacing it.
      > > The idea I get is that Agile is some how flawed and needs
      > > to be placed on a solid scientific foundation, which can
      > > only come from Lean because Lean as defined by Deming 40
      > > odd years ago is the theory of everything.
      > >
      > > I strongly disagree with this second definition.
      > "I have seen the Elephant and it is like a wall" - I think
      > I understand where Alan is coming from. Is that a bug in
      > Agile, or is it a feature? Depends where you are standing.
      > One of the features of Agile is that it is empirical. We
      > tried things and kept the ones that worked well. Is that
      > a bug in Agile, or is it a feature? Agile still has all
      > the value it has.
      > For some people, it is a big step forward that we now have
      > a theory that can explain the empirical results that have
      > accrued over the years. It is like shining a bright light
      > on what was a twilight world. It opens up so many
      > possibilities. It is hard not to go round shouting "Eureka!"
      > For others, the theory makes little or no difference; Agile
      > still works today as it did yesterday, and as it will
      > tomorrow. Do I need to learn all that stuff? Worse; are
      > you trying to tell me I've been thinking the wrong way
      > all this time?
      > > With Mary's definition, there is a definitive text, and
      > > she seldom criticises Agile/Scrum, so I'm very clear about
      > > what she is saying.
      > I hear one criticism from Mary, and she doesn't voice that
      > often. However, this is where the feature of Agile may be
      > seen as a bug.
      > You may not agree with my reasoning, so I'll try to make
      > it clear while succinct.
      > We already know that the value of individual practices and
      > techniques is very dependent on the context. We already
      > know that there are many practices that people have used
      > and found to work. Because Agile is empirical, we don't
      > know why practices work in certain contexts; they just work.
      > As an outcome, there is a strong drive to get to the same,
      > ideal context in which the largest body of Agile practices
      > work.
      > One of the outcomes of this drive toward the ideal context
      > is the isolation of the Agile team from non-ideal aspects
      > of the context that are difficult or impossible to change.
      > I hope I am not misrepresenting Mary when I say she would
      > find this isolation of the team to be a bad outcome.
      > It might be that some people would go as far as to say this
      > is a bug in Agile. They are particularly likely to say this
      > if they have to hand a theory that should allow the bug to
      > be fixed.
      > > With Lean/Kanban there is no text, David as been promising
      > > a book for a while. There is a Scrumban book, but the
      > > author appears to have fallen out with David, and that
      > > book isn't seen as the definitive reference on Lean/Kanban.
      > It's interesting that you feel the need for a Definitive
      > Reference. I'd rather hear more about how the ideas fit
      > with one another; how the various needs get met. I think
      > 'absolutes' and 'definitives' are of less use, but maybe
      > I'm looking at a different bit of the Elephant.
      > > So we are left with people critiquing Agile and providing
      > > no clear definitive reference to what they intend to
      > > replace Agile with.
      > I doubt there was any call to replace Agile, though I can
      > understand they may want to fix the bit they see as
      > giving problems. What you'd get would be mostly Agile
      > but better. Of course, "better" depends on one's values.
      > > > I think I understand the difference...
      > >
      > > I'm glad you do. I sense that Alan in particular is talking
      > > at an higher level of abstraction, above the team level.
      > > Here I agree that Lean provides an extremely powerful
      > > Leadership model. Unfortunately Alan disagrees strongly
      > > with this summary. So I am as confused as ever.
      > >
      > > If you understand, then please explain. I'm sure that I can't
      > > be the only one who is confused.
      > Well, there's my take on it. I hope it serves more to
      > enlighten than to confuse. It won't explain everything,
      > but hopefully it's a start.
      > Paul Oldfield
      > Capgemini
    • mark_kennaley
      So I noticed this thread and it caught my attention. Seems like a topic we have stood up a blog on called SDLC 3.0 . www.fourth-medium.com/wordpress
      Message 84 of 84 , Oct 6, 2009
        So I noticed this thread and it caught my attention. Seems like a topic we have stood up a blog on called "SDLC 3.0".


        Specifically, two things strike me about the back and forth of this thread: one is the us-vs-them, this-vs-that kind of discussion. Our take is practice=pattern="solution to a problem in context". To assume that each of the camps (XP/Scrum – Chrysler/Dupont), Lean or even the Unified Process considered all contexts magically and statically at a point of time some time back without continual learning is silly. SDLC 3.0 believes all is required in context.

        Specifically, Agile is a brand and a lobby, which did much to help kill the misinterpretation of the serial, single pass I-Plant waterfall articulation from Winston Royce. But most principles come from other places – in explicit form, whether it be USMC, Theory Y management – and thankfully these are being popularized through the Agile community. Some like Kanban are even claimed under the Agile umbrella, even though JIT and pull go much further back, even further than the coined term "Lean" from Womack and Jones; and Product Backlog management is analogous to terms like fine-grained demand management, ALM, and Digital Kanban (yes Toyota no longer uses the physical form).

        But the topic of Complex Adaptive Systems - this is key; as negative feedback is the common thread among modern software engineering communities. And the body of knowledge of PID control and the evolution of the System Dynamics work of Jay Forrester should serve to take software engineering to the next level. Beyond the "trough of disillusionment" as Gartner says. We must go beyond a tacit understanding of Agile, and we must stop this method war nonsense and ground ourselves in CAS, real options theory, queuing theory and the like if we are to evolve and produce results for the business value-stream.

        I note in the original post there are a number of prima-facia assumptions regarding the application of Lean and its inappropriateness to Software Engineering. But if you look at works exploring how to discover critical WIP, they are exploring PID control theory and ODE's/Laplace transforms as the mathematical model. And as far as the notion of pull and flow being prescriptive or orderly or manufacturing like – if you embrace CAS theory and think of a software development organization as a highly dynamic system best described by an nth order differiential equation (the plant), then one might be able to make the argument of single piece flow vs batched iterations as affecting the Nyquist stability criterion? I am wondering if Jim Highsmith covered this metaphor or body of knowledge in his book, as I know he holds an Electrical Engineering degree (as do I).

        Mark Kennaley
        President, Principal Consultant
        Fourth Medium Consulting Inc.

        --- In leanagile@yahoogroups.com, Pablo Emanuel <pablo.emanuel@...> wrote:
        > Alan,
        > sure.
        > ----
        > Alan,
        > there are some practical principles I inferred from CASs that I use in my
        > day-to-day work. I divide them in two categories:
        > Dealing with CASs (usually large groups such as companies, big departments,
        > cities, countries, etc):
        > - CASs have homeostasis, and move through jumps - it doesn't help to try
        > to push a CAS little by little, either you cause an avalanche or they'll
        > stay where they are.
        > - CASs won't react linearly. Sometimes the best way with CASs is to act
        > on the effects, not on the causes (since there's so much feedback going on).
        > It's the technique of forcing a smile to actually get happier.
        > - CASs doesn't have a natural scale, i.e., sometimes you have to act
        > globally, sometimes you have to act on the detail to get the result you
        > want.
        > Inducing on systems the good features of CASs:
        > - Short and abundant feedback loops
        > - To achieve robust efficiency, CASs must have:
        > - Redundancy: Each feedback loop must have a secondary feedback loop,
        > no individual can be irreplaceable, etc
        > - Variability: The distributions must have fat tails, instead of focus
        > on just what happens to be optimal right now, allow for some different
        > sub-optimal behaviour to exist, which must be exactly what you
        > need in the
        > future. For instance, new ideas must have room to grow, parallel projects
        > must be allowed to drain a small percentage of the resources,
        > people should
        > be trained in skills other than the ones you need now.
        > In general, I agree with you. Lean is a set of principles that translate
        > very directly to a set of tools that give measurable results. CAS theory can
        > give you insight, but it's definitely not a roadmap, so, comparing CAS and
        > Lean is indeed comparing apples and oranges.
        > Regards,
        > Pablo Emanuel
        > 2009/10/6 alshalloway <alshall@...>
        > > Pablo:
        > > I just read your comment you posted on our website
        > > (http://tinyurl.com/y8rcxq6 ). That was extremely helpful to me to
        > > understand the value of CAS. If you don't mind, could you post that here?
        > > It may help others get some value from this conversation.
        > >
        > > Thanks,
        > >
        > > Alan Shalloway
        > > CEO, Net Objectives
        > > Achieving Enterprise and Team Agility
        > >
        > >
        > >
        > > ------------------------------------
        > >
        > > Yahoo! Groups Links
        > >
        > >
        > >
        > >
      Your message has been successfully submitted and would be delivered to recipients shortly.