Somewhere in the overlap between software development, process improvement and psychology

Decision making case studies

I’ve previously blogged on a decision making model that involves understanding the decision making process and then the different ways a group can reach agreement and how to choose which method to use in which situation. This post covers some real case studies from my own experience that apply this model and help discuss some the issues involved.

This post won’t make sense without reading How to reach agreement in a group – autocracy vs. democracy as it contains the decision tree and questions this post refers to.

Agile Team customer sprint demo and assessment

Decision: Is the current iterative build on the right track, 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, 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 I mentor deciding on their way of working, note that the dynamics of who the owner is and their relationship to the organisation and team may be very different in other teams – that’s kind of the point of all this…

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 organisation 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-0rganising 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.

Agreeing a Process Improvement team’s scope

What about that same process improvement business change team working out how to agree what their scope is…

Decision: What is the scope of the process improvement team’s work for the next year? Who will they engage with, what will the improvement agenda be?

Decision owner: The development community in the organisation

Q1: Are the stakeholders known, available and engaged? – No. The community are known but not really available (they’re busy) and not especially engaged, at least not enough to represent the community and come and make decisions 😦 That means that the team has to represent the decision owner.

Q3: As the owner do you have enough information available to make a good decision? Yes or no it’s not a great answer. As a modern process improvement team the team don’t want to decide their own scope in an autocratic way, assuming that they represent the communities needs, however they’ve been forced into this situation by not having available engaged stakeholders.

There are a number of options available here of course, the primary one I’d recommend is get the community engaged (that’s a big group of topics in itself).

You could publish the results of this process and declare that scope decisions have to be made autocratically even if that’s not what the team wants to do. As a result I’d hope that the community would find a voice to say that approach is unacceptable beginning the journey to engagement and representation…

For more on decision making see Part 1 A model for making group decisions and Part 2 How to reach agreement in a group – autocracy vs. democracy

Have you got a case study?

Please feel free to share your own case study in the comments section, just thinking about the dynamics of these situations and seeing some variety means we can all learn.

This blog is part of a series on Holistic Communication: The linguistics of business change. Introduction, ethics and table of contents is all in the first post.


5 responses

  1. Pingback: How to reach agreement in a group – autocracy vs. democracy « The Mac Daddy

  2. Pingback: Linguistics of business change: Holistic communication, ethics and morals « The Mac Daddy

  3. Hi Mike,

    I think your post will benefit many project managers and that’s why I would like to republish it on PM Hut where it will get a lot of exposure.

    Please either email me or contact me through the contact us form on the PM Hut website in case you’re OK with this.

    April 3, 2012 at 3:03 pm

    • Sure, so long as it’s attributable and links back here – I’ll send you an email to discuss 🙂

      April 3, 2012 at 9:03 pm

  4. Pingback: What does a self-organising team really mean? Organisation! « Mike MacDonagh's Blog

What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s