"Experience, Empiricism, Excellence"
Please share with your colleagues and friends

The People View looks at the "soft-practices" involved in communication techniques, team building, decision making, leadership and team forming. 

As part of Evidence Based Decision Making and Making Effective Group Decisions we introduced a decision making model that uses a decision tree to help choose a model based on characteristics of the decision. The following are some examples from real case studies of using this decision tree to help explain its use.

Agile Team customer sprint demo and assessment

An agile team gets to the end of its sprint and demonstrates the product back to the Product Customer to get a decision on acceptance.

Decision: Is the current iterative build on the right track and delivering the right requirements to the right level of quality?

Decision owner: The Customer (actually 2 senior users acting as representatives of their user community)

Q1: Are the stakeholders known, available and engaged?

Yes, the stakeholders are the customers, their community and the dev team. All are represented, available and engaged.

Q2: Quality decision required?

Yes, decision required a binary yes/no response that is correct as the future work of the team, and therefore the product, is based on it

Q3: As the owner do you have enough information available to make a good decision?

Yes - the customer reps understand their requirements and needs, they understand (via demo) the solution being offered to them. Making this decision is why they’re there!

Q5:  (not a typo, Q4 is skipped in the decision tree): Do the members of the team or group have to accept this decision for it to work?

A tricky one… You could say “yes” because it would be personally difficult if they didn’t accept the decision and could cause contract issues in some environments but, if you boil it right down, the customers decision informed by the evidence presented to them is final. It’s not up to the dev team to decide if the customers are happy or not, they have no right to impose that decision on the customer. The purpose of a customer demo and assessment is to make sure they’re happy, so we answer “no”.

In this case we should use Autocratic 1 – the customer representatives should decide whether they’re happy or not. The wider team aren’t going to have a vote on it, the customers will just decide. Is that right? Is that what the customers expected? Is that what the team expected? Actually it is. Everyone was a little surprised as they thought that being agile groovy people everyone always had an equal say on everything, but that’s not the most effective way to make the good decision in this case.

 

Team deciding way of working

Here’s another example based on a process improvement business change team deciding on their way of working, note that the dynamics of who the owner is and their relationship to the organization and team may be very different in other teams.

Decision: What should the Process Improvement Team way of working be? (planning approach, tracking mechanisms and reporting, formal plan vs. agile taskboard, sprint/iteration or continuous flow etc.)

Decision Owner: Process Improvement Team Leader

Q1: Are the stakeholders known, available and engaged?

Yes, the improvement team are all available and engaged. It’s questionable whether their management is engaged(!) in our way of working but we still feel that we can make a good decision here.

Q2: Quality decision required? Yes, the team can’t have multiple ways of working at the same time, also the team have changed ways of working again and again with some low quality solutions, they need a good one now.

Q3: As the owner do you have enough information available to make a good decision?

Yes, no, maybe… The owner doesn’t want to make the decision here but does actually have enough information to decide as a process improvement expert. So the answer is “no”.

Q4: Is the problem well understood and does it have well known standard solutions that apply in this context?

Not really. Although there’s a bunch of standards and practices there’s not really a well established proven process (in this context and environment) for how a process improvement team should run.

Q5:  Do the members of the team or group have to accept this decision for it to work?

Yes, the team have to accept the way of working to actually do it.

Q7: Are the group members aligned with the same motives and goals as you the decision owner?

Yes, the team shares a common agenda to improve the organization and they all want to be successful.

In this case we should use Group 2 where all of the team understand the problem and discuss possible solutions before deciding as a group to adopt a way of working. This is not a surprising outcome for an enlightened team leader who believes in self-organizing teams. They’ve actively decided along the way to avoid imposing their decision on the group to the extent that G2 was the only feasible outcome here.

Please share this page

Submit to DeliciousSubmit to DiggSubmit to FacebookSubmit to Google PlusSubmit to StumbleuponSubmit to TwitterSubmit to LinkedIn