Archive

Archive for 2009/06/05

First impression of going Kanban

2009/06/05 2 comments

I can admit that going scrum for me can be described as the following process:

  1. Well, this is not hard
  2. Why don’t anyone care about this but me? Why do I even bother?
  3. Oh, crap. I’ll just go on and try to make it work.
  4. Ok, it doesn’t work cowboy style. Let’s go hard core.
  5. Great…. Flow… Finally it works.

This took me about a year. A hard bought year, both for me and the project. But when we finally went Scrum all the way, it actually worked like clockworks. Great. I loved it. Then everyone started talking about Kanban. Oh no, a new buzz word. But scrum worked so well? I started collecting links on delicious but never took the time to actually read them. Why should I. Scrum works, doesn’t it?

Yes, it does. Sometimes. But sometimes chaos is overwhelming. And either you fight the currents or you just go with the flow.

Scenario: one project with one team. A rather long list of requirements of which we know we cannot do all. And there is a bug risk that the resources can be grabbed by other projects.

Can you do scrum during these conditions? Well, perhaps you can, but why. This is perhaps a project manager’s worst nightmare. But still, I sleep tight at night.

So, what did I do? First, I explained the situation to the stakeholders. We are low priority. We will lose developers on the way, so we don’t know what we’ll get. Then I asked what they wanted most. And the answer was two features. These brings most value to the customers. And then I took those features and divided them into smaller chunks so I knew which parts of the features were the most important. You could use story writing seminars and the user story form for this, but I didn’t think this would bring more value to the actual description. But that is beside the point. The point is that I didn’t build a product backlog. Instead I just created a pile of requirements and could bring out the most important thing in the pile.

That story went up on the board first. I told the guys: we all work on this. So, they divided the task between them and started working. Within half a day, half of the crew were off on incident hunting in another project but the rest could move on. So, they kept on that item until it was completed. When that was completely done, we put up the next thing on the board. Half way through that task, the guys were stuck. They needed the guys stuck on other projects. So, we put that task on hold and moved on to a new task.

So, what have we gained? By not pushing a deadline or an estimate, a developer cannot hide incomplete work by “well, I did not have the time due to delivery”. We deliver when we’re done. Not a second before. So, I think we’ll get better quality. Also, we’re not stuck with many unfinished tasks but just the bare minimum. Incomplete work is waste. You cannot avoid it all the time, but here you focus on this. We’re not crippled by losses of resources. It effects how many tasks we can do and if they have different competences: which tasks. But we don’t miss the delivery. We also give the stakeholders to change priorities often. So what if they come running with new stuff: this only means that we change the queue. Since the guys are just working on one thing, we can change the very next task if they want to.

So, what do you miss out on? Well, fixed deliveries are great if you want to plan acceptance testing. But to what use is acceptance testing if what you test is crap? You also have the risk that the guys never stop working on one item, polishing it too much. But here it’s important to be present and describe what you want and what you don’t want. And this is no different than scrum.

So, what was the process for going kanban (up til now)?

  1. Why should I care?
  2. But this is just like scrum, so why bother?
  3. Now I get the difference. But where is my control???
  4. Blizz. I would have gone mad on this project if I hadn’t gone Kanban.

I’ll get back to you on further progress!

Advertisement
Categories: Agile, planning Tags: ,

How the mighty fall

The other weekend, I read Jim Collins new book, How the mighty fall. It is sometimes said that we shouldn’t focus so much on the success stories because we can learn so much from the failures. Jim Collins book From Good To Great was actually based on the comparison of successful businesses and failing businesses but since the advice pointed at what brought greatness, you perhaps did not focus on the stuff which brought failure. And this is where How The Mighty Fall comes in, it describes the steps some of the most successful business have taken on their journey to rock bottom. Some of them where actually also described in From Good To Great as examples of businesses going successful. That might seem contradictive, but as Jim Collins puts it; previous grandness does not bring continuative greatness. Quite the opposite; the first step towards failure is a belief that you are so great (that you can not do wrong). We call this hubris.

The next step is undisciplined pursuit of more. Grasping for new businesses without reflecting on if the business can handle this or not.

Stage three is denial of risk and peril. Often it’s not until now the decline starts to show. The insiders in the company might have seen “that the company isn’t what it used to be” during stages 1-2, but in this stage it really starts to show. Often the leaders complain on everything outside themselves. It’s the recession, or that silly customer who didn’t buy, or that employee who didn’t do what he should.

Stage 4 is grasping for salvation. Here the company tries a new product line or take radical steps “to turn the ship around”. But all the steps are taken in panic and if this continues, the company is heading for stage 5.

Until now, the research made by Collins team shows that the ship can be turned. But here it’s often too late. Here is capitulation. The company is bought or goes under. Or remains as a small shadow of its former grandeur. 

This week I also attended a seminar on crisis management. My company and our customers were stricken hard by the 2004 Boxing day disaster in south east Asia. No one could be prepared for such a disaster. But you can prepare for crisis and have tools for handling crisis. One of the many things I’ve proud about TUI Nordic is the crisis management. It goes from the management, focusing on and prioritizing the handling of the unthinkable but probable: the incidents no one wishes, down to the individual employees volunteering to be part of a crisis network which steps in and gives support to the organization during crisis. I dare say that at least on a Nordic level, TUI Nordic was one directly involved organizations which handled the crisis best. And this was not a coincidence. It’s hard work.

While I sat there, listening to how we work during a crisis, I realize that the crisis described in How The Mighty Fall are no different from the crisis that arises in the form of natural disasters, accidents, crime etc, which we train for in the TUI Nordic Crisis volunteer program. What Collins describes is when crisis hits a business and like any other crisis; the outcome is much controlled by how you handle the crisis. We cannot bring back the dead, but we can take care of the survivors. We can perhaps not make the missed sale undone but we can make sure that what ever made the customer go away is changed in the future.

Handling a crisis is taking care of the core problem first. And in the case of a falling company; it’s about understanding what the problem is and trying to fix that. Not looking at oneself and thinking about how good one is. Not blaming the recession. Not grasping for short term solutions which does not help in the long run.

I met with some managers from a company in decline the other day. They think they are in a temporary recession (blaming the recession game) but have not understood that there are more basic problems and that the problems arose many years ago. I actually tested the stages on them. First they stated that they were the best in the business. I asked them how they knew this. The answer was. Hm, well, we’ve been that for many years. Yes, we can say that we are best. Hubris…. Yes, they were best a couple of years ago but the competition has reached them. I already knew that they’ve tried marching into new customer fields, before reaching the needs of the current users. So, I knew that step two was checked. Then we come to stage 3. Denial. They’ve taken some steps to cut their costs by cutting staff hours. One of the department consists of 2,5 guys and a director. But cutting director costs is not an option. When asked if this is a long term solution and if this helps in the long run the answer was just that the recession is soon over and then everything is smashing. They are also building a new product line and I asked if the customers were more satisfied with the new product. The answer was that they didn’t know but one can measure customer satisfaction based on if people pay. So, you spend a fortune on a new product and you don’t know if the customers are happy about it? The problem is deeper than the number of staff.

In TUI Nordic, we have a saying: What you think can be seen. And if you think that a customer is happy just because he pays his bills, this shows. The customer knows he’s not worth more than the money on the bill. And the customers of 2009 want more. They want respect and a caring supplier. And here I think one of the core problems for the company in my example is; if the managers don’t care about the customers, do they care about the staff? And how does the staff behave towards the customers if the managers don’t care about them or the customers?

Categories: Agile