Critical Chain, Agile, and Program Management

I've been doing some research for a project at work on Critical Chain (a result of my articles <here and here> for Projects at Work being noticed within the company). I started by re-reading Goldratt's book Critical Chain. If you haven't read it, I recommend it. It's written as a novel and is an easy read, but still has some good content.

What I've been pondering is how to use Critical Chain in Program Management. I've come across some agilist talking about Critical Chain and Theory of Constraints (TOC-Goldratt's work in manufacturing). Dave Prior recently wrote an article for Projects at Work on transforming to agile where Drum-Buffer-Rope (part of TOC) was mentioned. There was also Mike Cottmeyer's mention of Theory of Constraints I mentioned in a previous post.

So is Critical Chain the answer to scaling agility? When Mike talked about scaling agility at the PMI North America Global Congress last year, he argued that Scrum isn't the answer to scaling agility. Some other tool that can address constraints needs to be used. I think many of us have experienced resources being the big constraint in a program. Critical Chain provides an answer to this.

When using Critical Chain, your first step is to identify the constraint. Let's say it's the number of U/I designers you have. You can't run four projects in parallel because your two designers will be constantly pulled back and forth, and we all know multi-tasking is bad! Critical Chain would say that you need to delay some of your projects to address this constraint, even if this means other resources are idle.

It sounds simple, but will it work? How else can you address constraints across a program? Do we also need to be concerned with buffers? Goldratt spends a lot of time talking about buffers on the project level, including resource buffers. But how does this scale to the program level? Do we need program schedules with resource buffers? I'm going to keep digging in. If you have any suggestions, let me know.

Afraid of Falling

I was out climbing with my son earlier this week. He's home from college on break; he got serious about climbing last year and dragged me into it. My first route was pretty technical (for me) and there were a couple points when I was about to stop but I pushed through and made it to the top. When I got down, my son had some wise advice. He said I will improve if I don't worry about falling and If I'm not falling, I'm not pushing myself hard enough. 

I came across a set of videos on Yahoo; The Failure Club. This was created as a reality TV show that never got picked up by a network, but it's along the same lines as my climbing; go do something without fear of failure…even expect failure…and see what happens.

It's easy to play it safe at work. We don't want to stand out as a trouble maker or risk taker, especially during an economic slowdown. But is that the best choice? If we knew our boss wouldn't penalize us if we failed, how much risk would we take? What could we achieve? 

If you're like a lot of people, you came up with some resolutions at New Years. How many risky items are on your list? How many new things are you going to try? How many things that you could fail at? When I'm climbing and not having a good day, it usually isn't because I'm falling; it's usually because I'm afraid to try and I convince myself that I can't do it. So get rid of the self-doubt and don't be afraid. 

Caucuses

I am working in Iowa this week. Today, Iowa is the center of the universe…or at least the US.  For those that don't follow American politics, the Iowa Caucus is the first stage in selecting the candidate that will run against President Obama in November. Winning here is a good first step on a long journey.

How is your project political campaign going? Are you on course to win the election? While a political campaign is a type of project, most project managers have to handle politics as a part of getting the project delivered. A good project manager knows to pay attention to their stakeholders and figure out how to resolve conflicts between parties. They can respond effectively to a negative campaign and win the popular vote.

Ignoring politics can be a mistake. A project can easily be derailed by someone that has the right influence with the right person. This doesn't mean you have to stoop to the level of a mudslinger, but you should at least be aware of the impact they can have on your project.

So after today, Iowa will fade as the political campaign moves on. Good luck in the elections.

Scaling Agility

I recently had a couple articles (here & here) published in Projects at Work based on some discussions I had at the Project Flow 2011 conference. I'll admit going into this conference I wasn't an expert on Critical Chain. In one of my articles, I compared Critical Chain to Agile and came to the conclusion that Critical Chain is not a form of Agile. However, that doesn't mean they can't co-exist.

For those unfamiliar with it, Critical Chain is the project management approach based on Theory of Constraints (TOC), all based on books by the late Eliyahu M. Goldratt. Goldratt's books are interesting because they are written as novels, not text books. 

The PMI Agile Community of Practice had a tweetchat last week on scaling agility with Mike Cottmeyer. One of Mike's comments was about Theory of Constraint. Mike tweeted that at the lowest level in an agile organization are small projects using Scrum. At the higher level, TOC or Kanban can come into play as the work should take on more of a flow. Mike recommended reducing the dependencies between projects and reducing bottlenecks (full Tweetchat text can be found here for PMI Agile CoP members).

So what does this mean to you? One lesson to take from all of this is that we need to constantly keep our skills up to date. Earning your CSM is good, but not enough. You need to pick up on other techniques as well, so find a conference, pick up a book or two, or get involved with the PMI Agile Community of Practice. This way you can scale up your personal skills in agile. 

You Can't Learn Jazz from Wikipedia

I've been listening to a series on Jazz from iTunes University. It's been interesting because they talk about a topic and then play some examples of what they're talking about. It makes it easier to understand the difference between Hard Bop and Modal when you are listening to the styles as they're discussed. Even then, I don't think you really learn Jazz until you pick up an instrument and start playing.

This got me thinking about how people learn. I often go to Wikipedia to look up some fact. This is often the case when I'm researching an article that I'm writing. As helpful as Wikipedia is, it's not a place where someone can learn a skill.

I'm starting an engagement in which I'm playing the role of mentor. I'll provide the client some basic knowledge about running agile projects, the kind of stuff you might find in Wikipedia or a good book on the topic. But then I'll observe and provide coaching. I'll share experiences from my past that are relevant. At this point it is a true learning experience.

Passing a certification exam doesn't mean we have the experience to perform a job, it means we have the knowledge. It is by applying the knowledge that we gain the experience. Sometimes we have the ability to try a new technique in the office and see how it works, sometimes a new skill is forced upon us, and sometimes we need to seek help from a coach or mentor. 

As this year draws to an end, think about the skills you've developed and the experiences you've had. Has it been enough? Are starting to think about what skills you want to build next year? 

A Habit a Month

There have been studies that have shown it takes about 25 days of repitition to learn a new habit. So whether its trying to exercise on a regular basis or take time every day to keep up on advances in your field, it will take about a month to turn it into a regular habit. 

So here's a thought. At the start of each month, identify a habit you want to build up.  Work on it every day for the month. Next month, start on something else new. Or it doesn't even have to be new; it could be something you used to be better at that has become less of a habit recently.   

So keep it simple. Make this new habit the first thing you do every day, before checking email or your Twitter feed. It doesn't have to be a lot of time, keep it as short as practical. Prepare the night before, whether its laying out your workout clothes or finding the article you want to read. Just keep doing it for the whole month. When next month comes around, pick something new to work on.

Less WIP for better flying

I spent the end of the this week at ProjectFlow2011, a conference put on by Realization. Realization focuses on software and professional services using a Critical Chain approach.

The conference speakers were primarily Realization customers sharing success stories. One story that I found interesting was from Delta Airlines, primarily because I fly on Delta so much. The challenge Delta had after the merger with Northwest was how many different types of airplanes they had to support. There was almost no overlap between the planes Delta flew and the ones Northwest flew. Over the course of a year, Delta was able to reduce their cancellations by 62%.

One primary change had to do with reducing multi-tasking. Before the change, they would look at all upcoming scheduled maintenance on all airplanes every night and would perform any work that was on the schedule for the next 2 1/2 days. This meant each plane had some other maintenance due 2 1/2 days later. The change they made was working on fewer aircraft each night, but looking forward 15 days on each plane they worked on. By focusing on fewer planes at a time (less work in progress), they were able to keep all the planes running better.

There were a number of other companies that shared the similar stories and reduction of work in progress was one of the key tools used to improve project execution. I'll save some of the other techniques, such as buffers, for future blog posts.