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

Re: [XP] Re: Scrum, and Revolution

Expand Messages
  • Leonardo Postacchini
    I would say that to call something by the proper name you must first be able to define the something, which I doubt is any consensus in the Agile community,
    Message 1 of 167 , Dec 18, 2012
    • 0 Attachment
      I would say that to call something by the proper name you must first be
      able to define the something, which I doubt is any consensus in the Agile
      community, just take Scrum as an example, if you are to be too strict,
      Scrum is a good start at agile, but is it Agile? I find Scrum very lacking
      when compared to XP, it gives a couple of guide lines but does not have the
      pratices for example, it is up to the team use TDD or not for example.

      Yet, it is this allowance to flexibility that makes it easier to be
      accepted by management people, it is not too much commitment, it is a
      smaller culture change. In the end TDD, CI etc end up creeping in the
      processes.

      My badly stated point is: the definition of what is Agile is not binary or,
      for what it is worth, clear. Instead of thinking of a project as Agile or
      not Agile at all, why not a little bit agile, a little bit more agile and
      so on?

      The same way waterfall have systems that are delivered or not delivered at
      all, we saw how that works, right? Delivering a bit each time is better
      than not delivering at all, becoming a bit agile at time is better than not
      becoming agile at all.

      I propose breaking Agile in small stories and go about implementing then
      one at time, testing them, seeing how they work, learning, fixing and going
      about new histories, in small incremental steps until you become "very
      agile". Sounds familiar?

      Instead of being boolean about it, using a discrete scale that goes on
      unbound, ever improving. At the end of the day the goal is: to be purist,
      shift the blame or get the work done?

      Calling things Fake Agile gets in the way of getting the work done because
      it scares people away of trying it out and adopting gradually to have
      security and avoid the blame for failure on Agile, does it align with the
      values of XP or any other Agile mindset?

      Once I had this mindset of: Either you go full XP or you are not XP at all.
      It simply does not work, few people have the courage to jump in head first
      and try it all at once. Most will say you can't do that and will actively
      damp your efforts.

      On top of that, as learned in biologic evolution, if you get a viable
      organism and mutate it too radically the odds are that it will produce
      something not viable, small mutations allow for viable organisms that can
      be selected on fitness until you have something quite different. With
      software if you mutate your process or the program itself in small steps
      you always end up with something workable and if you end up with something
      a little worse, you can always understand why that bit of change didn't
      work and fix it.


      On 18 December 2012 15:36, John Roth <JohnRoth1@...> wrote:

      > **
      >
      >
      > There's one of those Old Chinese Proverbs that may be due to Confucius:
      >
      > "The beginning of wisdom is to call things by their proper names."
      >
      > What name would you suggest to call something where the practitioners
      > are claiming to do something, but anyone who actually makes whatever it
      > is work can clearly see they're doing it wrong?
      >
      > John Roth
      >
      >
      > On 12/18/12 10:01 AM, Leonardo Postacchini wrote:
      > >
      > > I dislike the Idea that is implied by the term: Fake Agile, by stating
      > > such thing you are telling that there is a Right(tm) and a Wrong(tm)
      > > way of
      > > doing it, and that you know how it is. The way I see Agile, it is about
      > > always trying to review, understand, and improve on, you can only do that
      > > if you think there is the need and room to improvement.
      > >
      > > The term Fake Agile implies there is not. Besides that, being too pricky
      > > about how Truly Agile you are just scares people away and taints the
      > whole
      > > stuff with radicalism stigma. Agile is about small sure footed step
      > > progress why not applying that to adoption?
      > >
      > > A bit of Agile is better than not Agile at all, and if the project
      > failed,
      > > maybe it was Not Agile Enough.
      > >
      > > On 18 December 2012 14:45, RonJeffries <ronjeffries@...
      > > <mailto:ronjeffries%40acm.org>> wrote:
      > >
      > > > **
      >
      > > >
      > > >
      > > > Hi Charlie,
      > > >
      > > > Yes, we do know some good techniques (and values and principles),
      > > and they
      > > > do seem always to work if done correctly.
      > > >
      > > > (I note this is the True Scotsman fallacy but that doesn't mean it's
      > > > false.)
      > > >
      > > > Yes, there is resistance, and there isn't uptake everywhere. And yes,
      > we
      > > > can say we don't care about wider adoption. And maybe, borrowing a
      > > phrase
      > > > from JB, we really don't mind. Except, we do, most of us. Some of us
      > > mind
      > > > so much that we get out of the general helping business and get a
      > > job doing
      > > > the stuff. And more power to those folks. There's great honor in
      > > just doing
      > > > one's craft as well as one can.
      > > >
      > > > Except we do care, we do mind.
      > > >
      > > > I kind of resonate with the idea of calling out "Fake Agile". A concern
      > > > with that is that the people doing it are probably not overtly
      > > faking it.
      > > > Instead, they're probably doing their best with the hand they're dealt.
      > > > It's the damn Prime Directive again.
      > > >
      > > > And it certainly can't do much harm to keep making clear that you
      > > have to
      > > > put in the effort. At the same time, I feel absolutely sure that
      > > working in
      > > > the ways I have learned from XP, I have to put out less effort than
      > > I did
      > > > before. So that's odd.
      > > >
      > > > My seed note here was driven by the realization (belief) that the
      > > wave of
      > > > Agile/Scrum is flattening out, and that there is no real leadership
      > > of any
      > > > notable kind, either whipping up that wave, or starting a new one.
      > > Because
      > > > there was a wave, that says to me that there could be a wave.
      > > >
      > > > We surely can't bring the entire world around. We didn't bring the
      > > entire
      > > > world around the first time. We did manage to create, somehow, a
      > > bunch of
      > > > people who made noise and helped the world get to where it is now, and
      > I
      > > > think it is somewhat better now than before Agile.
      > > >
      > > > So it seems to me that there must be a thing that could be done that
      > > would
      > > > do it again. And I'd like that.
      > > >
      > > > Regards,
      > > >
      > > > Ron Jeffries
      > > > www.XProgramming.com
      > > > There's no word for accountability in Finnish.
      > > > Accountability is something that is left when responsibility has been
      > > > subtracted.
      > > > --Pasi Sahlberg
      > > >
      > > >
      > > > [Non-text portions of this message have been removed]
      > > >
      > > >
      > > >
      > >
      > > [Non-text portions of this message have been removed]
      > >
      > >
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Tom Rossen
      Rob, Thanks for your kind offer. I am currently gainfully employed - until Feb. 2, when my current contract runs out. Northern Trust renewed it as many times
      Message 167 of 167 , Dec 30, 2012
      • 0 Attachment
        Rob,

        Thanks for your kind offer. I am currently gainfully employed - until Feb.
        2, when my current contract runs out. Northern Trust renewed it as many
        times as they could, but there's a hard limit of 1.5 years.

        Re the high-performing teams: it's funny, but I really think I prefer
        working with an organization that's struggling with Agile. I'm extremely
        curious as to why XP practices, which seemed so obvious and satisfying when
        I first read Kent Beck's book years ago, are so frustrating for developers
        and managers who aren't used to them and didn't volunteer for them. I was
        rather seriously burned on my previous engagement when the company was
        acquired by a conglomerate and the policy of openness to Agile suddenly
        evaporated, so my insistence on TDD - which no longer seems as doomed as it
        would have been just a year ago, based on what I'm seeing now in the
        Chicago area - is protection against that sort of thing.

        So I'm curious about the high-performing teams you mention - at least in
        the Chicago area: I don't intend to relocate or commute a long distance (I
        worked in Madison, WI for several years after the dot-com-bomb wiped out
        the Chicago market - not a fun commute).

        Tom


        On Fri, Dec 28, 2012 at 2:30 PM, Rob Myers <rob.myers@...>wrote:

        > **
        >
        >
        > Tom,
        >
        > Thanks for the supportive reply!
        >
        >
        > > 35 years in my case, and amen! Here's a snippet from the cover letter
        > I've
        > > been sending out recently:
        >
        > Tom, if you are not currently gainfully employed, I can point you to a few
        > truly high-performing teams across the country. They are in the minority,
        > as most software/IT organizations struggle to change those
        > command-and-control cultures, and to foster passion and creativity in both
        > Product and Development areas.
        >
        > > *I just thought of an analogy to explain why I am so single-minded about
        >
        > > TDD. Suppose you need an operation and you're looking for a hospital to
        > do
        > > it. A major hospital sends you a wonderful brochure explaining how
        > > successful they are, what a high-tech surgical suite they have,, etc.,
        > etc.
        > > But when you call up and ask them whether the surgeons wash their hands
        > > before operating, they say, "Why would we want to do that?" Oh yes,
        > > surgery was practiced for centuries before surgeons ever scrubbed up -
        > it's
        > > a great tradition. But I don't think you'd want to have anything to do
        > with
        > > a hospital like that. That's how I feel about TDD. It's a matter of
        > > funda**mental
        > > software hygiene. *
        >
        > It's a perfect analogy. Scott Bain uses this in his book /Emergent Design/
        > as one example of how software development is similar to surgery. (Aside:
        > Apologies if I popped an original-idea bubble: So often I find I think of
        > something original, only to spot it in a blog post the next day. It's the
        > Newton-Leibniz Effect ;-) The medical field provides an analogy that gets
        > us much farther than bridge-building. Of course, no analogy is perfect, but
        > I often find myself thinking "Doctor, it hurts when I do *this*!" ;-)
        >
        > Happy Holidays!
        >
        >
        > Rob
        >
        > Rob.Myers@...
        > Twitter: @agilecoach
        > http://www.agileInstitute.com/
        >
        >
        >


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