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

Re: [XP] Re: "The process failed us." How about, "we failed the process"?

Expand Messages
  • Dave Rooney
    ... Yes indeed. And it wasn t only the development team, but the Customer s organization as well. To a certain extent, the project was a victim of its own
    Message 1 of 7 , Oct 25, 2006
      On 25-Oct-06, at 10:55 AM, DianaLarsen wrote:

      > --- In extremeprogramming@yahoogroups.com, Dave Rooney
      > <dave.rooney@...> wrote:
      >> In my 2.5 years on that project, there was precisely one
      >> retrospective. It was productive and led to some improvements in
      >> communication and understanding among the team. However, had we been
      >> doing them at each iteration a lot of issues could have been avoided
      >> in the first place.
      >> It still bothers me, because from a technical standpoint it was a
      >> very, very good team. Old habits die hard, I guess.
      > Aha! ;-) Just one retrospective! Rachel Davies (and others) calls
      > iteration retrospectives "heartbeats" because they take the pulse and
      > gauge the health of the project. Without checking the "heartbeat", the
      > project can go into decline without anyone really noticing...or if
      > they notice...without taking action to change things.
      > Seems as though your team, for whatever reason, didn't take the time
      > to learn from, then plan action based on, their experiences, so they
      > fell back into old habits.

      Yes indeed. And it wasn't only the development team, but the
      Customer's organization as well. To a certain extent, the project
      was a victim of its own success - people on the Customer side were
      taken away to work on a "problem-child" project since our project was
      going so well.

      > It can take a long time to really integrate new kinds of behavior so
      > they become new habits. Until they do, people on the team who care
      > about good work (sometimes the coach, sometimes the tech lead,
      > sometimes passionate team members) can propose reinforcing "boosters";
      > i.e., systems to put in place to make it easier to do the desired
      > behavior than to fall back into the old ways.

      Sure, I understand this. How do you explain this scenario, though:

      We had one release that was very story-focused, used short iterations
      and I created Big Visible Charts of our progress that was updated
      each morning before the standup. It was by far the best release of
      any while I was on that team, and everyone felt good about it.

      After it was released, though, it was almost as if the team said,
      "Wow that was great. Let's never do that again!" We immediately
      went back to focusing on tasks rather than stories, overbooking
      iterations with tasks, moving from 1-week to 2-week iterations
      because people "weren't comfortable" with 1 week, and no more
      progress charts. I had been doing the tracking for a while before
      that release as well as during it, and it was felt that it was time
      for someone else to track (which was fine with me!!). No one else
      saw the value in posting the progress charts. Ever.

      > Sounds like your example of "buying a round of drinks" was an instance
      > of that. What other examples do we have of these kinds of reinforcers
      > for new team behavior? "Informative workplaces" perform one kind of
      > reinformcement. Are there others? I'd like to see a collection of
      > them.

      The round of drinks worked fine until one of the few employees on the
      team (as opposed to contractors) was going to be required to buy a
      round. He refused outright. From that moment on, the practice
      pretty well died. What was thought to be a Community Agreement wasn't.

      > In _Agile Retrospectives_, Esther and I propose six ways to support
      > behavior change becoming the new habitual ways: reinforciment,
      > empathy, learning opportunities, practice opportunities, reminders,
      > and sharing responsibility for changes. Old habits /do/ die hard. If
      > we take this as given, we put into place lots of supports for making
      > the change and making it stick.

      Consider the book ordered! :) Retrospectives are likely my weakest
      point in terms of my XP/Agile experience.

      > What a great file to stumble across, Dave! You could write a book with
      > that list as a starting point! :-) Each point a new chapter.

      It was interesting, but also aggravating. It still pisses me off
      that such a good team and environment could eventually grind almost
      to a halt.

      As for it being a book, that's an intriguing thought! ;)


      Dave Rooney
      Industrial XP Coach
      I n d u s t r i a l L o g i c, I n c.

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