I am at Agile 2007 with Johanna Rothman, welcome. Please tell us what it is that you are doing these days, and what you are interested in.

I am a management consultant and the thing I focus on is risk: whether it is risk in the people that you have in the project, risk in how you manage the people on the projects, or the risk in the projects themselves. And that's what I do; help people see it, help people manage it.

How do you help them manage risk? You go in and coach people? You do courses?

Some of it is coaching; there are certainly workshops and training. I do assessment, actually a fair amount of the time, to really see what's going on and what are the causes. Because you can have any number of symptoms that come from very different root causes. And you want to know what is causing it here and now. Because sometimes you have great people, but they are not quite in the right job, sometimes you have processes all screwed up. That, you have got to manage. And sometimes you have people who just don't actually know what they are supposed to do or how to do it. And so you need to know what's the circumstance or the combination of circumstances here so you can help people get over that hump. Sometimes assessment is the right thing, sometimes training or workshop is the right thing, and sometimes it's coaching. I coach project managers, executives, sometimes Scrum Masters, although not as much. I don't focus on coaching Scrum Masters. So there are lots of opportunities to do just a little bit of work to help people get over that hump, and then they go merrily on their way, and then eventually they want me to come back and do more work.

You mentioned risk in relation to three things: people, management and projects. And I know that you are an author; can you tell us how your books relate to those subjects?

