Tag Archives: agile software development

Agile Project Management: What’s Up?

There is a great new site in town about Agile project management.

They are running a series of interview/guest posts on The State of Agile.

To my surprise, Peter from AgileScout.com reached out to me and asked me to be one of the interviewees.? It’s pretty amazing to be included in this list of Agile thinkers and practitioners!

The Questions:

  1. Your (author) background?
  2. How Agile has changed (from authors perspective) in terms of methods, philosophies, ideologies, pragmatic applications, etc.?
  3. Where is Agile going (in the future)?

Being of the contrary nature that I am, instead of responding with a blog post format I recorded a video with a mindmap on my whiteboard instead.

Click the image below to go to AgileScout.com and view the video.? Check out the rest of The State of Agile while you are there.

Tuesday 10/26 ? Tobias Mayer

Wednesday 10/27 ? Derek Huether

Thursday 10/28 ? Ken Schwaber

Friday 10/29 ? Josh Nankivel (Video!) and Sara Broca

Monday 11/1 ? Lisa Crispin

Tuesday 11/2 ? Mark Levison

Wednesday 11/3 ? Marcin Niebudek

Thursday 11/4 ? ?Matthias Marschall

Friday 11/5 ? Vincent D?Amico

SCRUM Concepts in Traditional PM


I wrote earlier about a potential method of using Critical Chain-stype “mini-buffers” within an element of a traditional project management approach. Now I would like to revisit multi-tasking and how having some experience with the Agile software development methodology called SCRUM has helped me formulate some guidelines. Some of these ideas come straight from Critical Chain too, and a myriad of other methodologies all pointing to the same conclusions.

First there is good multitasking and bad multitasking. Good multitasking may be an essential part of your job. Or you may be working on something where you really need to switch gears after a little while in order to recharge your batteries. Bad multitasking is really the enemy. This can take the form of fire-fighting, or just wandering around from task to task depending on how you feel that day. Both of these reflect a lack of proactive thinking when they occur in abundance.

What’s wrong with bad multitasking anyway?

I’m glad you asked! First, switching from task to task means that even if you are putting full effort into your work, the cycle time from start to finish on any given task is going to lengthen dramatically. See the following illustration for an example.


Second, when you switch from task to task, you introduce overhead into the equation, especially when you are talking about something in a manufacturing setting (Theory of Constraints, Lean) or if you are working on a highly intellectual task. It can take a long time to either set up a production line to run something different through, or remember where you were at the last time you left off.

Remember these are just illustrations and guidelines, not an ideology to be followed blindly. Obviously, there are many examples where you can not finish a task because you are waiting on someone else, for instance. Would you sit idle for a day until they get back to you? Of course not. Prudent judgment is required here, but avoid voluntary bad multitasking whenever you can.

So how can my project team avoid bad multitasking?

Here is where my experiences and research on SCRUM come in. One of the key contributors to mad multitasking is a lack of focus and planning. With SCRUM, each morning we would have a “war room” session for 15 minutes, with a very strict agenda. This is a small piece of SCRUM but a very crucial one. The leader would ask the questions and usually take notes so that he/she can help remove obstacles and have a good sense of what the team is working on that day.

The agenda consists of 3 questions, asked of each team member.

  1. What did you work on yesterday?
  2. What will you work on today?
  3. What obstacles or risks do you see?

This is not a meeting to discuss technical issues or even solutions. Usually 2-3 minutes maximum per person is what should be allowed. The lead should jot down issues or discuss afterwards in more detail.

The goals of the war room meetings are to:

  1. Foster excellent communication
  2. Allow for potential synergy in collaboration (by re-using code in software development, but parallels exist in all industries)
  3. Make sure everyone has clear goals and plans for their work
  4. Ensure the project manager/lead knows exactly what they need to focus on to remove obstacles and deal with potential risks on the horizon.

Done daily or perhaps a few times a week, this means that everyone has a clear purpose of what task they are going to work on that day, and it helps them focus on that and not jump around to other tasks. This is a good way to eliminate as much bad multitasking as possible by using a proactive approach.