Well I am Johanna Rothman I am the author of four books, "Hiring the Best Knowledge Workers, Techies and Nerds" the secrets and science of hiring technical people and no, I will never title a book that long again; "Behind Closed Doors: Secrets of Great Management" with Esther Derby; "Manage it! Your Guide to Modern, Pragmatic Project Management" and "Manage Your Project Portfolio, Increase Your Capacity and Finish More Projects" that's my most recent book.
2. Tell us a little bit about that book.
So that's the book about how do you figure out which project to do first, second and third, and most importantly never. Because many organizations have projects that have been going and going and going, and you wonder "Why are these projects still hanging around?" How come these companies, how come these organizations have never killed these projects? And sometimes you just have to transform a project, sometimes it needs to get split into two. You actually have two projects or I should say two products, masquerading as one product.
Well, you split into two each team takes one product and goes over there and is quite successful. And another team goes over here and takes this product and is quite successful with that. That's a transformation, good, let them go with that they have two audiences, they have two different classes of users, let them go, let them be successful. Great. But that's a transformation of a project. And then there are some projects that have outlived their successful lives, there is no more value in the backlog, just kill those projects, let them be done, declare success, declare victory, let them go.
Yes! Yes, declare victory, just say "We're done", or even better "We're done for now". I suspect that you and I have had parallel careers, even in different hemispheres in different companies, in different organizations, and we have tried to do things where we have bumped up against the laws of physics, we have tried to do things where we could not do that yet. I remember from my Master's Degree, all those many years ago, I wanted to do machine vision to inspect a sheet of music. Well it was a great thing to do but we didn't have cameras that could do that yet. And when I called - I did some research - and I called a professor at MIT because I lived in the Boston area, and he said "It's a great idea, we've been working on that for several years, the cameras don't exist yet". You're up against the laws of physics. And I said, oh nuts, I'd better do something else for my research and he said yes.
That is a perfect example of a project you should kill for now, you might put it on in what I call the parking lot, examine it later, take it out a year later, sometimes you take it out three months later, sometimes you take it out six years later. Sometimes you kill it permanently; but you put on the parking lot to say not now, just take it out of consideration, because when you are up against the laws of physics you just say it's not now, do not bump your head against the wall on this one, because it's not worth it.
4. What about the rules of bureaucracy and management? The Sacred Cow projects - those are the ones.
Those are the ones. See this is where you need influence; you might need cajoling and persuasion skills. And this is where it would be very nice if you could sa thaty management, all managers, make all decisions based on pure logic and reason. No.
The reason that managers don't do that is because managers are human beings, managers are the same people as you and I and everyone else out there. We are all human and I actually think that the more valuable, the more money that's based in the decision the less we are able to make the decision based on logic. The more we base our decision on - I don't want to say it's illogic, but on our emotion, I've been reading a bunch of books (and of course none of those I can remember the titles right now) but the more our emotions are in the decision, and the more emotions there are in the decision the more likely we are to own the decision with our feelings, the less likely we are to back up the decision with reason, and the more likely we are to take a stand on the decision, not based on principle.
So we are making unprincipled decisions based on emotions and not on fact. So what we have to do is get to principled-based decision making and evidence based decisions. And that means you can't go in to a decision and to a meeting biased and wave the flag and say we have to make this decision based purely on that. No, no, no, you have to start making friends with managers; you have to enter their decision-making mode and work on them a little bit at a time. If you go in there charging like a bull, you'll get a bull's reaction. The same people come and it will come all over you. And it's not going to be a pretty ending. But if you enter this situation and get people on your side, and say how can we make this decision together? And gently try and turn the situation, then you have a shot at making the decision together. Now those in the audience who know me are laughing; the tears are just rolling down their faces, because I am not known as the queen of diplomacy and tact.
Yes, you would definitely agree and the way I do this is to circulate possibilities in advance of the meeting. I always try and give people at least three options, and say what other options do you see? And that way no one feels backed into a corner, I have not said it's my way or the highway, that we use the rule of three all the time, and especially in decision making. So if we have three different options now people feel I am not backing anyone into a corner. If I give people a straw man decision, I say we could do this, we could do this, or we could do this, and maybe you have even more options before we even get into the meeting. Now people don't feel like I'm battering them.
So the rule of three is: if you only have one option you fell like you are trapped, two options is a dilemma, three means that you have broken through to logjam thinking and can generate more options. That's the rule of three to begin with. The rule of three says that if you give people options, now they feel like they have a stake in the decision too. So the more options people see the more they fell like "Oh, I could be a part of this decision making myself". Now this is different from don't bring me a problem bring me a solution.
7. But isn't that wonderful: Automatic punishment.
Automatic punishment. And the problem with: don't bring me a problem; bring me a solution is if I had a solution I would bring it to you. So I had a boss once who said don't bring me a problem bring me a solution, well if I had any solutions I would have brought them to him, he was pretty useless.
8. People just stop bringing problems.
Right. I want to know about the problem if I'm the manager. Otherwise I have put up a wall that says "I'm not interested in any of your problems; you go solve all of them yourself and don't bring me any bad news, because I don't want to hear it".
Well, you don't have to make the right decision; you can make the right decision for now, because you can change it. The thing about projects is a lot of people say "We have to make the right decision" and you do, you have to make the right decision enough of the time but the real issue is it doesn't matter how many projects you start, it matters how many projects you finish. So you have to make enough of the right decisions enough of the time, but if we were all really good gamblers, we could go to Las Vegas and make a ton of money. But I don't know about you, I'm not such a good gambler so I need to make enough of the right decisions and get feedback, get data on the projects, which is why Agile is such a fabulous way to do projects.
So we make a decision, we hope that it's right, get some data from the projects, look at the velocity, not that velocity is the only predictor but velocity plus the demo plus the value of the current backlog as it stands after the demo. So what kind of features did we finish, what does the product owner say about the value of the backlog after the demo, have we done enough for now in the project, could we ship it, could we release it, is it done enough, do we continue, do we make that further decision to continue to commit on this project? Now, we don't have to make this decision every iteration, do we continue, do we commit for a quarter at a time? For a number of organizations quarterly commitments is perfectly fine.
That helps the project team to say "Ok, we have a commitment for a quarter that we still want two week or one week iterations, that helps us with our rhythm if we want to do our demos, but at the end of our quarter we know we need to have made enough progress on our demos, on our backlogs that we are pretty happy with what we've done, we're really happy, we've done everything we need to do, we're really proud of what we've done, go forward"; now if our management says we need to do something different, well, we've done enough, we can release, we're happy, go for it, things are good.
10. You've also been talking about the Agile programs inside the portfolios.
Yes, what I've seen is that as people are becoming more sophisticated about their use of Agile, they of course want to extend Agile, not just to small projects, not just to managing which projects we do when, but say "Let's do big projects" and we saw that in our geographically distributed teams workshop [http://www.softed.com/Courses/Working-Effectively-in-Geographically-Distributed-Agile-Project-Teams.aspx] that, of course, as soon as you have geographically distributed teams is not because it's on one project, it's because it's on big programs, it's because there are teams here and teams here and teams there and we started doing it on our geographically distributed teams workshop.
Rebecca Wirfs-Brock and I are doing the Agile architecture workshop and it's all because I keep saying in my consulting practice there are big programs and I'm not talking about ten project teams I'm talking fifty project teams, eighty project teams, a hundred and fifty project teams, how do you coordinate all these project teams? At some point, can you make Agile scale? And I believe the answer is yes, and I have tremendous respect for Scrum, but you cannot just say "Just do Scrum of Scrums" because at some point that does not scale, because it's not just the technical teams, that is not sufficient, you have to somehow get Marketing and Sales and Training and Deployment and everyone across the organization, Legal, Finance. How do they all come into a program team across the organization and that is just a program across the organization not just the software program, how does hardware come into this? And what happens if you think you only need three turns of the hardware but then you end up needing five? What happens if you have firmware, why can't we go Agile on a hardware-software-firmware product?
Those are the questions that I'm working with some of my clients, this is a non-trivial problem, it was non-trivial when we did it, I never used waterfall to do it, those of us who did programming and trained people we didn't used waterfall then we're not going to use waterfall now. And we might not use pure Agile now but as I have done in the past, we've blended what we needed to do. But I think we can be more Agile than we have been in the past and the question is what fits for the context, as always.
11. So how do we set up that right environment for a large program in an Agile space?
Well, I think carefully is the first word. I think the key is you can't scare people. At one of my clients, the VP of product development took me aside and said, "Johanna, I've known you for a long time, none of that Agile garbage, ok?" I said, "Oh, no, not from me", thinking "Ok, but your guys are doing iterations", they're doing two week iterations, they called me in so that we would be more Agile but none of this Agile garbage, ok, why am I getting mixed messages here, so I said "What are you concerned about?", I figured I would ask that question.
He said "I don't like those stand ups"; I said "What is it about them that you don't like?', he said "They seem like a waste of time", I said "What is it that wastes the time?", he said "I still need to know the status", I said "What is it that you are not getting?", he said "I want my metrics", I said "Ok, so if I make sure you get your metrics, is it ok if the teams do their stand ups?", he said "Yes", I said "Ok, I'll make sure you get your metrics, but let them do their stand ups". He said "I want my spreadsheets", I said "Ok, you'll get your spreadsheets because they still have to do a bunch of roll up spreadsheets", because they happen to be doing a bunch of stuff on their local boards so they can see stuff as they do their stand ups and they have to do a bunch of roll up spreadsheets because they are geographically distributed and they have to integrate a bunch of stuff, but this way they can see stuff while they're right there.
And he was worried about his spreadsheets, ok, I mean they have to do some stuff that rolls up so I said "You'll get your data" and he really does manage with data and because he has 2,500 engineers over five or six countries over many time zones, he really was worried and he has the right to be worried, he needs his data.
Yes, and that managers have a right to be worried, they have a right to want their data, I don't know if it's cause or effect or what's been successful and what's not been successful, but they have a right to want their data.
13. What about funding for programs of work?
Well, this business of incremental funding is a huge piece and I know a fair amount about incremental funding, I'm learning more all the time, I'm actually learning a lot here [at the Agile 2011 conference] and I do know there is no silver bullet, at this time there is no tool, so people are just going to have to figure out how to do this with spreadsheets and pencils and paper. I am not aware of any tool and one thing that you and I have talked about at great length is that if you cannot do it manually you cannot put it into a tool.
So if you can't figure how to do it on a quarter by quarter, or if you have to do on iteration by iteration basis. manually you cannot put it into a tool, so first figure out how to do it and then tool-alize it, automate it; that was the right word. So I think it's really important to first figure out how to do it manually.
I think the first thing to do is figure out what is the problem they are trying to solve and a lot of the problem they are trying to solve is unpredictability in the budget. So if you're trying to solve a problem of the tax payers are only giving this much money, which for the government is a big deal.
15. Yes, at the moment it's getting less.
Yes, and that is the pot. So when you have this much money in the pot everyone wants to know what's their share, the problem is everyone is playing the zero-sum budgeting game and what everyone is optimizing below the level of the organization. So how do we have some transparency in the government? Well, I don't know if that's a solvable problem in our lifetime but I think we can solve that problem in private industry as opposed to solving it in the government. Government I don't want to touch, this is the US, if you've been following the news with the debt ceiling, let's just not go there.
But in private industry we can solve that with some transparency because we want to optimize at the highest possible level, that's really key in private industry, we shouldn't have to play the zero-sum game. Now I know that a bunch of your clients are actually in New Zealand and Australia are government.
17. Hiring for Agile teams, how do we get the right people into our teams?
So this is really a big deal. I was having a conversation with someone yesterday and he said in the US at least we have this big problem of unemployment cause we are at ten percent and when we are fully employed we have five percent unemployment, that's only a five percent difference, and this is in the high tech sector, so this is really a problem.
The kinds of people that we need in high tech in Agile teams are highly collaborative, are willing to try something and get a little feedback on it, are willing to, I don't know if set aside their ego is the right thing, cause Lord knows, we have quite the egos, but this business of taking small steps and asking for feedback, this is hard work, being collaborative, getting feedback and I think the key is how do we help people learn to be Agile in our teams, how do we hire for the right attitude and instead of looking for tools, looking for people with the right tools, how do we look for people with the right attitude, or look for people with enough of the right attitude and enough cultural fit so that they can fit into our organizations, and we can help them adapt.
18. HR departments are not good at that. So how do we help them?
Well, I'm thinking about writing another little eBook about doing that, and that's something that, depending on my fall, I might have enough time to do.
Yes, watch the space, it's something on my list but I have to figure out what my project portfolio is like.
I think it's a business of trust. Building the trust among the people on the team is key. I think that figuring out how do we help the people who are over there figuring out how to trust the people who are over here is the biggest piece. And part of that is how do we call the people over there, if you call them "Them", oh boy, if you call them "Headquarters and remote", you've just killed it. What do you think the biggest thing is?
Which is crazy, if nothing else you can put webcams in. You look at the travel budget and then you look at the cost of one week of delay in your project, just look at the cost of one week of delay and then look at the travel cost to get everyone together for one week and compare the two and pretty soon you'll see that getting everyone together for a week doing release planning and then compare the cost of one week of delay and see what that real cost is and pretty soon it looks like a wash.
The velocity goes up dramatically. What's so funny is that managers get together all the time and they are not the ones that need to be together, but they don't realize it. They realize how much more productive they are when they are together, so let's get the teams together too.