Fighter jet, toothbrushing and agile rituals

When I am in position to talk about the topic that is so “obvious” to me while struggling to find the right words to explain it to the others, I often escape in metaphors, looking for inspiration in nature, other people quotes or anecdotes. Agile philosophy is one of these topics, as it has truly become part of my nature – or it probably always was. When I start talking about it, I very often find myself in kind of schizophrenic mood: saying that agile is a flexible but strict discipline at the same time.  At first, it looks as agile methodology is full of controversy, probably because it insists on practices that look conflicting at first sight:

  • It requires strong discipline of all members while it claims that it is a flexible methodology
  • It requires empowered teams and strong leadership
  • Some people (who actually don’t do agile) compare it to a cowboy coding although agile movement has brought so many novel testing practices

So, the real question is: How to find the right balance between stability and agility? 

Let’s start with my first metaphor for tonight:

The new generation of fighter jets have one design feature in common. They are designed unstable, which is intended to increase agility.

High stability and highly effective flight controls are therefore incompatible requirements. In stable aircraft a compromise has to be made. However, no concessions need to be made in unstable aircraft.

Any pilot will find it very hard to control an aircraft like this without assistance. A computer (“fly by wire system”) is needed to provide necessary stability.

Practices such as standup meetings, iterative development, continuous integration, pair programing, TDD, serve as “fly by wire” system in agile. Although most of these practices should be applied to any methodology, there are crucial to agile, without them agile can’t fly. 

Great, it is all good and settled, so let’s check how it goes with one typical agile team during retrospective meeting:

What was I thinking first time my mother asked me to brush my teeth? I can’t remember, but I don’t think I really enjoyed it. Toothpaste doesn’t taste that great and rubbing your mouth with a toothbrush is not that exciting. While I still do it, I don’t think about it any more (unless I try to write some silly blogs) and that is why we call such activities “ritual” behavior: you do some things not really thinking about how and why you do them.

When you start working, no matter where, on no matter what, there will be things you like to do – aaaaand other things. The same is true for other people around you, sure about it. You may say: hey, hold on a second, how about motivation? Isn’t it all about autonomy, accountability and stuff like that? People will just do it, give them some space, right conditions  and things will happen, no? Well, noooo. Doesn’t really work like that – always. You see, some people confuse motivation and toothbrushing, and this is not the same thing. Your job as agile manager is to do both things, keep people motivated and engaged, and at the same time, sometimes, annoy people by asking them to be consistent. That is most of the time hard with things that they don’t like, part of the job that is not natural to their nature. In that case, motivation really doesn’t help, you need to use some other tricks, or like I put it here: “If you want to keep the ball rolling, make sure it is ticking.” In order to create a ritual behavior in the group, you need to do two things: make the outcome of the activity clear to everyone and fix the frequency when this activity is performed. So, let’s see how to do it:

  • Make the goals clear to everyone
  • Make sure everyone understand his/her part in the big picture
  • Give people space, autonomy and accountability (don’t ask folks to play piano with handcuffs around their wrists)
  • Make the checkpoints visible to everyone – such as percentage of the code tested, the number of bugs found in time, logging of activities in tools (in case you have multi site)
  • For each checkpoint define the activity and fix the frequency at which you want to review the results
  • Check the outcomes
  • GOTO 1

 

Tip: you can use the same methodology if you wish to loose some weight or prepare for the next year marathon. 

Do you need Chuck Norris in your team?

If you want to test whether you have Chuck Norris in your team, how about checking this blog post first. If you recognize someone in the team that fits this description, congratulations, this blog post is for you. Chuck Norris is really a lethal guy, and you should distinguish first whether your hero is only good in applying destructive force, or he is also trying to make any  good in the process of writing the code. One thing for sure, you have a guy with a great ego – and if you decide that the guy is worth trouble, you need to learn how to handle him (and don’t tell him that, as Chuck Norris doesn’t give a shit about management).

Before I continue, I would like first to say few things about myself and similar personal experience – not in software engineering, but in handball, which I start playing professionally when I was only 15 years old. When I was a kid playing handball, I had an idea that I can only trust myself, and when it was very important part of the game, I would simply take a ball and try to score, not thinking that much what other guys were doing (or thinking). One day, my coach came to me and said something that sticked to my mind to this day: “You know kid, if you continue to play like that, I will break your neck. But (and here is the funny part), if you don’t think that you are better than others, you will never become a great player.” And this is indeed the fine balance that big coaches need to manage every day in successful teams. In that respect, agile development is not that different from handball, it is a team effort where different people have different talents and you need folks that are willing to take a risk and score the goal.

During my career, I learned that there are two types of coaches. In first group are guys that I labeled as “Russian style coaches”. These guys would hate heroes and would ask every team player to surrender his imagination and personality to the benefit of the group, and then you would have team performing like a swiss clock, but just it was so boring to watch…  These teams had no Chuck Norris. And then, you had some other teams, where you would see fun, imagination and style. These were the great teams that we all remember. And occasionally,  you would see these great teams going loose, where internal fighting and argument would bring the complete team to the meltdown.

So, the question whether you need Chuck Norris in your team or not depends on two things. First part of the answer is about you, not him. Are you ready to take a risk and invest your time to get best out of him? That requires a lot of stamina and knowledge – and I will cover this in my next blog post.

Secondly, and even more importantly, not all projects require imagination and people looking to make the next big thing. Some projects just require pure execution, like a swiss clock.

 

This post was