Failure, It's Not a Bad Thing

I stumbled today into a new concept. It is called Day for Failure and I think it is very interesting and should be recognized more publicly. The web is full of those 'motivational' pictures about epic fails. Those are amusing. But on the other hand, I think failure is seen many times in too negative way.

Failure is a blessing! It tells you that you did something that you shouldn't try again. It's offering you valuable insight about how life works and something even more important. Failure opens a door for learning.

Mr. Edison might be the most known people to fail. Or as he puts it, found ways that don't work. But I think the main message is this: you only fail if you give up. If you make a mistake and learn, you haven't failed in this negative sense that so many people use. Or we can call that failure, but it's still a good thing.

Lean Startup along with the concept of Validated Learning has been one of my favorite books. Probably due to it saying the same thing. Experiment. My mistakes. Fail fast. And then try again. The faster we fail, the faster we gain more knowledge. And the safer and less costly we make failing, the more we can utilize its awesome power.

So next week, on October 13th and after that, start building a new culture at your workplace! Share and celebrate failures. They offer you and your colleagues information and learning you could never achieve by always staying on the safe side. And by sharing the experiences, you don't have to repeat the same failures but can try new ones.

Facing the Reality in Product Management

For some reason Software Development is somehow so far from the physical world that it is very easy to neglect the truth for a very long time. Managing products is one area where I have faced some horrendous gaps between the plans and the real world.

This picture of Chinese traffic jam has become one of my favorites lately:

Unfortunately I think it characterizes the amount of things some people think can be done in parallel. A Product Roadmap that has nine things that should be developed in parallel. By one team. Of about nine persons. If you say it out loud like this, it's probably evident that it's not going to happen. But if you just add boxes to a PowerPoint, it's deceitfully easy to just add one more box. ...and yet one more.

My solution asks for another picture. 

"There you go. I think your Roadmap is great, but it only has this one flaw. Everything you have there needs to fit through this funnel." Well the diameter of the funnel of course depends on the team size, but I think one-piece-flow would be something to strive for.

Doing things in priority order one by one. Creating the features that offer the biggest customer impact and added value one after another. Doing things pragmatically and keeping the focus. Let's try to get there!

Children are Excellent Teachers

I recently had a discussion with my son's kindergarten teacher and she told me how my son's group has been teaming up very nicely. They play together and everyone has found their place. Some are carrying sticks, some build things from those while some of the others are more involved with the planning. When, inevitably, there's conflict, they say they are sorry and the situations resolve quickly. And when they do sports, everyone is rooting for the others like crazy!

If preschool children can do this, why is it so hard for us grownups?

When the organization is still going through the agile transformation, it's probably not uncommon that people only think about their own tasks. "I have done my part. It's not my fault if the others don't keep up." But in an cross-functional Agile team you are not merely accountable for your tasks. There are no "your tasks". The team has goals and the team members are ALL equally responsible for the results.

This will probably become clearer over time. But in a bigger organization, I'd like to reach the next level. I see an analogy between one team and a Sprint and between several teams and a Release. My personal vision of a larger organization is such that teams working on the same product pull one rope. If one team is struggling and the others have finished their commitments, they will help. No team is left behind! And maybe in a larger organization this would scale up still one level, but I have no first hand experience about that.

Great things are achieved through doing things together!

Increasing Internal Communication

After the vacation I've been absolutely on fire at work! Seems that everything I do or try just goes pretty much as well or better than I had expected.

I can't remember exactly where I heard the term, but I got interested in Coding Dojo. We have suffered from teams being in silos and I've been thinking about possible activities to gather developers from across the teams. So I decided to arrange a Dojo!

Coding Dojo is a sort of workshop where everyone participates. There's a driver and a copilot (like in pair programming) and audience. Every five minutes (or any other agreed interval) people change places. Copilot becomes driver, driver goes to audience and someone from the audience becomes the new copilot. There ought to be one sensei also, but we didn't have one.

The subject for the first ever Coding Dojo was Async. No-one knew the subject that well and the group was able to successfully implement a small demo program. One improvement suggestion was that a bit better preparation would have saved a couple of minutes from the start. Point taken, inspect and adapt. ;)

I'm not a big fan of email, since people tend to ignore those messages. Or at least it is very hard to know if your message has been received and understood. I wanted to create a blog. First blog post could be a short report about how the Coding Dojo went by one the participants. It would be nice to get a developers perspective on this.

Third form of internal communication that I've tried this week was video. In a multi site company where people are spread around the globe, it's not possible to get everyone into a meeting room and just give a short training. And as I already mentioned, I don't have too much faith in people reading their emails.

