By Dave Prior
Editor’s Note: You can choose to view the video or read the transcript (provided below).
Dave Prior: Hi. My name is Dave Prior and I’m chair of PMI’s IT & Telecommunications SIG … About a week and a half ago, I was fortunate enough to be able to attend the 2008 Scrum Gathering in Chicago. It’s an event where about 250 practitioners of Scrum get together to share ideas and thoughts about what’s working, what’s not; ways to promote it, bring in other agile practices; how to make it just all around better. I wasn’t really sure what I was going to experience walking into it, being as I’m a PMP-certified, waterfall-background project manager. But I was very, very surprised and happy to see that it’s not just [a bunch of] developers and agile-minded developers who hate waterfall guys. There was an even mix of project managers and software developers; a fair amount of PMPs [and] non-PMPs who consider themselves project managers. But overall I found the environment to be very welcoming and friendly, which was a nice thing because I wasn’t really sure that was going to happen. I learned volumes at this event and if you get a chance to attend this or one of the agile conferences, I absolutely recommend it. It was a great, great learning experience.
While I was there, I had an opportunity to sit down with Mike Cohn. If you’re not familiar with Mike, he’s one of the rock stars of the Scrum world. He’s one of the founders of the Scrum Alliance; [at the time of this interview he was] serving on the board of the Scrum Alliance. He runs Mountain Goat Software and he is also a Scrum certification trainer who teaches all over the place. I took Mike’s class last year and it was a great time—I got a lot out of it.
When I sat down with him, one of the first things that I asked him was, “For a project manager who is just coming into the agile world, just kind of becoming aware of it, what is the best place, or the best way, for them to get started understanding what’s going on and how can they break themselves free of that waterfall mindset that would basically lead them to believe that a lot of agile practices are basically taking your hands off the wheel and seeing what happens?”
Mike Cohn: Well, I am associated with the Scrum community, as you mentioned I am a founder of the Scrum Alliance. One of the things I like about Scrum is that it’s a good place to get started. Scrum is kind of the default agile process in a lot of ways—it’s been around the longest. I like that it is the lightest-weight kind of starting point. We don’t start out by mandating you do twelve different practices or anything like that. Scrum, at its heart, is really just about getting a team to be iterative and once you’re iterative then moving towards becoming agile. So I really like Scrum as the starting point. Although, as much as I like Scrum, my preference is actually for what I call unbranded agile. I just kind of wish all the brand names would go away—Scrum and XP and Crystal and everything else—and we just call it agile software development, or even better just call it software development. But for now, we still have the brands and Scrum is the right starting point in my mind.
In terms of getting started with Scrum, Ken Schwaber has three great books out on Scrum. But what I really like is for somebody to read one of those and then go to something like a class. I’ve always thought that I could do a great two-hour Scrum training class if I could get somebody for one hour at the end of one day and then one hour at the beginning of the next day. There’s something that happens when you sleep on it over night. You know, I couldn’t do a two-day class and get somebody’s mind changed, but if I could get them to get the right things, kind of sleep on it and come back the next day, I think you could kind of start shifting your mindset away from traditional thinking towards a more agile mindset.
Dave Prior: I took Mike’s Scrum certification training in Dallas last year and I was the only project manager in the room, which surprised me, I was sort of expecting a lot more. And I asked him, generally when he teaches a class, what is the mix? Is it mostly developers, mostly project managers, or maybe a mix of both? Here’s what he had to say about that.
Mike Cohn: Well, the mix is really different. If I teach a public class (you know where I rent a hotel and invite people to just show up in my classes), the mix there is probably 70-80 percent on the management side. It’s either a project manager or it’s a tech lead who soon would be a project manager, kind of thinking in the traditional way, and a few developers that show up—but typically skewed toward a people who are in leadership or management positions at the public classes.
When I’m invited into a company to talk, one of the ways I structure the classes and just do my pricing with companies, is I want everybody there—it might be three managers and twenty technical people there—because I’m trying to get the whole team mindshift to happen. Earlier, when I started doing this I’d have companies that would say, “OK. You price per person, we’re going to leave the testers out.” I’d say, “No!” Right? And so I would price per day, right, with people, because I want the whole team there. … Otherwise, people don’t hear it. One of the things I’ve found with training, having been doing this for a long time now, is I have to be careful with what I say because people will hear the one sentence they hear, they doze off from the rest, and you’re quoted back the one sentence out of context that--people hear what they want to hear. And so I really want all the groups there. So when I go in to work with a company, that’s how I set it up, I want everybody there. So I typically don’t just teach just a management class inside a company. But those choosing to come to a public estimating class or ScrumMaster class, much more on the management side.
Dave Prior: One of the projects that I’m working on right now is a Scrum project that’s being run inside a waterfall organization. So everything within IT is happening from a Scrum perspective and that’s going off like gangbusters. But we still have to find ways to communicate with the folks upstairs, the people who want to see Gantt charts. And Scrum’s great, but they have to able to know when everything is going to be done.
Obviously there’s a lot of conflict there and one of the challenges that I’ve had in working on it is trying to find a way to come to grips with the fact that, yes we’re doing an agile practice or Scrum, but we’re doing it in a place where we still have to be able to answer to people who want to see a Gantt chart or a network diagram. So I asked Mike if he had any tips for project managers in a similar situation. How do you address that? How do you deal with the fact that you are doing an agile methodology inside an organization that is anything but?
Mike Cohn: There are a lot of myths in agile about things like, you know, “documentation is horrible.” Documentation is not horrible, right? The Agile Manifesto says we value working software over comprehensive documentation. It doesn’t say get rid of all documentation. And a lot of agilists are opposed to Gantt charts and things like that. Those are mistakes. Gantt charts are wonderful communication tools. So I don’t go in and want to try to change how a, how a company looks at things.
I was working with one company that had maybe twenty projects going on; they were experimenting with agile on two of them, and when I got there the two agile teams were trying to change the, kind of the, dashboard reporting that their VP wanted. I was like, “No. You’ve got eight teams doing it the other way, eighteen teams doing it the other way, you figure out a way to make yours look like theirs. “ Right? You don’t have to go in and change all those things as part of this initial battle. Again that’s part of starting in a lightweight manner and kind of pushing to constantly improve.
So a thing like Gantt chart is an absolutely wonderful way to communicate; it’s a horrible way to do day-to-day management. I’ve always had an issue [with a situation where] a project manager would walk in and say, “It’s Tuesday. The Gantt chart says you’ll be done with this. I don’t know what ‘this’ is but where’s you’re corrective action plan because you’re not done?” Right? None of us think that’s a good way to go. But as a way to communicate overall progress and just kind of map out high-level expectations, it’s wonderful. So I don’t necessarily look to change a lot of those things.
Dave Prior: In places where I’ve worked where agile has been a part of the mix, it’s normally been introduced by somebody from the development side. And walking into that situation as a project manager who is certified in being able to do things from a waterfall standpoint, it’s a little bit of an uphill battle for me, especially because you don’t have a developer background.
So I asked Mike, walking into that type of situation, if you’re a project manager and you’re not a software developer, how do you overcome that? What steps can you take to kind of even the playing field so that the developers who have brought agile in, or turned to it, turned to Scrum or XP or whatever it is, how do get yourself raised up to a level where they see you as an equal as opposed to the waterfall guy who is just going to be in the way?
Mike Cohn: I think if we make up a list of all the desirable attributes of a, kind of an agile coach or what Scrum teams would call a ScrumMaster, on a project, certainly having the knowledge of how to do the job is on the list. Right? I mean, I would love to have, even in a traditional world, I would prefer to have project managers that have done the job in the past. It’s going to help you when the team says, “ten days,” when a developer says, “This’ll take ten days.” And if you know something about it you might know, you know, “Is it really going to take twenty and this developer just isn’t seeing part of the problem?” Or maybe you’re looking at it thinking, “[wow] ten days is kind of a long time for that … is he sandbagging…what’s going on?” So having technical knowledge of things is certainly a desirable attribute, but there are so many other things that need to happen on the project, that that’s just one of many factors for me.
I mean, I’ve hired plenty of project managers into agile teams that did not have a technical background, a coding background. Right? They knew how to manage people; they knew when somebody said ten days they could look at their body language and other things. You know, is the guy confident in that? Is he kind of looking down at his feet? Those type of things that help you make up for that. Just knowing people is a big advantage there. So to me, technical ability is just one of many attributes-- love to have it, but to me it’s not a make or break aspect there.
Now in terms of the project manager, I don’t typically see a project that needs both a project manager and a ScrumMaster. Right? Typically the project manager becomes the ScrumMaster if they have that type of process and impediment removing desires. If the project manager is somebody who’s worked in that company or that domain for a long time, and they really know something about the product or customers, they shift into more of a product owner role, defining what we’re going to build. A lot of times, project managers shift in either direction.
Dave Prior: And if you want to find out more about Mike, here’s where you can go to learn more about him, Scrum, Mountain Goat Software, all of it.
Mike Cohn: The easiest place to find out about me is www.mountaingoatsoftware.com. … I’ve got a ton of presentations up there; every time I teach at a public class like this, I put my slides up there and sample chapters from books, and things like that. Good site to [visit].
