Good design

Indexed does it again. Explains it like no other.

What you don’t evolve is being terminated

The quotation is better in Swedish, “Det som inte är under utveckling är under avveckling”, but still. Christer Olsson lectures in management and spread his idea that if you don’t evolve, you are becoming extinct. You cannot keep status quo without improvement. You can see the world as ever moving and if you stop still, you will not stay in your place but you will loose your position.

This is obvious to everyone who is struggling with agile or lean values, with the rule of constraint or Kotter’s sense of urgency. Evolve or die! But at the same time, it is easy to slip.

Some weeks have passed since my first 7 habits class, and during the first two weeks, I worked the habits, went through them in my head. But then they became mainstream in my head. I started taking them for granted. It is almost scary how little time it took. I came to a stand still. And I didn’t even notice it.

But one of the strengths of our 7 habits program is the learn through teaching part. As a part of our own training, we’re training others. I’ve picked two really talented developers with whom I’ve previously worked with and who are interested in management and leadership. And I know they are not just interested in a superfluous manor, they want to evolve in this area. This, alongside us sharing some experience around leadership in different flavors has made them interesting partners in this project.

I think I’ve tripled the gain of the class by having these discussions. Having worked with training for most of my professional career, this should have been obvious, but now it’s staring me in the face. I’ve covered all the habits with one of these guys but yesterday, I started with the first habits with the second guy. So, I had to turn back all those pages. Go back to the first habit. And I saw that I’d lost it. I’d let habit 1 go. By simply taking for granted that I’d already worked with that habit, I didn’t work as hard with it. I was not back on the level I was on when I started taking the class, but I was not as strong in this area as I was two weeks ago.

If I hadn’t looked back, reflected and understood that I was not evolving, I would soon have been back there again. This is a lesson I must not forget. And today I could again see the difference in my handling of a specific situation. My soon got too much vaccine when he got his flu shot today. I directly saw this as something I couldn’t do anything about. So, instead of badgering the staff, I instead kept calm, focused on Peter and awaited the information from the Swedish authorities. As I kept calm, I could see that the woman who gave the shot was not feeling well. She felt terrible about what happened and I could place myself in her situation. I tried to calm her by thanking her that she told me and I later called and confirmed that Peter didn’t seem affected. I did what I could about things I could affect and left the other things in the bin. Screaming about it would not have made the thing undone.

A sense of urgency

John Kotter stresses the importance of creating a sense of emergency. Working with the 7 habits program, this might seem like a really bad idea.

Urgency according to 7 habits

The 7 habits program divides tasks into four types:

I Urgent and Important – the crisis, stuff which is important and must be done “now”

II Not urgent but important – the strategic work, important tasks which must not be done at once, but if not taken care of is in the risk of becoming urgent.

III Urgent but not important – tasks which you don’t really see the point with but is urgent. This is mostly tasks which others want you to do.

IV Not important and Not urgent – these are the tasks which brings no value and which might bring a sense of wasting your time and guilt for not making use of your time.

The 7 habits program wants you to spend more time in sector II, since this avoids the I:s and creates a productive work profile. If you spend too much time in I, you will probably feel wasted and the rest of the time is spent in sector IV, since you don’t have the energy for anything else.

Urgency according to Kotter

When people think something is important, they can work harder and be more productive. By creating a sense of urgency, people uses crisis as potential opportunities. This can be a positive force in companies, clarifying what the objectives are and what they are not.

How to use a feeling of urgency

Most of us feel like we have too little time and too much to do. So, what should we prioritize?

it is very easy feel productive when you’re doing sector I tasks. You might feel like a hero, saving the day. You can avoid prioritizing since THIS is so important. But often, it’s not that productive. Too many sector I tasks are in sector II since you failed to complete them before they became urgent. This is also one of the points Kotter makes – you shouldn’t wait for the crisis to happen. You should sit, passively and just hope that things turn around. In other words, prioritize sector II tasks.

If you spend too much time in sector I, you can start thinking that sector III tasks are sector I tasks. You are so used to working with those hectic tasks that you fail to recognize what is important and what is not. You see something urgent and without really thinking, you take for granted that since it’s urgent, it is probably important too.

I’m currently working on an important project. It’s very important that we deliver on time and with the right content. And I want the people involved to feel a sense of urgency. This doesn’t mean that all the requirements are urgent or even important. These prioritized must be fully understood by the developers. By making them feel a sense of emergency, I also hope they can use this feeling to become more creative. This does not mean cutting corners and pushing defective code. It means that they can come up with new brilliant ideas and also discuss when they think that something is very time consuming so we can decide if it should be cut or not.

But the feeling must be shared with others. If other coworkers does not feel the urgency, they can easily distract my team with those sector III and sector IV tasks. It is so easy to see your own deadlines and tasks as important, but how important are they compared to other stuff? Context switching is one of the best ways to ruin a project. Once, I had a developer assigned 5 hours a week on a project. I declined. The context switching for this person would not make him productive and the others would spend too much time updating him every week. And how could he ever get that feeling of urgency if he had three projects at the same time?

My own conclusions are:

– Don’t mistake Kotter’s definition of urgency with the 7 habits definition

– Make Sector II tasks feel urgent! TDD, BDD, and what ever strategic software development techniques you wish to use must feel urgent, otherwise they will not be prioritized and then developers can start to think that the quality isn’t that urgent

– It’s hard to get a sense of urgency if you context switch too often

