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

Prerequisites for Agility (was Blog Entry - Call it what it is!)

Expand Messages
  • Dave Rooney
    ... Agreed. The Criteria I listed are intended to be provocative or evocative in order to provide a basis for discussion. For an adoption exercise, if I were
    Message 1 of 39 , Sep 26, 2008
      Steven Gordon wrote:
      > From my point of view the prerequisites for agility are not specific
      > practices. The simplest prerequisite is good faith agreement to
      > clearly stated responsibilities (and authorities to meet those
      > responsibilities) of the customers, developers, stakeholders and
      > management. If each party agrees in good faith to meet those
      > responsibilities and to respect the authorities of the other parties,
      > all the practices follow.

      Agreed. The Criteria I listed are intended to be provocative or
      evocative in order to provide a basis for discussion. For an adoption
      exercise, if I were to be wishy-washy and tell the client that daily
      business involvement or team co-location were important, but we can get
      away without them, the effort is doomed from the start. If I say that
      certain practices are mandatory, it forces the people to look at why
      they aren't doing those things now.

      > Indicating the types of practices that have worked for other
      > organizations is useful in helping these parties understand what they
      > are agreeing to and seeing that it is feasible to make agility work.
      > However, dictating the exact practices violates the above authorities.

      Shu-ha-ri. They have to at least pass "shu" before it becomes a

      Having said that, at my current client I didn't present them with
      "Extreme Programming", but rather used the generic name "Agile Software
      Development". I presented the XP practices but, for example, changed
      the concept of Pair Programming to "Code Oversight". I described why
      oversight is good, and said that it could be accomplished using formal
      code reviews, peer review prior to committing to source control, or Pair
      Programming. Without any further intervention on my part, the
      developers used pairing for a good 50-60% of the time. The rest of the
      time they used peer review. They accomplished the goal of code
      oversight in an adequately "agile" manner without having to be sold on
      Pair Programming.

      > In the short run, dictating the specific practices does provide a jump
      > start. In the long run, if these parties have not done the ground
      > work themselves to figure out what they need to do to meet their
      > responsibilities in their context, they will not have the process
      > ownership and the practice at reflection and self-improvement
      > necessary to stay on an agile path.

      Yup, with you 100% - this is exactly what I'm doing.

      > This is why I believe starting with Scrum and coaching teams to evolve
      > into XP is far more effective agile adoption program than starting
      > with XP.

      Interesting - I was just about swatted by David H. the other day for
      suggesting that Scrum was an "entry-level" agile process, but that's
      exactly what you're saying. I do have issues, for instance, with
      allowing a team in this situation to reap some initial benefits while
      continuing to pile up charges on the Technical Debt credit card. If, as
      a coach, you already know of a better way for them to work, to me it
      borders on the unethical if you don't tell them about it.

      Have you honestly seen teams that successfully adopted Scrum but
      wouldn't have been able to adopt all or most of XP from the start? Or
      is it a case where the XP name and terminology are too "scary" or carry
      too much baggage?

      Dave Rooney
      Mayford Technologies
      "Helping you become AGILE... to SURVIVE and THRIVE!"
    • kentb
      Chris, Your summaries of my statements seems accurate, so as far as I can tell you are only wrong in thinking you are wrong :-) I was responding to a statement
      Message 39 of 39 , Sep 29, 2008

        Your summaries of my statements seems accurate, so as far as I can tell you
        are only wrong in thinking you are wrong :-)

        I was responding to a statement something like, "Not using TDD is risky
        behavior." My (summarized) response was, "But many companies don't want what
        TDD can deliver and don't have experience with it, so from their perspective
        adopting TDD is the risky behavior."

        I try to be careful about dogmatic statements, having peddled so many of
        them in the past. That's what I was really responding to. There is a context
        in which adopting TDD is risky. There is another context in which not
        adopting TDD is risky. There is a huge, interesting middle ground where it
        could break either way. Oh, and time can change the contexts one to the

        Does this clarify the conversation for you?


        Kent Beck
        Three Rivers Institute


        From: extremeprogramming@yahoogroups.com
        [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Chris Wheeler
        Sent: Saturday, September 27, 2008 12:26 PM
        To: extremeprogramming@yahoogroups.com
        Subject: Re: [XP] Blog Entry - Call it what it is!

        On Fri, Sep 26, 2008 at 9:00 PM, kentb <kentb@earthlink.
        <mailto:kentb%40earthlink.net> net> wrote:

        > The thing I see is that many organizations don't see the need for the kind
        > of confidence that TDD can produce. They spend less developer time on
        > quality but still get satisfactory results. For such an organization,
        > adopting TDD would be risky--they would be investing without the
        > expectation
        > of return.

        I'm having trouble getting the meaning of this statement. First, if an
        organization doesn't see the need for the kind of confidence TDD can
        produce, does that mean that the organization can't see the need because
        they don't have that need, or does it mean that they are blind to the fact
        that they need it?

        Also, spending less developer and getting satisfactory results sounds pretty
        good to me. So, I'm really perplexed: if there is no necessary or
        demonstrable gain, why would we expect an investment in something that has
        no expectation of return?

        > I believe that better overall throughput is possible by shifting
        > in quality to the developers, but again, many organizations don't see the
        > need for better overall throughput. Again, for such an organization,
        > adopting TDD is the risky position.

        Once again, same question - if an organization doesn't see the need for
        better throughput, then why would it try to increase throughput? Also, is
        better throughput always necessary? What if my throughput already satisfies
        customers, and increasing throughput would not increase sales? In this
        light, investing in something with no demonstrable gain makes no sense.

        > I wish that software development and software developers had higher
        > aspirations, but I can't force that to happen, only hold them myself and
        > try
        > to support others who do as well.

        Now this is an interesting statement, something that I've thought about
        recently. My wife is taking a course about the history and purposes of adult
        education. Something that she has been reading and writing about is the
        shift in motivation to educate oneself. In the past century, education has
        shifted from something that one does to better oneself and one's social
        circle to something one does to make oneself more useful to an economic end.

        Nowadays, companies have influence on what a person learns, but rarely can a
        company control someone's aspirations. Thus, it makes sense to me that there
        are lot of programmers out there who are not only in the business because it
        made economic sense, but are also actively pursuing ongoing education to
        satisfy the demands of their employers so that they can pursue higher
        rewards. But, they may aspire to things that are altogether different than
        building high quality software because, to an extent, their hearts aren't in

        I, for instance, like programming, and will fiddle in just about any
        language. But I am interested in XP and agile because my company got
        interested in it. I have no aspiration to build really great software: I do
        that mainly because my employer needs to sell good software and I need to
        build it for them and I'm decent at it. Rather, I aspire to study philosophy
        and literature and write something of substance one day. I also aspire to
        artistic expression and am trying to explore the things that will let me do

        So, I'm not so surprised that great software is the aspiration of most
        software developers.


        [Non-text portions of this message have been removed]

        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.