Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Written by Alberto G

April 24th, 2009 at 7:47 am

7 best practices for taking decisions in the development team

with 5 comments

Importance of Decisions.

During the software development process, a lot of decisions have to be taken, they may be related to design or architectural issues, testing approaches and many other different areas… What follows is the 7 best practices for making the most when you are about to take a decision in your team

The 7 Good practices.

1.- Have a clear goal. (A vision statement)

Good Example: “We need to decide on what technology we are going to use for the UI of the next product”.

Bad Example: “What are we going to do next week?”.

Write it in a board making sure that everyone can read it. (Importance of boards are highlighted in the 6th point)

2.- Gather all the inputs.

As explained in my previous article about inputs, outputs and actions, inputs are the clues that leads us to find the best solution, in order to take the best decision we need to make sure that we  have the appropiate inputs.

Good Examples: “We are not tight to use the same technology for the backend and the frontend”, “Inside the team there is strong expertise in technologies x,y and z”, “The dead line for the UI is in one month”…

Write them in the board as well. (Importance of boards are highlighted in the 6th point)

3.- Keep the discussion objective

Opinions should be translated into facts and numerical arguments, if not it will be impossible to compare with each other, keep an eye on the following symptoms of a non objective discussion

– Don’t use Buzz words/be vague/use the word “should”.

Some examples: “This approach should be easy”, “performance is going to be bad”, “what I am suggesting is a best practice in the industry”….

– Don’t let people speaking in future terms (if they are outside of the scope).

If the scope of the solution doesn’t include any point that states that the solution has to be time proof, then don’t let people use that argument to discuss. Example: “Well, I don’t like this logging approach because there is too much overhead data, and maybe in one year we will run out of space”.

– Avoid people from first being understood rather than to understand.

Lots of time two persons argue about something but they are basically saying the same thing with different words, two tricks to avoid this are:

– Don’t let people interrupt
– Make them rephrase other people point with polite questions like: “Sorry Tom, just to make sure you understood Andrew point could you rephrase it?”.

4.- Don’t make it personal

If deciding A or B becomes deciding if Bob is better having good ideas than Harry, your may be discussing for the next two weeks.

– Separate opinions from people.

Write them in the board and call them with letters or numbers, NEVER write besides them who suggested the idea. Try to mix the best from all the ideas rather than selecting just one person approach.

– Be careful with the egos.

Software developers usually have huge egos, actually the better is a developer, the bigger is his ego.

5.- Timebox the decision, make the decision process takes as short as possible.

As we will see in the last part of the article it’s not about the idea is about the execution, but we still want a good enough decision, as a rule of thumb, if the vision is clear, the inputs have been discovered and every one have expressed their opinion, it shouldn’t take longer than 15 minutes to make a decision.

6.- Keep Focused

Book a room with a board. The idea of having a board is to picture all that has been discussed, at least in the board there should be the “Vision” (Point1), “Inputs” (Point2), all the different alternatives, and the final decision.

Don’t discuss anything outside the scope of what needs to be decide.

Focus on “why” rather than “how” or “what”, just make them explain why a solution is better or worse, is very easy to get stuck in implementation details.

Make people describe their opinions in short sentences and write them on the board.

7.- Make everyone participant of the final decision.

Have a final solution that includes the best from every alternative, thank everyone for their effort.

At the end all is about the execution, not the idea.

Even being important to have a good decision, what matter is the execution, that’s why point5 focus on make the decision making process as quick as possible.

5 Responses to '7 best practices for taking decisions in the development team'

Subscribe to comments with RSS or TrackBack to '7 best practices for taking decisions in the development team'.

  1. […] junior developers that want to impress their colleagues, this type of developer can as well easily get stuck in a discussion with his colleagues about […]

  2. […] 7 best practices for taking decisions in the development team « Making Good Software (tags: tips) […]

  3. […] doesn’t mean that you don’t have to fight for your opinions and ideas, there is a time to take decisions and that’s when you have to bring all your ideas, after a decision is taken, embrace it as if […]

  4. […] doesn’t mean that you don’t have to fight for your opinions and ideas, there is a time to make decisions and that’s when you have to bring all your ideas, after a decision is made, embrace it as if […]

  5. […] There are a few more tips for improving communication when having a meeting in this previous article I published “7 best practices for taking decisions in the development team“. […]

Leave a Reply