Project Cage Match: Multitasking vs. Critical Chain

Last week I was able to participate in University of Texas at Dallas’ 9th Annual PM Symposium. It’s one of my very favorite events (this was my 4th time) because the audience tends to come back year-after-year and many of them come back to see me. They’re very supportive, participative, and it’s a good time.


This year I spoke about the problems with multitasking. I will post a link to the paper after they may it public, but in the meantime here are the slides. Enjoy!


Lightweight agile only needs 2 goals

Most of the time, developers want to deliver useful software. They want their business partners and end users to be happy, even delighted to use their software. They struggle with this. Sometimes forget this. I haven’t worked with everyone, but for every developer I have worked with and gotten to know, this is true.

Given this, a desire to make customer happy with useful and delightful software, what would I do if I went back into IT management? If the desire was right and the software development practices were not effective, then I think I would introduce 2 ideas. I would not send everyone to agile training. I would not introduce stand-ups, paired programming, or burn-down charts. I would not change the language. All of that is too difficult. Too heavy.

What 2 ideas would I introduce to my team? I would insist on just 2 things. Here’s what I might say . . .

First I want us to develop a new review & feedback system. On a regular basis, we need to review what we’re doing and figure out how to do it better. Sometimes this would cover the last hour, when we where in a meeting. Sometimes it would cover the day, so tomorrow will be more effective. Sometimes it will cover a week or one month, so we make sure we capture the big and important issues. And to make sure we are on the right track we will also hold an annual review to check our overall direction and strategy, too.

Second I want us to start integrating code into the trunk multiple times a day. Anything less than twice a day means you’re in too many meetings! The reason for doing this is to reduce risk, because if you’re spending time working in a silo then you are adding or ignoring risk.


So, why these 2 ideas? Why did I ignore the rest of the principles surrounding the agile manifesto? Because everything the agile manifesto wants is covered in these two ideas. I am both forcing change and giving them a means to talk about the problems and incorporate the differences into their processes.

The first idea I will introduce is all about giving them the foremost thing a team or company, an individual or company needs is the ability to review it’s process and work, to honestly assess the output and performance, and be able to improve upon what they’ve done.

The second idea I will introduce is all about forcing fast feedback. Jez Humble has said, “If it hurts, do it more frequently and bring the pain forward.” It was counter-intuitive for me, but I finally learned he is right. We need to stop avoiding the painful parts of the process because we are making it worse. For example, if integration is difficult, waiting makes it more so. Do it so often the issue becomes irrelevant.

By requiring continuous integration as my second idea, I force the team to look at their environments, their tools, their permission structures, their process, their tests, their requirements, and more. Each change will cascade other changes, and in so doing, push the group to accommodate the greater needs. We may never call what we do “agile” even though I expect, with some time, we will be living the agile dream!


Okay, this is my dream. What do you think? What’s missing? Can you convince me even these 2 steps are too heavyweight?

Blow-up the Iron Triangle

I am presenting at the 7th Annual UT Dallas Project Management Symposium being held August 15-16, 2013. 

The conference theme is Project Management: Optimizing Value to Stakeholders. I thought this topic, Blow-up the Iron Triangle: Rethinking Software Project Approaches and Goals to Increase Business Value was not only catchy, but very relevant to the theme.

My inspiration was Jim Highsmith’s article, Beyond Scope, Schedule, and Cost: The Agile Triangle. It’s a great introduction to the concept and I expand on it a little bit with an example and the implications. I want to give a big shout-out to Jim for reviewing my accompanying paper and giving feedback.

You are welcome to download the paper and view the accompanying presentation below.