Multi-tasking and Kanban

I was at a presentation on Kanban put on by the local agile group tonight. I'm familiar with Kanban, but still picked up some good information.

One thing that struck a chord with me had to do with multi-tasking. In a previous blog post, I've discussed how multi-tasking doesn't work. In tonight's presentation, a statistic was shared that software developers waste 20% of their time when they are multi-tasking.

Kanban is the solution. The idea is you only take 1 task at a time and work until that task is done before you grab another one. You don't have a long backlog of work and you're not trying to manage a full plate of work with all the task switching that goes with it.

I find I'm more successful when I take this approach to work. At the beginning of the day, I figure out the tasks I need to accomplish. While I'm working on a task, I do my best to avoid interruptions. I ignore my email and avoid other distractions (or at least I try). I'll catch back up on email and other stuff when the task is done. It helps when I can keep tasks to an hour or less. If it's a big project, I break it into smaller chunks.

So if you find you are often interrupted, look at how you can break your work into small chunks and turn off the distractions while you complete your task.

Tools & Communications

I had a recent discussion with one of my fellow IT & Telecom SIG board members on a budget item. There was a mis-understanding between us which stemmed from the use of an electronic poll in one of the tools we use to run the SIG. We were using a tool instead of having a conversation, which lead to mis-communications.

I've been working with a couple new clients and the tool topic has come up. My advice is always to get practices down before trying to use any tools to support your practice. One of my clients is using note cards on a white board to manage their stories, and it's working for them. They have a dedicated room for the project, most people are on sight most days, so the technique is working. Inspect and adapt can also mean continue to do things that are working well, don't change just because you can.

As for the SIG, I'm going to change the process for approval of budget items to include a conversation and not just an electronic vote. This will give people the chance to ask questions, clarify assumptions, and make a better decision. It's like user stories - a reminder to have a conversation and not a detailed requirement. Without the conversation, you're going to run into problems.

Keep it Short

This past Sunday, in conjunction with the PMI North America Global Congress, I hosted a Pecha Kucha night on behalf of the IT & Telecom SIG. This served as the launch event for the new PMI Agile Community of Practice.

Pecha Kucha is a style of presentations where you have 20 slides, each lasting only 20 seconds. This was the first time that I, or the other speakers, had given this type of presentation. We all agreed it was fun, but took a lot of work to get right.

I think this brings up an important point. How often have you received a very lengthy email where you couldn't figure out the real message? Like presentations, good writing requires effort. Trying to deliver your message in a short, concise format requires you to really work on refining the message. I think people get lazy with email, throw something together, and expect you to figure it out.

One exercise I like at the start of a project is developing an elevator speech. The idea is to be able to clearly define the purpose of your project in a couple of sentences. The challenge again is to make that message clear & concise at the same time.

So next time you're sending an email, take the extra time to read it through and decide if you are getting your message across in a concise manner. If not, you need to make it shorter.