What if one Team member does not agree with the process? (eg, to do “scrum”)

For our work, we have two related ideas.  The Team and the team’s process.  (Yes, there are many other ideas, principles, values too.)

The Team

Most people, I think, like working on a pretty good team.  Often quite a lot.

Of course, not every team is good.

Some people need an adjustment time. See the Tuckman model: forming, storming, norming, performing, etc.  But let’s just say a lot of people need to get to know others before they decide whether they like this Team.

Some people will like most Teams, but can also a bit picky.  They might say “Team X is not my cup of tea, I’d prefer Team Y”.

And we have some people who will never want to work in any team.  Although at first, the person may not know that.  So, you may have to give him or her a try, and discover later they want out.

In Scrum, we need a way to deal with these two situations.  People who (a) don’t want to be in just this team, and (b) people who discover they “want to be alone” (to use the Greta Garbo quote).  That is, they want to be an individual contributor.

The Process

By “process” I mean a combination of A + B + C (below).

A. The bare framework

The bare framework of Scrum is defined in the Scrum Guide, as “the rules of the game”.

Virtually all “scrum” teams do not do everything defined in the Scrum Guide.

B. Additional standard Scrum patterns

A lot of standard Scrum patterns are well-agreed by most of the community but are not in the Scrum Guide.

We would hope that a typical team does all or most or many of these.

A few quick examples: user stories, story points, DOR, a Scrum Board and an Impediment List.

See A Scrum Book by Sutherland, Coplien at al.

C. Additional “lean-agile” things

I think every Scrum team adds a lot of other things (ideas, values, processes, tools, job aids, etc).

We probably could argue whether some of these are common “scrum” things.

And whether they should be added to Scrum.

But Scrum includes the idea that Scrum is incomplete, and other things MUST be added.

Ex: Some XP practices (pair programming, TDD, etc.). (Commonly recommended by Scrum coaches for software teams.)

Practical situation

In this context, I am using the simple word “process” to mean all of these things (A  + B + C above).

The way-of-working that a team settles into.  Consciously mostly and maybe partially or significantly without thinking.

Odd people

First, I recommend that every team try to define the process they are using now.  As best they can.  And agree to use that together to be successful.

Yes, talking about it is not easy.  A lot comes down to how we will use it, if it really works, etc.

But at least for now, let’s agree on what “process” we will use.

 

And, fairly often, one or more persons in the team is not happy.

But to be a real team, the team has to (pretty much) agree to use the same process.  To play the same game.

 

Yes, in the US we have the idea of minority rights.

But our teams are business units.  Every person has a right to leave a team at any time. (And also the right to ask to join.)  And equally, at some point, if 5 or 6 people agree on a process, and 1 or 2 people do not, then at some point the 1 or 2 must leave.

Now, the odd one(s) might leave and join another team.  Or work as individual contributors outside the team.

Also: good people are hard to find.  So, the company and the (main) team members have also a responsibility to maybe adjust some or at least try to convince the skeptical or resistant to overcome that and join to Process X (maybe after revised).

But for deciding the process, I think ultimately you have majority rule in the Team. (I strongly believe in the Bill of Rights for individual and minority rights.  But that’s for largely “non-business” situations.)

Created Equal?

Hmm.  In Scrum we want all team members to treat the other team members mostly equally.

Let’s not go too far.  There must be some recognition, as we move from thing to thing, that some people know more about thing A or thing B.

Some are smarter about certain things.

So, I recommend for almost everything, each team member gets to voice his or her opinion.  But commonly it is good if one team member decides. Ordering the Product Backlog is one example.  We are not having a majority vote. The PO decides (fairly quickly).

And a wise team, when it finds a minority with another opinion about a Thing, the Team will be wise sometimes to  listen to the minority opinion for a while. And perhaps even ultimately agree with it.  Again: one example is the PO and the Product Backlog. The PO (perhaps often a minority in the Team) decides.  On the wide range of other matters: the Team should listen to the minority. And in some cases let themselves be swayed.

But the worst decision is no decision.

***

Too short, but I think most people can read between the lines.

 

« « Is Velocity Evil? (No.) || In medias res (“Into the midst of things”) » »