I tried something new. I made a short PowerPoint presentation and uploaded it into our intranet. Then I started recording and talked through my presentation. It took less than ten minutes. After finishing the video and uploading it to the intranet I sent an email with links to both the slides and the video. I can warmly recommend this approach; the feedback was very positive. Of course, if it is an option, stick with the face to face conversation.

This video by Henrik Kniberg about Agile Product Ownership is simply the greatest educational video about any Agile subject that I have ever seen! It's been of great inspiration to me in the way of describing very complex concept in such a clarifying way. Thanks Henrik!

Solving Problems, Together

First of all, without too much advertising, I saw recently an interesting commercial with a powerful message. It was by a company called Wickes and it simply stated:

What more can you say? I think it says: craftsmanship. And it sets the expectation level on quality really high. If you create something and want to tell everyone about that with your back straight, I can imagine myself being interested in what ever you are offering. Hopefully they never have any quality problems. That would shoot them in the leg.

But I was actually going to write about different ways of conflict resolution. The examples that I refer to are from conflicts between parents and their children, but they sound very useful also in agile coaching.

Thomas Gordon's What Every Parent Should Know is a freely available pdf document that describes a conflict resolution where neither party loses. In a resolution to a conflict, if one of the parties needs to "lose", they most probably don't feel happy. They probably feel rather bad. And depending on the circumstances, this might inflict grudge. A historical example of this might be Germany after World War I.

If on the other the conflict can be resolved in a win-win manner, the resulting piece will probably last longer and the resolution process can strengthen the bond between participants. Very practical in parent-child relationships and also in team work.

Another interesting example came to me from my personal life. My son has sometimes difficulties in tolerating changes to plans (well, actually I also suffer from that from time to time.) He gets upset when he has to interrupt building LEGOs and come to dinner. I sympathize with him, but as a parent I also feel as my responsibility to keep the boundaries.

In his book, The Explosive Child, Dr. Ross W. Greene introduces a concept of Collaborative Problem Solving (CPS). If I have understood correctly, it was originally developed for kids with problems in controlling their frustration. Actually, I also found a website that explains the method.

But shortly, there are three ways to solve conflict in CPS: plan A, plan B and plan C. A and C are the extremes. In plan A, the parent wins (and child loses). In plan C, the child wins (and parent gives up his/her plan). The main message of the book is plan B. That's where the parent and the child work together to find a resolution that they both can accept.

There are three steps in plan B:

1. Empathy
2. Problem definition
3. Invitation to negotiation

I can't yet tell anything about the effectiveness of this approach, but if it can offer a win-win resolution for both parties, I think it's worth checking out. 

So all in all, again, everything seems to come down respecting our children/co-workers/others and seeing them as human beings with hopes and dreams. Very common sense stuff that is usually taught already in kindergarten. But we grownups tend to forget...

Also this reminds me of  Marshall Rosenberg's Non-Violent Communication. The main thing to understand here is that we all have needs and we live our lives trying to fulfill those needs. And if you can understand yours and other peoples needs and find a way to satisfy them all, there's no problem that you can't overcome.

People are Weak, Teams are Strong!

If you are familiar with Scrum, you have probably read that Scrum is different. It's different from the management point of view, but also from the developer perspective. In an expert organization where everyone has been a sort of a super hero, it feels weird to suddenly be part of a team. No-one is telling you what you should do next. And you have to be in close collaboration with your team members; possibly for the first time during your career.

Although in literature I often see that the lack of management support is a big impediment for Scrum adoption, I'd say that the employees themselves can also create interesting challenges.

It takes time before people accept the fact that they can get more done when they work as a team. If you have five tasks and five people it is not the most efficient way to start working on all of those at the same time. If you are familiar with Lean this is probably crystal clear to you. But in real life, it's not so easy to let go of the old habits.

Alone you can do small things, but if you are aiming to go higher, I advice you to take a team with you!

On a Ride with Heroes (or Bad Apples)

I went back to work today and read two interesting articles. First one was about "bad apples" in teams. Probably quite many are familiar with these people. At least I can admit that I have seen these.

It is very odd that when the company is going through a challenging period of moving from old way of working into a more Agile way, some of the most senior people see as their divine right to protest. In the past these people have been the heroes of the company: solving the impossible problems at the last minute, making that needed fix in no time and knowing almost everything about their domain.

Somehow these company's finest become anti-heroes. They start to undermine the Agile adoption process by not sharing information with their team members. We often call these people "cowboys". And because of their superior knowledge (especially when dealing with complex legacy software), just showing door to these people is not the option that management is eager to take.

In my opinion, the option the company is left with is to motivate these individuals. Try to see what makes them tick and show them how Agile can work for them. And maybe pipe down about the process talk and concentrate on how they can maintain their status as experts also when working together with a team. But it is not easy for the team. That I can assure you.

The second article was about Ericsson adopting agile. It is always soothing to see others have some similar challenges and we are not alone with our problems.