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

Re: [XP] Re: Scrum, and Revolution

Expand Messages
  • Leonardo Postacchini
    Hi Charlie, ... This goes against what you have said about agile not being one thing. If you have a definite set of properties, you just made it close ended,
    Message 1 of 167 , Dec 18, 2012
    • 0 Attachment
      Hi Charlie,


      On 18 December 2012 18:02, Charlie Poole <charliepoole@...> wrote:

      > Hi Leonardo,
      >
      >
      > On Tue, Dec 18, 2012 at 11:07 AM, Leonardo Postacchini
      > <notivago@...>wrote:
      >
      > > **
      > >
      > >
      > > 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.
      > >
      > As described earlier, I see Agile as a very bare set of minimum
      > requirements.
      > Scrum and XP are both approaches that meet those requirements and add
      > much more to them. So I don't see Scrum as a start toward Agile and I
      > definitely
      > don't see Agile as one thing.
      >
      > But we do frequently define things that are categories, with many
      > instances,
      > and are quite successful at it. We know what a quadrilateral is, even if
      > some
      > folks may follow the Square methodology, while others are Rhombists. We
      > only
      > have to count the sides.
      >
      >
      This goes against what you have said about agile not being one thing. If
      you have a definite set of properties, you just made it close ended, you
      can't improve on something if it is already at its perfect definition,
      finished.

      Which I don't think agile is.


      > > 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.
      > >
      > Others may feel differently, but I have never wanted to work in a way that
      > somehow tricks management into something by making it sound too easy
      > or as if there isn't a lot of culture change needed. Generally, I try to
      > err
      > on the side of promising to little and threatening more change than they
      > are initially comfortable with. On rare occasions this costs me a job -
      > probably not one I would have been happy in - but it mostly works out
      > well. Telling management straight out also tells them you can be trusted.
      >

      No trick asked for here. When you deliver a system gradually are you
      tricking anyone? Quite the contrary, you give them the chance to control
      the pace, the risk and the choice of when to stop. Just the same goes here,
      if you go bit by bit management can terminate the change process whenever
      they want and they can see the benefits and earn the benefits early.


      >
      > > 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?
      > >
      > I take your point. I just don't agree with it. Agile is binary. It's just
      > that
      > the definition doesn't include things like TDD, pairing, etc. Those are
      > all part of specific agile methodologies. At least in my view.
      >
      >
      As I see it they are the tools by which you make abstract ideals become
      reality. Be it through TDD, stand up meetings, or anything else you may
      chose to accomplish the values of Agile, you need them to make it real,
      conversely, by using them you get those ideals even if you were not aiming
      at getting them.

      It is the abyss rule: if you look at it, it looks back at you.


      > > 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?
      > >
      >
      > Using my definition of agile, can you give me some sample stories? I can't
      > figure out how to be partly empowered and self-correcting, but it could be
      > that you can.
      >
      >
      Assuming that your definition of agile is the act of retrospect about what
      you do and do it better:

      Suppose we have a waterfall project and it is going bonkers, defect rate
      high, badly integrated pieces of API, etc... And people are resistant to go
      all in Agile.

      One story could be stand up meetings where everyone just tell what they are
      doing and what they are failing to do.
      Other could be doing weekly meetings for planing the next steps. We could
      define another one is no extra hours, even giving people an week off so
      that they refresh and come back to theirs game again...

      Then management thinks all of this(and other agile practices) too radical
      but, 15min meetings cant hurt too much.

      So we start with this, this presents a problem on itself, we could start by
      doing it every morning at 10:00am, and then find that some developers are
      not too kin on getting at work before 11 when they stayed up until 3am.

      At some point you can have this working, information starts to flow and
      people help each other, interfaces starts getting more concise and easier
      to work, so people feel more inclined to commit a little bit more, a 4
      hours weekly meeting start to seem less badly now.

      And so you go on about making bit by bit the information flow, improving
      learning process, and gaining benefits.


      > >
      > > 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?
      > >
      > Notice that I haven't said we can't improve, once we are agile. I've just
      > said
      > that you're either agile or you aren't.
      >

      I would argue that what is not agile is completely static. And even
      waterfall is not completely static.


      >
      > > 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?
      > >
      > I haven't found that it gets in my way. But of course, you are making some
      > assumptions as to what I might call Fake Agile.
      >

      Maybe. And thus I ask you for some clarification.


      >
      > > 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.
      > >
      > What is XP is a different question from What is Agile. And whether to adopt
      > full XP all at once or one bit at a time is even a third question. I have
      > my
      > own views on those questions, but they aren't relevant to whether Agile
      > has a real definition or not.
      >

      The question is, is there a clear line where Agile starts? I don't see it.
      As I see it you can go from not being able at all to change and
      improve(completely static) to being able to do it in an infinitesimal step
      of time, and having an infinity of middle grounds between those two.

      But you cant be neither of the two extremes, you always fall in between on
      the scale, and thus you can be more or less agile.


      >
      > > 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.
      > >
      > Yes. But if you aren't Agile in the first place, ,you can't mutate it at
      > all.
      >

      I find it hard to imagine a methodology that is not Agile at all.


      >
      > Charlie
      >
      > >
      > > 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]
      > >
      > >
      > >
      >
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >
      > ------------------------------------
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.comYahoo! Groups Links
      >
      >
      >
      >


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