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

Re: One Of My Biggest Agile Problem.

Expand Messages
  • dgery2000
    (sorry if this answer is posted twice) The last thing a (agile) team of smart people needs is resorting to autocracy or bribes. In your case, that won t help
    Message 1 of 46 , Aug 30 2:12 AM
    • 0 Attachment
      (sorry if this answer is posted twice)

      The last thing a (agile) team of smart people needs is resorting to
      autocracy or bribes.
      In your case, that won't help finding the root of the problem which
      seems to be : why do those smart people prefer to do dumb things on
      purpose.
      Well, simply ask them. Use reflexion session (aka retrospective.

      But please, don't design your workplace as a Skinner box.

      Géry.

      --- In agile-usability@yahoogroups.com, Jonathan House <jonathan@...>
      wrote:
      >
      > Hi there,
      >
      > This is a very common problem - not only for new agile teams, but even
      > experienced teams can lapse into this sort of behavior pattern over
      > time, especially in cases where they are working on functionality that
      > is familiar with them.
      >
      > First question I would as is "how detailed are your stories?". If they
      > are at a high level of fidelity, that alone may be prompting the
      > developers to assume that the level of detail indicates that all of the
      > discovery work has been done and that they don't have to have the
      > conversation. If your stories seem to be detailed enough to prompt a
      > developer to dive right in as opposed to having a conversation, I'd
      > reduce the stories to the point where you start to see the
      conversations
      > occurring.
      >
      > If your stories are relatively rudimentary and the developers are just
      > assuming behavior, you've got a more challenging problem to fix - their
      > behavior needs to change. There are multiple paths to this goal. Here's
      > a couple of examples:
      >
      > 1) Mandate - Don't allow a developer to start work on a feature unless
      > they've had a conversation with the appropriate customers / end users.
      > This is a rather heavy-handed way of getting the job done, but it
      > generally produces the fastest results if the management team is on
      board.
      >
      > 2) Reward - Set up a reward system of some type that will encourage
      > developers to have these conversations. There's lots of different ideas
      > for rewards that are worth trying. This causes much less wear and tear
      > on your team, but you have to find the right rewards to encourage them.
      >
      > 3) Punitive - Assuming that you have some sort of ceremony when a
      > developer finishes a feature, you can arrange to have the customer /
      end
      > users show up right then at that developers workstation to review the
      > feature that has been developed (don't wait until the end of the
      > iteration - this has to happen right at the completion of the feature).
      > When the customer inevitably finds something wrong with the
      > implementation, give the story back to the developer to have them
      rework
      > the functionality. This is different from the mandate approach as it is
      > tightening up their feedback loop to the point where they can see for
      > themselves that if they had engaged with the customer at the outset
      they
      > wouldn't be re-doing that story.
      >
      > Good luck, and let us know how things go with your team.
      >
      > Cheers,
      >
      > Jonathan House
      > Technology Operations Director, Amirsys Inc.
      >
      >
      > imaginethepoet wrote:
      > > So recently we switched to a new methodolgy for doing agile. I
      won't go
      > > much into this now but maybe later as I see if it works for my UI
      needs.
      > >
      > > The biggest problem I think we are facing and I want some feedback
      from
      > > others is this. People just look at the story and do just that. It's
      > > like everyone has become a robot. There is no more common sense. I
      know
      > > some of our development team used to have common sense. They are all
      > > excellent developers and smart people. And now it's getting less and
      > > less as we go year after year story by story.
      > >
      > > This is terrible for usability.
      > >
      > > Do any other UI people have this problem? I can spell everything out
      > > but sometimes talking and interaction just aren't enough.
      > >
      > > Extremely Frustrated.
      > >
      > >
      > >
      > >
      >
    • William Pietri
      ... That s a good point. The biggest complaint I hear about this list is that the volume makes it too hard to keep up. Might I suggest that any future
      Message 46 of 46 , Sep 6, 2008
      • 0 Attachment
        aacockburn wrote:
        > I also have enjoyed this rampaging discussion immensely, even if
        > it has precious little to do with agile-usability. It has opened
        > some interesting doors for long-term inquiry in my mind. (Thanks
        > Jonathan for that).
        >
        > Maybe now we can let this group get on with its regularly scheduled
        > program :)
        >

        That's a good point. The biggest complaint I hear about this list is
        that the volume makes it too hard to keep up. Might I suggest that any
        future discussion on this topic go to a more appropriate list? E.g.,
        this one:

        http://tech.groups.yahoo.com/group/agilecoaches/

        Thanks,

        William
      Your message has been successfully submitted and would be delivered to recipients shortly.