Using Whys to Understand Good Behavior

When a problem occurs, we usually know what happened and how it happened, but it can be difficult to know why it happened.

Lets say a bug is found in your system and you are able to reproduce it (what), isolate and study the code containing the badness (how) and produce a patch for it. Bug fixed, problem solved, right? Not really, because we don't know why it happened, so we didn't really learned anything from this. The point is to do it better next time and avoid the problem in the future.

This is where root cause analysis, RCA, can help. In short, with RCA you work your way backwards from the problem statement and ask "why" enough times until you end up with something that seems to be the real cause. In this case, it might be that the database abstraction they've been using is too complex and they should use a more straight forward approach.

This might result in a discussion about values like simplicity and concepts like meaningful abstractions, which in turn can be a new point on the definition of done list: "Is the code simple enough?"

Turning RCA around

I was thinking about using RCA not to solve problems, but to analyse good behavior and find reasons for that behavior. This could be used as a way for the team to "self-learn to self-organize" without having to force feed them theories about team dynamics. My idea goes like this:

First brainstorm quickly with your team around "What characterizes a great team?". You might end up with stuff like regular deliveries, stable velocity, shared goals, conflict management etc. Don't go too deep here. Stop when you have a handfull of phrases like that up on the whiteboard. This sets the context for the next step

Now run a RCA starting with the statement "This team produces great results" and ask why? several times!

This may go completely out the window if the team is not confident or mature enough, but I'd like to think that something like the following should be the result of this experiment:

"This team produces great results!"

1. Why? Everyone focuses solely on team success and are able to put their own personal agendas aside
2. Why? They call out each others bad behaviors when someone breaks the rules and decisions
3. Why? Everyone commits to and understands the goals and are confident in the teams decisions
4. Why? All opinions and ideas have been vented and argued so no-one feels left out
5. Why? They are mining for potential conflicts and are not afraid to passionately question ideas even though it might be uncomfortable
6. Why? They use unfiltered, honest dialogue to reach the truth rather than as a way to win arguments or push ideas for political or personal reasons
7. Why? Team members trust each other knowing they can be open with their fears, mistakes and shortcomings without having to risk any kind of retaliation

The major breakthrough in this exercise is when (or if) the team reaches the root cause "trust" and it dawns on the them that trust is, without doubt, the most important characteristic of a great team and the first solid stone to success.

Overtime is Waste of Time

Working overtime produces more results faster, right?

I'll just lay it down for you:

Developers working overtime does not produce better software. The occasional crunch day is fine, but as soon as overtime turns into the accepted norm, things will go downhill: bugs, crappy design, complexity, no testing etc. And that's only mentioning the technical problems.

A lesson for managers and developers (myself included)

Developing software is problem solving. Solving problems requires a focused and creative mind. A tired brain loses it's ability to concentrate. It's like playing tennis with a broken racket: pointless. Quit, go home and come back fresh in the morning.

Having said that, I know that being stuck on a tricky problem and suddenly having to quit is extremely annoying, especially when you think the solution is just around the corner. My natural instinct is to stay put, work on it some more, "try a few more things" and then leave. It never works. You're not going to solve it that way. Just bite the bullet and go home, unwind from the problem and jump on it in the morning. My experience is that you will solve it almost instantly once you're back the next day. Or (as it often happens) your mind suddenly realizes there is a solid way to sidestep the issue completely.

A true story

Let me tell you about one place where overtime was the accepted norm. Even though the devs worked overtime, nothing of value was finished. Instead everything just took sooo muuuch looonger, like they had stretched the normal eight hours so they would last the entire day. Obviously, their brains were overworked, tired and completely void of creativity. As you'd suspect, it was a slumbering mess of zombie activity.

How did that happen? For starters, those who dared to leave the office at 17 got the evil eye from the boss and a snide remark. Leaving on time got you branded more or less like a traitor. The last person leaving the office in the evening was, without exception, the dev boss. I'm certain that was just to make a point of it. I remember one occasion he was wearing a t-shirt with "22 is the new 17" printed on the front. I kid you not.

Accepting overtime, on the other hand, was rewarded with fist bumps, ata boys and other signs of approval. Simply put, you had to work overtime to get accepted by the chain of command. So naturally, the programmers did that. Eventually, it fell apart. Development practically stopped due to bugs and sloppiness. People got fed up and quit. In the end I believe only the boss stayed and I bet he's still there, hacking away in the night...

Team Entropy

Code that is left alone will eventually start to break down. This is called code entropy  and is like this evil force of nature which can only be kept at bay by constant code refactoring. 

Each time you add code, entropy increases making the code a little bit more complex and a little bit harder to maintain.  In short, technical debt is slowly increased little by litte.

But what about team entropy?

Like code decay, team entropy is an invisible force constantly working on you to let things slide, beckoning you to return to the way things were before. At the core, this is one of our most basic instincts: avoid work by taking the easy path, not necessarily the smartest path. 

"I should go to the gym, but...". 

"We really need to do something about this, but ..."

All teams are influenced by it and many succumb to it. When energy is high, this is not a big deal, but eventually energy is lost. After numerous sprints and releases, things starts to get cosy and routine. Complacency sets in. The result is that continuous improvement suffers and the team eventually falls back to a pre-agile state. But the funny thing is that the team still believes they are agile, even though they are only going through the motions.

Here are some indicators that a team is affected by entropy or complacency.

• Retrospectives becomes a comfortable routine
• Longer iterations are introduced
• Re-planning during iterations are accepted
• Stand-up meetings gets longer and does not create energy for the team
• Less pair programming and/or pairs rarely switches
• The whole team is getting more quiet
• Agreed-upon practices are skipped in silent agreement
• Workarounds are accepted instead of fearless problem solving
• Bugs are starting to appear again

Team entropy is hard to fight or even notice once it has started to set in. They way to fight it to be vigilant (for lack of a better word). You need to be on your toes. Constantly challenge yourself and your team to improve and question the way you work.

How to fight it?

Retrospectives! Treat them seriously and never accept routine when it comes to retrospectives!

Change the way you do them, make them shorter or longer, try a new agenda, hold them in a new place, use different tools, try another time. In short, surprise your team!

For inspirations there are a few books which can help you with this. I recommend that you add Agile Retrospectives and Collaboration Explained to your reading list.