(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
Well, simply ask them. Use reflexion session (aka retrospective.
But please, don't design your workplace as a Skinner box.
--- In firstname.lastname@example.org
, Jonathan House <jonathan@...>
> 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
> 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
> 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 /
> 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
> 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
> wouldn't be re-doing that story.
> Good luck, and let us know how things go with your team.
> Jonathan House
> Technology Operations Director, Amirsys Inc.
> imaginethepoet wrote:
> > So recently we switched to a new methodolgy for doing agile. I
> > much into this now but maybe later as I see if it works for my UI
> > The biggest problem I think we are facing and I want some feedback
> > 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
> > 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.