– You cannot get a sense of urgency if you’re alone with this feeling

– Developers will never feel that sense of urgency if they don’t feel and understand the objective. Excluding them from these discussions is contra productive.

Any other thoughts?

Teaching as a part of learning

One of the key parts of the Seven habits program I’m following is to include other people. The idea is that when you teach other, you gain a greater knowledge yourself. You need to reflect on the findings and referring them to another person. Also, this is an opportunity to test your hypothesizes on others.

So, I’ve booked a number of sessions with a former colleague, Morten. He’s a bright young developer from my former job, and we share a lot experiences, which we can base our discussions in. We’re also different; he’s a developer, he’s ten years younger and we will probably have to work the most on different habits.

Our first session was really interesting and even if we’ve discussed the concept of leadership so many times before, the discussion took a completely other route. Also, we discussed the personal choices in a broader perspective. To summarize; we both left the session with a bunch of new stuff to think about.

I’m also glad to see that Morten is sharing his ideas and experience with this collaboration on his blog. I’m really looking forward the next step!

Fighting Neptune

When it comes to leaders, I cannot help thinking about Gaius Julius Ceasar Augustus Germanicus, better known as Caligula. He was seen as the salvation after years of horrible leader, Tiberius. The people of Rome saw Caligula as their savior. His names in themselves promised a brave and successful leader.

It is said that Caligula started off well, but after two years, things were bad. He ruined state finances, killed and tortured his subjects. Of course, we don’t know how much of the stories around Caligula is true, but one of the stories which are thought worthy is the story of Caligula’s military “victories”. Carryingng all those fancy names, Caligula wanted to be seen as a great military leader. He wanted to celebrate a triumph, just like his predecessors. But the problem was that he cared less about being a great leader.

So, he went on a quest for a battle. But Caligula was not a military genius. The northern campaign had to be abandoned. According to Suetonius, the historian, Caligula had no problems claiming that he conquered both Germania and Britannica, but the prisoners displayed during the triumph were gauls, dressed as Germans and Britons.

But a mere triumph with mortal enemies was not enough. He decided to make war with the God Neptune. Having declared himself divine, he had no problems fighting this enemy. The story tells about the soldiers fighting the waves. They of course didn’t believe in Caligula’s delusions, but they all knew that questioning the ceasar meant certain death.

Today, we don’t know what is true of Suetonius story, but there are many lessons to be learnt.

Working with 7 habits, we discuss the core of a leader. A leader is not only a manager but also a person giving direction to others. I’m currently struggling with this in one of my projects. We have too many objectives, and it’s an ongoing task to describe, explain and discuss. Leadership should never be taken for granted. It’s a difficult and ongoing task.

What Caligula learns us is also that the name and the title does not make you a good leader. Yes, people tended to do what ever Caligula told them to. And for too many managers, this seems to be the essence of leadership. But what it can lead to is people fighting the waves with their swords and the celebration of false victories. A team victory should not be like the triumph of Caligula, just a show to fit his ego, based on a false history. A team victory is a victory which is felt in your bones, when you know that YOU have been part of something important and the real objective has been met.

In a couple of months, I hope my team will have that feeling; that we worked against that objective and that we reached it together. It was not easy, but it was all worth it.

The PI constant in software estimation

Already in 1975, Fred Brooks suggested in Mythical Man Month, Fred Brooks that you should triple any developer estimation. And reading blog posts, talking to fellow project managers and stressed IT managers, we all know that this is still valid. At the same time all these project managers and IT managers have a hard time accepting this. But from now on, you can refer to the mathematical formula of estimation. We all know it.

C=d*PI

Project Management Estimation = Software developer’s estimation * PI

Yesterday, we discussed this over lunch and one of the bright developers at TUI Nordic said it was the PI factor which wasn’t considered in project management.

 

 

If we see the problem as the circle we could say that we cover the problem by travelling from one end of the circle to the next. And that is what developers estimate. You could say that they are estimating the diameter.

But when they need to complete the task they have to take the route around the circle. Not only do they have to take a longer trip to reach the other side of the circle, they must also complete the whole circle and that was never in their estimate. You have setting up development environment, merging, build script problems and all that stuff which you never considered. That is the circumference of the task.

You cannot argue PI, can you?

Presence in the past does not help today

The previous weeks have been hectic, 7 habits classes, lots of meetings, trips and more meetings. I usually send a couple of days a week in the developer team room, but during this period, I’ve just come and gone.

It’s pretty amazing how fast you lose your touch with reality. Even if I’ve been down and said hi almost every day, I’ve not been a part of the every day hassle and questions and that is evident. I’ve become a chicken in just two weeks.

Scary.

Now, it become so obvious since the time between me leaving and returning to the team was short. But what if this would have been gradual? Or if I’d been gone for half a year? Or perhaps worst; if I’d never been a pig in the project? To be able to see that something is missing, you need to know what you’re missing in the first place.

So, I’m more confident than ever that the product owner IS a part of the team and not just as a happy fellow who drops by and says hi or just hangs around without making a difference to the actual work. A good product owner brings value to the team and the process and to be able to do so I need to be and work in the team room.

Well, you might think that daily meetings does it but I don’t think that this enough. Quite the opposite. If you’re a product owner who just comes for the daily standup, this meeting will probably be about informing you and keeping you updated.

So, what will be my measurement of whether or not I’m a product owner who is part of the project? Well, that is if I on most daily standups can share what I’ve done for that project and that is not only having meetings.