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

Re: [XP] Re: Help a journalist on an article about Agile in the real world

Expand Messages
  • Ron Jeffries
    Hello, Marvin. On Saturday, January 8, 2011, at 7:57:17 ... There are two dimensions entangled here. One is a principle of communication, with which I believe
    Message 1 of 10 , Jan 8, 2011
    • 0 Attachment
      Hello, Marvin. On Saturday, January 8, 2011, at 7:57:17
      AM, you wrote:

      > One of the challenges with implementing Agile is the natural
      > tension between the self-organizing team and Enterprise
      > Application Architecture/Design/Implementation direction.

      > We have sought to strike a balance by providing a tool for our
      > self- organizing teams as follows:

      > "Proven enterprise Architecture/Design/Implementation patterns
      > are effectively communicated when including working software
      > examples derived from a reference implementation."

      There are two dimensions entangled here. One is a principle of
      communication, with which I believe most would agree, namely that
      examples are a good way to teach. I believe this has been known for
      a long time, and that it probably does not rise to the level of the
      principles of the Agile Manifesto. Damn good idea, though.

      The other dimension is the notion of "Enterprise Application
      Architecture / Design / Implementation direction". This is a
      particular corporate style of solution to one or more problems that
      are usually not stated. The problems probably include application
      interoperability, hardware and software cost reduction,
      transferability of people talent, and perhaps more.

      Of these, only one actually addresses true product need, namely
      interoperability. The others are cost reduction concerns. They are
      still important, of course. All of these concerns, however, are
      capable of being addressed in other ways than imposition of
      approaches from the "Enterprise".

      (I note that you couch your principle not in terms of imposition,
      but of provision of information. That's good. The impact of this
      provision will be the adoption of the solution: that is the point.
      And the solution is not as "Agile" as it might be.)

      I believe that the Agile philosophy is generally not to impose
      solutions, but to require objectives to be met. In the SLE's case,
      these objectives would include interoperability and cost-related
      measures.

      There is a big difference, I believe, between saying

      "Here are some useful patterns. Use them." and

      "Here are some useful patterns. Keep your costs within this limit
      per feature, your code capable of being understood by others,
      measured such and so."

      One of those differences is that the latter is hard to do. We would
      have to actually pay attention to what we want and measure whether
      we get it. The opposite side of that coin, however, is that imposed
      architectures are presumed to be good but rarely do we set forth the
      supposed benefits and measure whether we are getting them. We just
      enforce.

      Because the two dimensions, communication and presumed solution of
      unstated problems, are mixed in your strategy, it is not possible to
      determine the extent to which it's about communication, which would
      be "good Agile", and the extent to which it is imposition of a
      solution, which would be "not so good".

      Having spent many hours with you, Marvin, I am confident of your
      good will. I do believe that there are likely to be some unwanted
      side effects from communicating with these patterns, namely the
      adoption of inferior solutions to the unstated but important
      objectives mentioned above.

      Now, that said, the specific people whom you are addressing with
      these patterns are not cream of the crop individuals who will
      self-organize and come up with amazing new valuable solutions.

      And that may well be the crux of your issue. Your enterprise choose
      not to create effective self-organized teams, but instead to recruit
      rank beginners from the streets. As such, those teams are not likely
      to be effective. I think we agree on that. The question is what
      should be done about it.

      One possibility, and I support it, is to educate these people as
      much as possible, and imbue them with approaches that, while perhaps
      not the best, are pretty sure to work. That's just fine, and as I've
      said many times, it might well be what I would do in your situation.

      However, that solution is emphatically not in line with Agile
      principles as I see them, which are about setting up good teams made
      up of good people, and giving them freedom. Your people are not very
      good, the teams will not be very good, and that's not what Agile's
      about.

      Teaching with examples is a great idea. It could be used in an Agile
      fashion, to help educate teams and improve information flow. It
      could also be used in a fashion that would preserve the old not so
      Agile status quo of imposed solutions from "above".

      Therefore, your "principle" is not, to me, a wonderful new Agile
      principle, but instead it provides a loophole through which an
      enterprise could say it was doing the Agile thing but in fact not be
      doing it at all.

      I could, of course, be entirely wrong. I am, however, at least
      consistent. :)

      Ron Jeffries
      www.XProgramming.com
      If you're not throwing some gravel once in a while,
      you're not using the whole road.
    • MarvinToll.com
      Ron, A couple of thoughts for your consideration: 1. You may notice that in my previous post our experience was not labeled as a Principle. This because I m
      Message 2 of 10 , Jan 9, 2011
      • 0 Attachment
        Ron,

        A couple of thoughts for your consideration:

        1. You may notice that in my previous post our experience was not labeled as a Principle. This because I'm getting more specific about our own enterprise emergence and less interested in trying to "Principlize" it. (I've got a post going on the Agile Alliance site looking for feedback on this issue - Principle vs. Practice.)

        2. You may notice the addition of the term "Proven". (Something like Principle #8 of the Toyota Way.) I'm now thinking perhaps Manifesto Principle #11 is better suited for 'unproven' (or 'one-off' or 'corner-case') Architecture/Design/Implementation patterns. Since we anecdotally (a code word for unmeasured) experience our teams using about 80% "proven" and 20% "unproven" we focus on the 80%. We really don't provide any unique guidance to teams with one-off solutions... unless they want to hire one of our internal Consultants to join with their team.

        Our Experience:
        > > "Proven enterprise Architecture/Design/Implementation patterns
        > > are effectively communicated when including working software
        > > examples derived from a reference implementation."

        So I'm (perhaps slowly) moving to a position of bifurcation. That is, there are different approaches to realizing 'Agility' for "proven" Architecture/Design/Implementation Patterns and "unproven". And perhaps my objection all along with Principle #11 is that I've found it less than useful for optimizing the (theoretical) 80% of what we do. Which or course means that it IS useful for (the again theoretical) 20% of what we do in the Architecture/Design/Implementation patterns space.

        _Marvin

        --- In extremeprogramming@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
        >
        > Hello, Marvin. On Saturday, January 8, 2011, at 7:57:17
        > AM, you wrote:
        >
        > > One of the challenges with implementing Agile is the natural
        > > tension between the self-organizing team and Enterprise
        > > Application Architecture/Design/Implementation direction.
        >
        > > We have sought to strike a balance by providing a tool for our
        > > self- organizing teams as follows:
        >
        > > "Proven enterprise Architecture/Design/Implementation patterns
        > > are effectively communicated when including working software
        > > examples derived from a reference implementation."
        >
        > There are two dimensions entangled here. One is a principle of
        > communication, with which I believe most would agree, namely that
        > examples are a good way to teach. I believe this has been known for
        > a long time, and that it probably does not rise to the level of the
        > principles of the Agile Manifesto. Damn good idea, though.
        >
        > The other dimension is the notion of "Enterprise Application
        > Architecture / Design / Implementation direction". This is a
        > particular corporate style of solution to one or more problems that
        > are usually not stated. The problems probably include application
        > interoperability, hardware and software cost reduction,
        > transferability of people talent, and perhaps more.
        >
        > Of these, only one actually addresses true product need, namely
        > interoperability. The others are cost reduction concerns. They are
        > still important, of course. All of these concerns, however, are
        > capable of being addressed in other ways than imposition of
        > approaches from the "Enterprise".
        >
        > (I note that you couch your principle not in terms of imposition,
        > but of provision of information. That's good. The impact of this
        > provision will be the adoption of the solution: that is the point.
        > And the solution is not as "Agile" as it might be.)
        >
        > I believe that the Agile philosophy is generally not to impose
        > solutions, but to require objectives to be met. In the SLE's case,
        > these objectives would include interoperability and cost-related
        > measures.
        >
        > There is a big difference, I believe, between saying
        >
        > "Here are some useful patterns. Use them." and
        >
        > "Here are some useful patterns. Keep your costs within this limit
        > per feature, your code capable of being understood by others,
        > measured such and so."
        >
        > One of those differences is that the latter is hard to do. We would
        > have to actually pay attention to what we want and measure whether
        > we get it. The opposite side of that coin, however, is that imposed
        > architectures are presumed to be good but rarely do we set forth the
        > supposed benefits and measure whether we are getting them. We just
        > enforce.
        >
        > Because the two dimensions, communication and presumed solution of
        > unstated problems, are mixed in your strategy, it is not possible to
        > determine the extent to which it's about communication, which would
        > be "good Agile", and the extent to which it is imposition of a
        > solution, which would be "not so good".
        >
        > Having spent many hours with you, Marvin, I am confident of your
        > good will. I do believe that there are likely to be some unwanted
        > side effects from communicating with these patterns, namely the
        > adoption of inferior solutions to the unstated but important
        > objectives mentioned above.
        >
        > Now, that said, the specific people whom you are addressing with
        > these patterns are not cream of the crop individuals who will
        > self-organize and come up with amazing new valuable solutions.
        >
        > And that may well be the crux of your issue. Your enterprise choose
        > not to create effective self-organized teams, but instead to recruit
        > rank beginners from the streets. As such, those teams are not likely
        > to be effective. I think we agree on that. The question is what
        > should be done about it.
        >
        > One possibility, and I support it, is to educate these people as
        > much as possible, and imbue them with approaches that, while perhaps
        > not the best, are pretty sure to work. That's just fine, and as I've
        > said many times, it might well be what I would do in your situation.
        >
        > However, that solution is emphatically not in line with Agile
        > principles as I see them, which are about setting up good teams made
        > up of good people, and giving them freedom. If people are not very
        > good, the teams will not be very good, and that's not what Agile's
        > about.
        >
        > Teaching with examples is a great idea. It could be used in an Agile
        > fashion, to help educate teams and improve information flow. It
        > could also be used in a fashion that would preserve the old not so
        > Agile status quo of imposed solutions from "above".
        >
        > Therefore, your "principle" is not, to me, a wonderful new Agile
        > principle, but instead it provides a loophole through which an
        > enterprise could say it was doing the Agile thing but in fact not be
        > doing it at all.
        >
        > I could, of course, be entirely wrong. I am, however, at least
        > consistent. :)
        >
        > Ron Jeffries
        > www.XProgramming.com
        > If you're not throwing some gravel once in a while,
        > you're not using the whole road.
        >
      • Ron Jeffries
        Hello, MarvinToll.com. On Sunday, January 9, 2011, at 7:55:00 AM, ... I ll reply to your specifics later, perhaps. This came to me as I read it. It seems to
        Message 3 of 10 , Jan 9, 2011
        • 0 Attachment
          Hello, MarvinToll.com. On Sunday, January 9, 2011, at 7:55:00 AM,
          you wrote:

          > A couple of thoughts for your consideration:

          I'll reply to your specifics later, perhaps. This came to me as I
          read it. It seems to me germane.

          Principle 11: The best architectures, requirements, and designs
          emerge from self-organizing teams.

          I suggest that

          P11 means that if you want to invent the best architecture for
          something, you should use a self-organizing team, not some other
          approach.

          I suggest that it does NOT mean that every self-organizing team
          invents the best architecture.

          I would think it would go without saying, but apparently it doesn't,
          that for a self-organizing team to produce a "best" architecture,
          they need to be very experienced and capable. How do they get that
          way? By experience (!) of good (and bad) architecture. How can we
          speed up their experience? Patterns.

          So I think that the patterns idea is a good one. I don't think it
          rises to the level of an Agile principle, in fact I don't see that
          it says much about agile one way or the other.

          Ron Jeffries
          www.XProgramming.com
          Speak the affirmative; emphasize your choice
          by utterly ignoring all that you reject. -- Ralph Waldo Emerson
        • MarvinToll.com
          Likewise... I ll just react with a single iteration... Perhaps if Principle #11 included the notion that: The best Architectures/Design/Implementation
          Message 4 of 10 , Jan 9, 2011
          • 0 Attachment
            Likewise... I'll just react with a single iteration...

            Perhaps if Principle #11 included the notion that:

            "The best Architectures/Design/Implementation patterns emerge from self-organizing teams and the Agile Enterprise figures out how to harvest and leverage that insight."

            Then... I agree with Principle #11. I've just never interpreted the Principle from that perspective.

            --- In extremeprogramming@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
            >
            > Hello, MarvinToll.com. On Sunday, January 9, 2011, at 7:55:00 AM,
            > you wrote:
            >
            > > A couple of thoughts for your consideration:
            >
            > I'll reply to your specifics later, perhaps. This came to me as I
            > read it. It seems to me germane.
            >
            > Principle 11: The best architectures, requirements, and designs
            > emerge from self-organizing teams.
            >
            > I suggest that
            >
            > P11 means that if you want to invent the best architecture for
            > something, you should use a self-organizing team, not some other
            > approach.
            >
            > I suggest that it does NOT mean that every self-organizing team
            > invents the best architecture.
            >
            > I would think it would go without saying, but apparently it doesn't,
            > that for a self-organizing team to produce a "best" architecture,
            > they need to be very experienced and capable. How do they get that
            > way? By experience (!) of good (and bad) architecture. How can we
            > speed up their experience? Patterns.
            >
            > So I think that the patterns idea is a good one. I don't think it
            > rises to the level of an Agile principle, in fact I don't see that
            > it says much about agile one way or the other.
            >
            > Ron Jeffries
            > www.XProgramming.com
            > Speak the affirmative; emphasize your choice
            > by utterly ignoring all that you reject. -- Ralph Waldo Emerson
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.