So I've been using my home Kanban board for about a month now. As I suspected, it is a bit of a challenge to use a physical board with as much travel as I do. My approach so far has been to review the board before I head out on a trip, figure out what will be in my working queue, and capture that electronically. When I get back home, I update the board. I think I have to go to an electronic version of a kanban board, but I haven't looked into that yet.
I've also started reading Personal Kanban by Jim Benson and Tonianne DeMaria Barry. I'm almost done and it has given me some other ideas.
One idea is setting up a special flow for different tasks; in my case when I do writing. My writing takes on a different flow than just from doing to done. I found with writing articles or papers, I go through a step of laying out the outline, then I go through a first draft where I try to get my thoughts on paper, a second draft where I try to make my thoughts more coherent, and a final review to check grammar, punctuation etc.
I also like the idea of having a "Today" column. That gives me the ability to look at everything I have going on that day - tasks, meetings, work in progress - and decide what else I think I can get done.
One area I still need to improve on is capturing all my tasks. Right now I am only putting the bigger tasks on the board, not all the little tasks I have going on. I think I need to do this to really get the full effect. In general though, setting up my personal Kanban has helped me get more organized.
Wednesday, June 22, 2011
Tuesday, June 14, 2011
Shuhari
I've written in the past about the rules of jazz. I've come across another similar concept that has surfaced in relation to learning agile techniques; Shuhari. The ideas first gained popularity in the martial arts, but is being used these days when discussing agile. Alistair Cockburn has been an advocate of this idea (link).
Shu is the first stage, when a pupil is learning the technique. The emphasis here is practicing what was learned. This reminds me of the new Scrum Master, running their first projects following the techniques they developed in training. Having a coach would be beneficial at this stage.
Ha is where we start to think about what we've learned. We may start to bring innovation to our technique. In jazz, this is where you start taking solos and improvising. In the project setting, it is where you start bringing in new ideas.
Finally, Ri is where we discard the structure learned in the first step and take our own direction. We are no longer the student but the practitioner.
A key part of this approach is that it is a journey. As a project manager, you will face challenges if you try to move right to Ri without practicing in Shu and reflecting upon it in Ha. I have always been an advocate of selecting the right approach to manage a project based on the details of that project (a Ri action). However, to be able to do this, a PM must understand the tools in their toolkit, which they build in the Shu step. The Ha step is where the begin to understand how a particular approach works in a given situation.
This isn't a one-time journey either. I know as I adopt new techniques, I have to go through all three stages. Learning Scrum is a good example. I was already a project manager when I learned Scrum. I went through Scrum training and applied what I learned (Shu), then I started holding retrospectives with my team to reflect on how things were going (Ha), and then we modified our approach on new projects (Ri).
Shu is the first stage, when a pupil is learning the technique. The emphasis here is practicing what was learned. This reminds me of the new Scrum Master, running their first projects following the techniques they developed in training. Having a coach would be beneficial at this stage.
Ha is where we start to think about what we've learned. We may start to bring innovation to our technique. In jazz, this is where you start taking solos and improvising. In the project setting, it is where you start bringing in new ideas.
Finally, Ri is where we discard the structure learned in the first step and take our own direction. We are no longer the student but the practitioner.
A key part of this approach is that it is a journey. As a project manager, you will face challenges if you try to move right to Ri without practicing in Shu and reflecting upon it in Ha. I have always been an advocate of selecting the right approach to manage a project based on the details of that project (a Ri action). However, to be able to do this, a PM must understand the tools in their toolkit, which they build in the Shu step. The Ha step is where the begin to understand how a particular approach works in a given situation.
This isn't a one-time journey either. I know as I adopt new techniques, I have to go through all three stages. Learning Scrum is a good example. I was already a project manager when I learned Scrum. I went through Scrum training and applied what I learned (Shu), then I started holding retrospectives with my team to reflect on how things were going (Ha), and then we modified our approach on new projects (Ri).
Saturday, June 11, 2011
Adjusting Goals & Re-planning
I ran the Chicago 13.1 last weekend and while my time was not very fast, I did make it across the finish line; which was an accomplishment under the conditions we faced. Because of heat & humidity, the race organizers actually stopped the race. Only about 130 people (out of 4000 starters) "officially" completed the race before is was stopped. I crossed the finish line after the clocks had been turned off.
Preparing for and running this race was a lesson in adjusting goals and re-planning. The original plan was to run the race with my son. By March, we abandoned that plan because he got an injury and wasn't able to train. So I set a new goal of running under 1:45 and targeted my training toward that goal. On race morning however, with the temperature already climbing to a humid, sunny 80 degrees before the start, I knew if I went out on my target pace, I would pay for it later in the race, so I went slower right from the beginning. I ended up about 7 minutes off my target, and I was pretty tired at the end, but I made it.
So how often does this happen in projects? We start out with a goal, and as events unfold, that goal is no longer attainable. Can you recognize the need to re-plan, or do you keep marching toward your original target, not admitting that the situation has changed and your plan won't work?
I was consulting on a project last year where it became obvious that we would miss the target date. This information was presented to the executive steering committee, but they wouldn't allow the date to change. I think their logic was that if they let the date change, everyone would start slacking off. We missed the date, but still no one tried to come up with a realistic goal. It turned into a death-march where everyone was trying to deliver to an impossible goal. Fortunately for me, I had moved on to another project by then.
Did the executives achieve anything by keeping the pressure on? I doubt it. The morale was sinking with my team members as the project moved forward. In the race, the people that didn't adjust their goals were disappointed. People I talked to missed their target by 20 or more minutes and were really suffering at the end. When faced with reality, it's better to adjust a goal to be achievable. That doesn't necessarily mean easy, but if everyone knows the goal is impossible, the race is already lost.
Preparing for and running this race was a lesson in adjusting goals and re-planning. The original plan was to run the race with my son. By March, we abandoned that plan because he got an injury and wasn't able to train. So I set a new goal of running under 1:45 and targeted my training toward that goal. On race morning however, with the temperature already climbing to a humid, sunny 80 degrees before the start, I knew if I went out on my target pace, I would pay for it later in the race, so I went slower right from the beginning. I ended up about 7 minutes off my target, and I was pretty tired at the end, but I made it.
So how often does this happen in projects? We start out with a goal, and as events unfold, that goal is no longer attainable. Can you recognize the need to re-plan, or do you keep marching toward your original target, not admitting that the situation has changed and your plan won't work?
I was consulting on a project last year where it became obvious that we would miss the target date. This information was presented to the executive steering committee, but they wouldn't allow the date to change. I think their logic was that if they let the date change, everyone would start slacking off. We missed the date, but still no one tried to come up with a realistic goal. It turned into a death-march where everyone was trying to deliver to an impossible goal. Fortunately for me, I had moved on to another project by then.
Did the executives achieve anything by keeping the pressure on? I doubt it. The morale was sinking with my team members as the project moved forward. In the race, the people that didn't adjust their goals were disappointed. People I talked to missed their target by 20 or more minutes and were really suffering at the end. When faced with reality, it's better to adjust a goal to be achievable. That doesn't necessarily mean easy, but if everyone knows the goal is impossible, the race is already lost.
Subscribe to:
Posts (Atom)