| Newsgroups |
gmane.comp.programming.extreme-programming |
| Message-ID |
<CAGH=xQvt06RUDgshB3so1YCk129iXWk4Fow21xhubxUWZx6u1g@mail.gmail.com> |
In the cases I'm thinking of, the team liked the decision but the org did
not (or the team sensed that the org did not).
For example: team decides to try full-time pair programming. They enjoy it
a lot. The org asks that each feature or component or bug has an owner, so
they "know who to go to with questions about that thing". When we pair on
"your" thing, you worry that people will think you're cheating by getting
me to do "your" work, and I worry that I'm letting "my" thing be ignored
which will be seen as bad. So we are slow to actually engage in pairing,
even though we A) decided to pair, and B) enjoy pairing.
The "enforcement" I'm thinking of is reminding the team "you decided you
wanted to do X. To me it looks like you're not doing that right now. Do you
still want to do it, or revisit that decision?" The team is free to change
their decisions as they see fit.
(It's obvious now that the workgroup was not able to function as a team
because the org only understood individual accountability.)
-J
On Fri, Oct 14, 2016 at 5:35 PM, George Dinwiddie [email protected]
[extremeprogramming] <[email protected]> wrote:
>
>
> Jay,
>
> On 10/14/16 7:08 PM, Jay Bazuzi [email protected] [extremeprogramming] wrote:
> >
> >
> > "they were told to pair program" - That's exactly what I'm objecting to.
> > Teams should decide this for themselves.
>
> Yes, I mentioned that to highlight the difference with the second team.
> The management was the same.
>
> > Maybe you read "hold the team to their decisions" as "managers should
> > hold the team to the manager's decisions". I meant "when a team makes a
> > decision, the manager should help make sure that the team sticks with
> > that decision until the team makes a new decision."
>
> Why should the manager do that? I predict many bad outcomes:
> - The team that thinks they have to choose what the manager wants them
> to choose.
> - The team that is afraid to make a decision because then they'll be
> stuck with it.
>
> > I say this because I've watched teams decide to change how they work
> > (say, "full-time pairing on all production code"), and it lasts for a
> > little while and then happens less and less without the team actually
> > deciding to stop. If they want to stop that is fine, but they should
> > make a decision according to their decision-making practice (whatever
> > that is). And I want managers (and everyone else) to reinforce that.
>
> That tells me that the team didn't *actually* decide to work that way.
> They only *said* they had decided. Perhaps someone else was better at
> "winning meetings" and that was taken as a team decision. Perhaps they
> were coerced into choosing that. For whatever reason, they're not
> whole-heartedly behind the decision. Their behavior tells you that.
>
> Use that behavior as information, not as something to be thrown in their
> face. Enforcement of the nominal decision will likely be seen as
> punishment.
>
> When the first team kept choosing "get better at pair programming" as
> the outcome of their retros, I finally stepped in and said, "I've notice
> that you've chosen this action for the last several retros. May I
> suggest that you choose something that you've got the energy to do."
> That got them unstuck, and they were able to make other improvements. It
> took months before they were ready to do much pair programming, though.
>
> - George
>
> --
> ----------------------------------------------------------
> * George Dinwiddie * http://blog.gdinwiddie.com
> Software Development http://www.idiacomputing.com
> Consultant and Coach http://www.agilemaryland.org
> ----------------------------------------------------------
>
>
>