Fear does funny things

Have you ever worked in an environment where there was an overriding sense of fear behind decision making and team behaviors?

Do you ever notice people are very quiet in meetings when you know they disagree? 

That's what we had for a long time. 

I still recall the Project Executive standing in the middle of the open team space and yelling "I'm going to fire you all and start again" (He also had other gems like "Conflict breeds performance". But I digress... ). The main point was that the teams were driven by fear. 

Ironically - so was the Exec. It was his butt on the line if the project failed again. 

No one likes to fail and get thrown under the bus, and it had been going on for 4 years. I even had developers that were too scared to touch their keyboards.

Fear of failure and the corresponding repercussions can lead to perfect charts like those below.

Agile teams should make mistakes. They should be allowed to fail. In fact there is a general motto of "Fail fast". The emphasis should be on how fast they get back up, dust themselves off, learn from the mistake and re-adjust. If they never fail, they're probably sand-bagging.

Does your work environment allow for failure?

An example I use is that of a tightrope walker. If you want someone to learn to get to the other side fast, the best thing to do is install a safety net.

Otherwise they won't even take the first step.

Finding defects is part and parcel of software development. You can slam the development and testing team for letting one escape, or you can set-up an environment and behaviors that catch them as soon as possible. Test Driven Development. Automated Tests. Continuous integration.

Fail Fast. It's the best way to succeed.

What behaviors are you rewarding?

It was 2 weeks into the project and the team environment was still hostile. 

Not just "challenging". Hostile. I was running out of ideas.

I had always prided myself on my ability to build cohesive, productive teams and a spotlight had just been shone on how limited my tool belt was. When you contract to a public sector department -  you can't take the team out for lunch or drinks because they don't want to risk the perception that there was any "bribery" involved in the contractual process.

The side-effect is that I had to start learning to use other tools.

Candy started appearing at work. The small things that are normally overlooked got rewarded and praised. A gong appeared so that the BA's could hit it when a story was approved and accepted. This was usually proceeded by applause and cheers from the open floor. If you're reading this with cynicism, I can empathize. False praise doesn't motivate anyone...

It's funny how far sincerity and genuine good intent will take you though.

A lot of management theory relates to rewarding performance or results. In the last year or so, I've taken to rewarding the behaviors that lead to those achievements; rather than waiting for the goals to be achieved and then rewarding that.

Why?

Imagine you set a New Years goal of running a marathon. Are you more likely to give up at the beginning when you have just started training or at the end? When will you need the motivation and support from friends and family? 

Reward the right behaviors during the tough times and the results tend to follow. Besides, then you get to go to the pub again when the project releases :)

This video is highly recommended:

The power of Three

I recently sat through a UI session with some developers and business analysts as they tried to choose between 2 design options. The situation made me consciously recognize a tool that I use a lot in meetings to help drive decision making.

On the board were 2 implementation approaches that the business analysts were trying to decide between and struggling with. So I added Option 3: Use what the base product provides and not code anything. We all knew it wasn't a viable option, but it provided context that the two other options we gave them were so much better that they could go with either one and be much better off.

It's seems like a silly and simplistic technique but there has been quite a bit of research done on it.

Choosing from:

• No options: This is generally a bad idea unless it's specifically a brainstorming session or a "Understanding the problem" session. Otherwise the discussion tends to go around in circles. 
• 1 option - No one likes being left with no alternatives
• 2 options - You start second guessing whether you should have chosen the other one.
• 3 options - My perfect number 
• 4+ options - “The more options there are, the easier it is to regret anything at all that is disappointing about the option that you chose.”

There's an interesting TED talk about the Paradox of choice below. 

So next time you want to drive a meeting to a decision point, remember the power of three. 

Can something be too perfect?

Another common fallacy with agile delivery methods is that there is no proactive planning and tracking. I wouldn't call that Agile.

That's more "Cowboy".

The common tools I use are burn-down and burn up charts for iterations and for releases. It gives you an idea of what you have left to do for each milestone at a quick glance, and whether you're in trouble.

Over the last year, I've leaned towards just doing burn-up's and only at the story point level. Once you start tracking hours against tasks, the management cost increases exponentially without the corresponding benefits. You could theoretically extract resource utilization data from it, but I rarely see that data used. Remember - There's no point capturing data if you're not going to use it. 

In the example below, the story point goal was ~800 points. The dark green represents what was accepted by the PO. Due to organizational dysfunction, We were utilizing more of a kanban approach and were demonstrating as soon as features were completed and tested rather than waiting until the end of a sprint. This method had pro's and con's which I'll discuss in a separate post.

We emphasized with the team that it's much better to get stories done and accepted all the way through the cycle and not letting things sit and slamming QA and the PO at the end.

After several iterations we started seeing these patterns in the burn-up:

An almost perfect linear line from iteration start to the goal.

That's a good thing right?

Or is it a little too perfect? 

To answer that - you have to understand the team, the environment and their motivations.