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

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

Expand Messages
  • Curt Coulter
    ... released to customers, 100% code coverage with well written unit tests, automated acceptance/regression test suite is completed before release, and the
    Message 1 of 10 , Jan 7, 2011
      On Fri, Jan 7, 2011 at 11:49 PM, Tim Ottinger <linux_tim@...> wrote:
      >
      > Okay, here goes my jab at the dark side:
      > .snip.
      > The other problem is that naive managers try to push velocity, which is the
      >
      > wrong way to go. Simply putting pressure on velocity will drive developers
      > to
      > cut corners and release messy, incomplete, partially-tested code. Instead
      > of
      > pushing velocity they need to increase capacity of the team or the
      > workability
      > of the system. It is a different way of thinking.
      >
      > Bingo. The velocity is what it is. My metrics are more like zero bugs
      released to customers, 100% code coverage with well written unit tests,
      automated acceptance/regression test suite is completed before release, and
      the lowest possible number of stories test failed by QA on the first pass.

      /Curt


      [Non-text portions of this message have been removed]
    • MarvinToll.com
      Esther, One of the challenges with implementing Agile is the natural tension between the self-organizing team and Enterprise Application
      Message 2 of 10 , Jan 8, 2011
        Esther,

        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."

        _Marvin

        --- In extremeprogramming@yahoogroups.com, Esther Schindler <esther@...> wrote:
        >
        >
        > In short: As an Agile developer, what do you find is different, and difficult, about moving from older paths such as waterfall?
        >
        > Please don't interpret this as though it's meant to be negative about Agile. Quite to the contrary: This is meant to help people make a transition to Agile and, in so doing, understand where they're most likely to trip. We're looking for the answer to, "Where are the bodies buried?"
        >
        > Esther Schindler
        > twtiter.com/estherschindler
      • M. Manca
        Il 08/01/2011 13.57, MarvinToll.com ha scritto: I can suggest to write an article about agile used internally and for consulting using fixed rate contracts.
        Message 3 of 10 , Jan 8, 2011
          Il 08/01/2011 13.57, MarvinToll.com ha scritto:
          I can suggest to write an article about agile used internally and for
          consulting using fixed rate contracts. This is the bigger challenge that
          will help agile adoption.
          Personally for me works better a scrum development cycle using a
          different approach to define initial product backlog and using this
          backlog to make an early estimate (size, effort, cost) using an interval
          prediction scheme. But most of agile purist say me that this is not
          agile at all. For me, best of all it works and it work better then
          before when I used PSP/TSP but this has no meaning from a pure agile
          perspective.
          >
          >
          > Esther,
          >
          > 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."
          >
          > _Marvin
          >
          > --- In extremeprogramming@yahoogroups.com
          > <mailto:extremeprogramming%40yahoogroups.com>, Esther Schindler
          > <esther@...> wrote:
          > >
          > >
          > > In short: As an Agile developer, what do you find is different, and
          > difficult, about moving from older paths such as waterfall?
          > >
          > > Please don't interpret this as though it's meant to be negative
          > about Agile. Quite to the contrary: This is meant to help people make
          > a transition to Agile and, in so doing, understand where they're most
          > likely to trip. We're looking for the answer to, "Where are the bodies
          > buried?"
          > >
          > > Esther Schindler
          > > twtiter.com/estherschindler
          >
          >



          [Non-text portions of this message have been removed]
        • 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 4 of 10 , Jan 8, 2011
            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 5 of 10 , Jan 9, 2011
              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 6 of 10 , Jan 9, 2011
                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 7 of 10 , Jan 9, 2011
                  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.