Kanban Kick Start

Simply wonderful description of Kanban. Thanks, Crisp!

Unsustainable pace

I had a chat yesterday with my best friend. As too many times before, she tells me about her husband working almost around the clock, weekends, holidays. And she always says “This is such a tough project. It will all change when this project is over.” She has been saying that for four years now. We’ve all been in episodes when we have to work very hard, spending evenings and even nights. But when this becomes the normal situation, you’re on the wrong track. You can perhaps skip that TV show you love but your spouse, your children and your friends will continue their lives without you if you’re not there. Is it worth it? And is it really effective?

A basic principle of the 7 habits program is the old story of the goose and the golden egg. In the story, a poor peasant have a goose which he loves a lot and one morning, the goose lays a golden egg. Bewildered with joy, the peasant can buy food for his starving family. But the next morning, there is yet another golden egg. And again, he’s filled with joy and can provide for his loved ones. As the days passes, the goose continue laying the golden eggs, one each morning, and the once poor man is transformed into a rich man. He no longer has to fight for survival and instead he craves the riches of the golden eggs. His greed makes him impatient and one day he cuts the goose open to get all the eggs at once. But there are no golden eggs in the goose. Instead he has killed the goose he loves and destroyed the resource which brought him continuous wealth.

In 7 habits, the goose is the production capacity and the golden egg the produce and the basic principle is that you need a sustainable pace and focus both on the eggs and the goose. If you’re fixated on the eggs, you will risk the health of the goose, and thereby kill it and loose all your future winnings. If you don’t work with the eggs, the production capacity will be useless, since it does not bring wealth.

For me, this story struck a core. Having worked with agile values for many years now, I of course know and have discussed the importance of the sustainable pace. And yet, I’ve worked too many times in environments where no value has been given to the production capacity of the resources. I’ve had managers who didn’t care if someone worked themselves to death. Literary. But what have they won in the long run? I’ve also worked in organizations where no one has cared about the produce, where managers haven’t bothered about people producing something of value. Who’ve turned a blind eye to employees wasting time and resources. Both are killers, in their own ways, and if you find yourself in an organization which does not addresses these issues, you are probably better off somewhere else. In some cases, you can perhaps be a part of the transition of the organization, but if your managers are not on the wagon or refuse to change, there is probably no use. You cannot make the change yourself.

Time is too precious to waste and time is wasted on an organization who does not realize that building a business is a long race and not a sprint.

A sense of urgency

I once worked for an organization, marketing their product as business critical. We spent a lot of energy and effort getting the customers to maximize their use of the system, something which made them dependent on the system too. When it worked, all was of course well and their productivity was amazing.

But the system was not fool proof and sometimes it just stopped working. It didn’t happen all the time but not as seldom that you would not get a bit used to it.

The first time, it was a real disaster. The customers and we consultants panicked. If the system didn’t work, our customers wouldn’t get paid, their customers would not be serviced and since we’d made them so dependent on the system, they didn’t have a really good process to handle this type of situations.

But when it happened again and again and yet again, the same situation wasn’t handled as an urgent issue. Oh, the servers are down. Too bad. We’ll work on it and hopefully the problem is solved soon. Indexed has as so often caught this in a simple image:

Since we let the failures happen too many times, we lost a sense of urgency. We knew the system would fail so we weren’t that serious about it. A real horror story was when a customer was left with a non working system for many days, not being able to bill his customers.

So, what happened to the customers? Well, first of all the trust was broken. We had stated that we would treat his system as business critical, but that was not how it worked. They lost faith in the product and I guess a couple of customers built a separate system for the times when the system failed. The customer staff of course lost all their trust. Many are stressed at work and need their critical systems to work. I guess they did not recommend this system to their friends and families.

Does this mean that systems cannot fail? Well, of course they can and they will but if you are building business critical systems, the likelihood of failure should be low and not functioning systems should be seen and handled as disasters. Of course that does not apply to all functions in a system. There are few really mission critical functions of a system.

When developing systems we must clarify SLA’s and identify these mission critical tasks in the systems. And we need to build a sense of urgency into our crew when disaster strike.

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.