The first book I wanted to address was the one about people. Because if you don't have the right people on the project, you can't get the work done, that's just hopeless. That's why I wrote: "Hiring the Best Knowledge Workers, Techies and Nerds: the Secrets and Science of Hiring Technical People". (There's a funny joke about short people and long titles, I had that with that book.) The idea there is that there is a lot of bad ways of hiring people and then you get people in the wrong job, who might be very nice people, who might be able to do something else but they can't do the work that they were hired to do and so they become a huge impediment, a huge bottle neck for the organization. We don't want that. You don't want it if you are the person, and you don't want it if you are the manager, it's just a disaster all the way around. That's why I wrote the book, I actually started writing the book when I was working for a client and I was coaching a customer service manager, of all people, who said: "You know, I just can't find the right people. They are not out there, I am interviewing thousands of people (it wasn't thousands, it was tens), but I couldn't find the right people, and I can't get the right people and no one wants to work with me". And I said: "Have you done these things?" and he said "No". "Have you done those things?", "No". So I wrote out this little outline and he said "Oh this is really helpful, can you tell me more about this first thing: analyze the job?"

So he helped you write your book right on the spot!

Not quite that much, because you know how books are. But yes that was actually it, and so I had an outline of what I wanted to say and how to do it and that worked out really well. That turned into the "people risk" part of it. And then what I realized that you can get the right people in, but we have a lot of really smart people in this industry but people tend to be developer today, manager tomorrow, and all of your training is "here are the forms you have to fill out." You don't know how to do a one-on-one, you don't know how to give feedback, you don't know how to coach, you don't know how to organize the work, you don't even know how to have a meeting. So there's all kinds of stuff that you need to do as a manager, that as a technical person, even as a lead technical person, you have never had to do. And that is really important: how do you become a great manager, how do you practice being a great manager and how do you get feedback on whether or not you are doing the right things yourself.

Esther Derby and I wrote: "Behind Close Doors: Secrets of Great Management" which follows a theoretical but almost perfect manager through seven weeks of work, and then we talk about the tools and techniques that were used in those seven weeks. And that was good, and Esther and I have done a bunch of "Behind Closed Doors" workshops and that's been great, and then I realized that there were still a whole bunch of project managers out there who were formerly wedded to serial life cycles. These are smart people, they are not stupid people but they got stuck somewhere thinking: "First we get all the requirements". That's never happened to me, I've been in this business for 30 years. First we can try and get some of the requirements if we really have to do that first, but we are never going to get all of them and they are never going to be right. So what do you do with people who are stuck? The first thing they think about the project is the wrong thing and then that has implications for the entire rest of the way the project goes. So I wrote "Manage It. Your Guide to Modern Pragmatic Project Management" (which you will notice is a much shorter title). To address that, i.e. how do project managers make good choices at the beginning of the project, during the project and at the end of the project to really make it work?

You are on your third book, you are looking at the issue of risks on projects. Can you go into a little more details for us please about your new book?

Ok, so "Manage It! Your Guide to Modern Pragmatic Project Management" came about because I have been teaching a project management workshop since I think 1997, possibly 1996. And people, when they take the workshops, they say: "Well, I didn't know you could organize a project like that. I didn't know that if you thought about what's driving your project you might make different decisions about life cycles. I didn't know that you could time box in a serial life cycle or use continuous integration in an iterative life cycle, or do automated smoke tests in an incremental life cycle. I didn't know there were those life cycles". So since I have been teaching this workshop and of course evolving it over the last 10 years, it was relatively easy to write the book.

Those of us who write know "relatively easy" is certainly a relative term. But I was really interested in how do you do project management when you are not necessarily going to do Agile? My preference is that you use some form of Agile management and practices, because in my experience it reduces all the technical risk as much as you can, and reduces the schedule risk as much as you can. But if you can't, if you are stuck in an organization that insists on measuring you with gates and phases, if you are stuck in an organization where you at least have to start the project in a serial fashion, for a whole variety of reasons, the test are not available, the marketing people think they have to give you a five hundred page MRD, or if they haven't done their job, a two hundred page MRD and it is still about a hundred and eighty pages too big. How do you do this in an organization?

Your book is not another book on Agile. It's taking what you learned, the lessons you have learned from Agile and finding a way to apply it where the whole pattern won't fit?

Exactly. Because there are many organizations where the whole pattern doesn't fit, where either the people won't work in an Agile way. Or they say: "No, get out the garlic and the crosses, the Agile people are hackers". I don't want to fight with everybody and I don't want to label. I want to help people do what's most effective for them. Time boxing isn't a word that was developed in the ‘90s or even the ‘80s or even the ‘70s, time boxing has been around since time immemorial. So if you've had time boxes for a long time why not use them? Continuous integration is nothing new. I actually imposed continuous integration on a program I was running back in 1990, before we had good continuous integration tools and before we had really good version control tools. No, I didn't have a lava lamp and I didn't have CruiseControl, I didn't have any of that. But we could build every night and we could see what broke the build. And there are still organizations where they have to adapt continuous integration.

Say you are replacing a big chunk of a system that already exists, and people have to use that system. You are not going to put little bits and pieces in every single day. However you can take down from the mainline every single day into what this group of people is doing, that is going to replace this big chunk in the legacy system. They can keep taking down from the mainline, making their changes so that they are doing continuous integration. And when it's time to merge back, the number of merge collisions you have and the number of problems is significantly reduced. There is no need to do stage integration at all. Most people who see the value of continuous integration do this. Some people are a little stuck, you have to help them see "How could I do it here?" And so I put in lots of stories and lots of ideas and lots of things that I have done in different projects and that my clients have done in different projects to say: "Here's how it could work here, because here's how it worked in my organization, here's how it could work for you".

You have got an interesting chapter called "Schedule Games". What's that about?

In almost every project, even some of the Agile projects, you run into "schedule games". Now, in the Agile projects you tend to run into schedule games such as "We've got to have it, we're toast without it", which is when someone from marketing, or the product owner, somebody on the customer side, says: "Can we just fit this one more thing into the iteration?" and no one really says: "Well we can take something out to put this in". That's the management side of the schedule game. And the team side of the schedule game is: "We just can't say no. We love our customer, we want to do the right thing, we are team players, we'll suck it up..." the list goes on.

Those are co-dependant schedule games, because you tend to have "We've got to have it, we're toast without it" and "We can't say no" in the same organization. And what people don't realize is they just can make their lives so much easier. I have a little talk called "Geurilla Agile" using schedule games to help move the transition into Agile, which is not: "Here is how you really be Agile", and it's not a top-down approach, it's a way to get some of the ideas and practices into the organization. I think of it as priming the pump for the organization. And those two schedule games are actually great in helping people move from time-box to iterationiterations, especially shorter time box to iterationiterations, for ranking a product backlog, for helping the team learn how to estimate better. Teams don't get feedback on their estimation.

Never learn if they are doing a good job with estimation, so it's a five, it's an eight, it's a thirteen, it's a something. But if you don't know if your estimations are any good and you never have to go back and look at them, then how do you know if you are doing anything well, and how do you know what to trade off? And so, if you have a two-week iteration and someone comes to you in the middle of the first week, and if there are things that haven't started, maybe you could trade them off. But you have to know that your estimates are useful, you have to know that they are even close to accurate so that you can trade an eight for an eight, but you can't trade if you have a five in the iteration and someone wants a thirteen - you can't do that. That goes against the laws of physics. There are several, I think fourteen, schedule games that I go over: "Bring me a rock", "The queen of denial", "Hope is our most important strategy." You can't manage a project with hope. Hope and prayer might be helpful, but that's not a way to manage your project. You have to be able to see progress, get feedback, really understand what's going on, that's how you avoid the schedule games, and many of the Agile practices really help.

What's "Bring me a rock"?

"Bring me a rock" is a schedule game that, when you come up with a schedule for your project, and even Agile project managers Scrum Masters have to say: "Well we think we can do this much in an iteration; looks like eight, nine, ten iterations", you still got a date at the end. "Bring me a rock" says: you bring in your best schedule and then some senior manager says "Bring it in". And so you go back with your team and figure it out. Of course the first thing people say is: "Let's cut testing", like that's going to help you get the product done faster. It's not, but people work on it. "We can parallelize this, we can cut this corner, we can do this," none of that stuff ever works. And you bring in the date by two weeks. And you bring back the date to the senior manager and they say: "Not good enough".

You can do this until you are ready to pull out your hair, or you can ask a bunch of questions about what is driving this project, there are context-free questions to ask, you can say: "What does ‘done' mean? What are our release criteria? Let's make sure we are both talking about the same thing". You can move from time box to iterations so that you can get as much as much of the stuff done in priority order (preferably by value, not by risk), so that you can keep making progress as you go. And then when they say: "You are done", you are actually done with stuff, you just might not have got to the end of everything that you wanted. So "Bring me a rock" is a common schedule game I think. A lot of project managers get sucked into it. "Maybe we can be more effective," "Maybe we can go faster", which is another schedule game. It goes on and on.

I like this, it sounds like you are helping teams find a vocabulary for talking about the dysfunctions that happen when they're planning.

Yes, and the dysfunctions can happen throughout the projects, not just in the planning. So for example there is the "Split Focus" schedule game, where you think you have everyone on this team for some amount of time. And then they were supposed to spend some of their time on this project and some of their time on that project. That's the multi tasking schedule game. You can't focus on two things at once, I dare you to make one eye go over there and one eye go over there. You can't, it's not possible. But there are so many senior managers who because they multitask all the time, every day, that's their job, they have forgotten or really don't know that technical people need substantial time to really invest in the work that they are doing, they need to think. Sometimes thinking involves picking up a pen, sometimes thinking involves typing at the computer, sometimes it involves talking with other people, and sometimes people just sit back in there chair and think. And if they are constantly moving from one project to another there is no way. And that's crazy. Sometimes it happens where managers assign you two projects at the same time, just so you can't get bored. Very few of us actually get bored these days. Sometimes they can't decide which project is more important as in "Pants on fire".

Hang on, you have a game called "Pants on fire"?

Yes, "Pants on fire", actually Elisabeth Hendrickson or Tim Lister (I can't remember, I wrote it down in the book), named this game. I wish I were smart enough to name all the games, I didn't name all of them. [The names would be too long!] Yes, they would be, I suffer from long name-itis. But "Pants on fire" says: first senior management wants this project, and then a week or so later they want this other project as a top priority. And then they change their minds a week or two, or even three or four later. And so you keep moving from project to project to project, not getting anything done. We know how to deal with that: short iterations of one to two weeks, allow you to make a substantial progress on one project at a time. And then if senior manager is managing the portfolio, then that quickly which is hard to believe but it's a possibility, you can move to another project. That's the only time I actually suggest that you have an iteration end on weekend. Finish on a Friday or whatever the last day of your week is, and then you have a natural context ... of the weekend, so that when you come in on Monday you start a new project. Otherwise, I actually suggest teams finish iterations or have major milestones in the middle of the week. [To avoid the temptation of work over the weekend!] You bet, you got it.

Although you're aiming at less Agile, or partially Agile teams, or beginning-to-be-Agile teams, but you've mentioned things that are obstacles for Agile teams, too. Perhaps they are not facing all of the games in a way that some of the people are but if they are facing "Bring me a Rock", and who hasn't, this sounds like a useful resource.

I hope so. That was why I put the schedule games chapter in because I think if people have a name for something, even if it's a team who says: "Oh, our VP Joe is playing "Bring me a Rock" or "Queen of Denial" - which is yet another schedule game - at least you have a common vocabulary. And having a fun name, with cartoons (I actually had a cartoonist draw some cartoons for that chapter), I think helps people get a little prospective on it. I couldn't have named the schedule games unless I have seen them; and I have seen all of them - thankfully not all in one organization, but I have seen all of them over the course of my career, and I have been in, I'm pretty sure, all of them also. And having a vocabulary, and seeing I have alternatives, I don't just have to take this lying down, I could try this thing, and if that doesn't work I could try this thing, and if that thing doesn't work I could try that thing. For every schedule game I have at least four or five, generally more, possibilities. Try this, try that, try this, try that. And then it helps people say: "Ok I could probably work my way out of this schedule game". It might not be tomorrow, but it could be either in a week, it could be by the end of the iteration, it could be when we meet this particular milestone and if we just can have a common vocabulary, I can bring the rest of the team in. We can all solve this problem as a team, which really helps the team work in collaboration, of whichever team you are working with.