What!? When’s the decision made?

Making a decision in a team is not easy, especially working in a peer group. MSE studio teams are peer groups. Although there is a team lead in the team, it doesn’t mean he or she is superior to other team members. So, while working in this kind of environment, one big question is “Who gets to make the decision?”

A Story

I remember the first conflict in the Square Root team was happened in the first semester. One day, after the class which was talking about choosing a process for a project, our team was excitingly discussing about what process we are going to use in our cubicle. Everyone was saying his opinion about what processes we should use for each semester. I remember I stood there and kept questioning “Why? Why we should use this process instead of that? Do you have any analysis to show that this process will work for our project?” However, we spent a lot of time on the discussion and we didn’t make any concrete decision. 

Sometimes it was just so difficult to let everyone in the team knows:

When to send out meeting agendas?

When to input tasks time on the sharepoint?

What data we are going to track for the estimation?

How we do planning?

Who should take the responsibility of communicating with the client?

This kind of team consensus problems happened only in a team of five. Not to mention what will happen in a larger team.

Finally, we learned to use “Proposal” to help the team communicate more effectively and to drive the team making defensible decision. 

What’s inside a proposal?

First, we wrote about the objective of making a decision. This sound trivial, but sometimes people really would forget “why they are doing this.” 

Second, the approach of the process we are going to follow. Any detail procedure of how we do things would be recorded here. 

The last but not the least – we also wrote down what metrics and data we wanted to get from this process. This is for future analysis on this process.

How does “proposal” change us?

After we used the proposal approach to make decision, the team started to create a lot more proposals than we thought! For example, we have meeting proposal, process proposal, planning proposal, tracking proposal, and even a proposal for proposals!! 

We became very clear that according to different roles who is responsible for making what decision. We spent less time on quarrelling about any decision we need to make. However, team member would review a proposal and provide very specific suggestions.

Later on, we even invent a proposal survey mechanism to use quantitative data to prove how well the proposals are.

Writing a proposal is never a fun thing, but this is one of the approaches that keep the team align and hold the team together!

Are you indecisive? If so, play a game!

Decisions! Decisions!! Decisions!!! They are key ingredients in the colorful life of any engineer (not just for us, the reclusive software hermits!). No longer can we secure sanctuary at the confines of our desk, hoping to have our decisions deferred indefinitely or delegated to some unwilling soul. The conclusions that we arrive at often have far reaching consequences, some of which we can barely fathom. Wouldn't it then, be wise to employ the collective wisdom of our peers to arrive at conclusions that have their benediction? But wait, does that mean more boring meetings - constructs devised to drain the energy and enthusiasm of its participating members. Well, Not exactly. Sure, meetings are unavoidable but they need not be long - and they definitely could be fun! How, you may ask, do you do that? By playing games! Intrigued? Well, the following strategies listed below illustrate how we employed games to make the decision making process a bit more entertaining.

The Planning Poker

We had an estimate of the time that was available. We also had a list of certain milestones that needed to be accomplished within this time frame. The quandary that was ostensibly placed before us was - could we accomplish all these milestones? If not, which ones do we prioritize? Sure, there were a lot of slick estimation tools available; however, most of them rely on historical data - something that was not available for our benefit in the Fall semester when we embarked on this project. The viable solution seemed to be the employment of past experiences of team members in order to arrive at a reasonable estimates - estimates that would prevent the plan from being entirely quixotic. To avoid inconclusive discussions and foster team enthusiasm, we decided to employ the game of planning poker. As indicated by the website http://www.planningpoker.com/ " The idea behind Planning Poker is simple. Individual stories are presented for estimation. After a period of discussion, each participant chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again." In our case, the stories were milestones, where each member rationalized his estimates by discussing the tasks he believed were inherent within this milestone. Not only did this environ alleviate peer pressure, but it also fostered amusement in an otherwise mundane process.

The Task Selection Race

Based on historical performance, each team member had an upper limit on the tasks that they could place on their respective backlog. This task selection process was spiced up by incorporating race flags and lights on a central progress monitor. Its principle was simple - as each team member filled up their backlog queue, the indicators associated with their queue changed from green to amber. The goal was for each team member to select tasks until the indicator changed to red. The concomitant effect of this strategy was that team members tried to race each other to the finish line. Individuals who would otherwise deliberate indecisively on which tasks to select to their queue, were now subconsciously motivated to speed up their decisions and select the tasks that they found interesting. The overall effect was a drastic reduction in meeting duration and a dramatic improvement in excitement in what would otherwise be a mundane, repetitive process.

Rock, Paper, Scissor!

The simplest games too can come to you rescue! When all else fails, we decided to base our decisions on chance. Note that, this was used only in situations where all paths were feasible and only a selection had to be made in term of individual ownership. To cite an example, for determining a presenter for an event, this technique would come in handy to eliminate options and quickly arrive at a winner (some would call a loser!) who would take ownership for the task at hand.

Have fun!
The whole idea being this article (if you haven't figured out already) is that the workplace need not be boring! I have anecdotal evidence to support this, and believe that even the most mundane tasks can be transformed into something interesting. Arriving at decisions that are in conformance with multiple members is a daunting task, and can be quite demoralizing if they degenerate into long, inconclusive meetings. Why then, not speed up the process and have fun while at it?