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

Help a journalist on an article about Agile in the real world

Expand Messages
  • Esther Schindler
    As some of you know, I have a new (part time) gig as editor in chief of a new site for software developers and testers. (Yay me!) The site won t go live until
    Message 1 of 10 , Jan 6, 2011
    • 0 Attachment
      As some of you know, I have a new (part time) gig as editor in chief of a new site for software developers and testers. (Yay me!) The site won't go live until later this month, so I don't have a lot of info to share much less a URL. (We're hoping that the curtain will come up by February 1. Assuming that the developers get it done... <grin>)

      In the meantime, I have several writers working on articles that, I hope, fulfill the site's mission: "Stuff that developers and testers want to read." I like to think I have a decent track record at achieving that. <modest cough>

      You won't be surprised that Agile topics are among the first articles assigned.

      One of my writers, Steven Vaughan-Nichols, needs a little real-world input for his article, however, and I hope that you can share some of your experiences. (Be sure to cc sjvn@... as he isn't on this list.)

      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]
    • Tim Ottinger
      ... Esther, et al: The book/card/thing Jeff and I wrote should not be out until later this month, but we tackled the basics in three cards, the original
      Message 2 of 10 , Jan 6, 2011
      • 0 Attachment
        >
        > In short: As an Agile developer, what do you find is different, and difficult,
        >about moving from older paths such as waterfall?
        >


        Esther, et al:

        The book/card/thing Jeff and I wrote should not be out until later this month,
        but we tackled the basics in three cards,

        the original primitive versions being still on our AgileInAFlash website. This
        is real-world stuff, and may be helpful.

        http://agileinaflash.blogspot.com/2010/03/personal-objections-to-agile-process.html

        http://agileinaflash.blogspot.com/2010/02/organizational-objections-to-agile.html

        http://agileinaflash.blogspot.com/2010/07/agile-success-factors.html

        The first two are on objections which have some validity, and the latter is a
        set of success factors.

        All the problems with agile transition are people problems (paraphrasing
        Weinberg) but we hoped

        to show that the problems are at different levels of the organization, as are
        the solutions.



        Tim Ottinger
        http://agileinaflash.blogspot.com/
        http://agileotter.blogspot.com/
      • Tim Ottinger
        Okay, here goes my jab at the dark side: Sometimes organizational inertia and control issues get in the way. The largest problem is when management expects
        Message 3 of 10 , Jan 7, 2011
        • 0 Attachment
          Okay, here goes my jab at the dark side:


          Sometimes organizational inertia and control issues get in the way. The largest
          problem is when management expects that only the programmers need to change. The
          truth is that Agile development touches product management, customer contact,
          team management, deployment, and schedule management in a deep and significant
          way. Getting programmers to work in pairs, test-drive code, and refactor their
          systems is trivial compared to dropping individual assignments, reducing scope,
          minimizing work in progress, and connecting customers to development teams.

          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.

          Tim Ottinger
          http://agileinaflash.blogspot.com/
          http://agileotter.blogspot.com/
        • 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 4 of 10 , Jan 7, 2011
          • 0 Attachment
            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 5 of 10 , Jan 8, 2011
            • 0 Attachment
              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 6 of 10 , Jan 8, 2011
              • 0 Attachment
                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 7 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 8 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 9 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 10 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.