00:35:27 video length
Bio Johanna Rothman, founder of Rothman Consulting Group, works with companies to improve how they manage their product development--to maximize management and technical staff productivity and to improve product quality. Johanna is a leader in the Agile community, having most recently chaired the Agile2009 conference. And she has written books on management, including “Manage Your Project Portfolio.”
The Agile 2010 conference is created by a production team of highly respected Agile experts and practitioners to present a program that spans the whole spectrum of agile practice.The Agile conference series is a organized as a program of the Agile Alliance, a non-profit organization dedicated to uncovering better ways of developing software inspired by the values and principles of the Manifesto for Agile Software Development.
They have to work a little differently because managing the people is - what do you do? Tell them what to do? We know that that part doesn’t work. The managers really have to manage the system. So there is the system of the project or the program which is "How do all these people work together?" They might be self-directed, they might be self-managed. Self-organizing really means it’s an ad-hoc team, but if they come together and understand how they work together, there is still the outer system of the project or program in the organization. The managers manage that.
That means that you have to manage the project portfolio, that means they have to help people understand how do you give feedback, how do you coach people, how do you get feedback and how do you manage the financial and HR systems all around the program and the project and the people. Because if you keep the people as the first thing, it’s not to say you keep the people happy, but you make it a great place for people to work. If you create a great system, a great work environment then people will do their best job. How do you make that system? How do you make that environment work for the people and the organization?
No. How many of us were told: "Hey, go make a great work environment." I don’t know about you. I suspect your introduction to management was much like mine. I went down to HR and they said "Congratulations, you are a manager." and I said "Thank you." They said "Here are the req forms." "Req for what?" - "Personal requisition." That was it and I learned how to do that. I also learned about how do you put someone on short term disability and long term disability, but nothing about how you make the workplace a great place to work. Did you get any of that?
These are different skills. They are not intuitive because all of us who have come up through the ranks have seen management that doesn’t do that, not because they don’t want to. Our current managers are not bad, they just don’t know. If you are becoming a manager, you might know you want something different, but you might not know how to get there.
I’ve been doing a lot of reading and I don’t quite have enough of my references. Brad Appleton has a really fabulous blog post. In his blog post he talks about self-managing and self-organizing. I think that there are also self-directed work teams where the team takes in the work and says "Here is how we’re going to do it." When they are self-managing, they say "Here is how we’re not just going to do your work, but here is how we’re going to manage our interactions with each other, our (I was going to use the word ‘policing,’ but that’s not the right word) ability to give each other feedback and to give each other coaching and to be brutally honest to vote people off the island when they are not working."
If you have a self-managed team, they are completely able to say to someone "JR, you’re not pulling your weight here. You have to do something different in order to pull your weight. If that persists, we’re going to have to get rid of you." If you can’t give that kind of feedback to a person on your team, you are not a self-managed team. You might be self-directed, because you can take in the work and manage it and do what needs to be done, but you’re not self-managed. Self-organizing, to me at least, means an ad-hoc team.
We realize that there is a problem, we realize we need to do something about this problem and we will come together as a team of people, work on this problem and then when the problem is over disband. That means that management does not appoint a self-organizing team. Management might say "Hey guys, we think you’d be a good team. Here, make yourselves a team." That’s one way of creating a self-directed and possibly a self-managed team. But that’s typically what we see in organizations - that the managers put the teams together, they don’t ask teams to come together.
A self-organizing team actually could stay together for a while, if they come together to solve a problem, such as a project and then move on to another problem, such as another project. That’s perfectly acceptable. It’s the how was the team created and how does the team really manage itself and manage how they bring people in and how they escort people out.
Self-directed teams I think are what a lot of Agile teams are today. Management put them together. They said "We think you guys would make a great team." They understand how to take in the work, hopefully in the form of user stories, they understand how to estimate together, how to commit to the work and how to deliver the work. They are not so good at giving each other feedback and coaching. Those skills still fall to the manager to either help with or have the manager coach or give feedback to the people who need to coach and give feedback. The manager still gets the meta-coaching and the meta-feedback and that helps the team turn into a self-managed team.
We are in IT, in the software industry for a reason. We got into this industry because we love to solve technical problems. We didn’t get into this industry because we were so good at the people skills. You are better at people skills than I am (maybe not), but I actually thought that working was going to be just like what I did in college. I got to sit down in front of a computer, I got to solve really cool problems, I got to say "Yay, I did it!" when I was done and I got to do more. It never occurred to me I was going to have to deal with people. What a surprise. Of course, now my job is mostly dealing with people because we can’t solve the technical problems unless we work with people.
If we can’t work with people, we can’t solve the technical problems. So you have to build your interpersonal skills as much as you build your technical skills.
I wish I could wave my magic wand (we are in Disney, right?). I could wave my magic wand and all these teams would be together. The first piece is that if you have a distributed team, if in all possible you have a cross-functional team, of all the skills you need in one location working with cross-functional teams with all the skills they need in other locations. Because that means you can distribute the project backlog. Each team has its own backlog and can deliver into the common code base or into the common project or program and that can work. We know how to do that, even if you have teams on the same floor, if they now become across time zones and across continents, that works pretty well.
Is it still harder than if you have two teams on the same floor? - Of course. Do you have to somehow do team developing among teams? - Of course. But it’s doable. What’s really difficult is when you have developers in one location across the space-time continuum from testers and from BAs or product owners. People write documentation and especially if I had put BAs and product owners together, but it’s really a problem if your product owner is time zones away from your developers and testers. I see that a lot, where the product owner is in one geographical location, the developers are in a separate geographical location and the testers are in a third geographical location.
I don’t know how you succeed except it takes forever to get anything done. That’s where I always suggest to people that you measure a very specific time -- the time that it takes to make a decision, to commit to something from the product backlog, for this iteration’s backlog. So you’ve decided what goes into this backlog and the time it takes to have that done as in accepted by the product owner. We’ll talk about other definitions of "done" later, but at least accepted by the product owner. Because my experience is that if you map the value stream, if you just look at all the delays, it takes at least twice the time when you have a geographically distributed team with functional groups in different locations.
My experience is at least twice, sometimes three times. It’s amazingly expensive and I’m not saying you get rid of anybody. But if they have testers in a geographical location, they probably have developers and if they have developers in a geographical location, they probably have testers. And then if you have a product owner somewhere, can you get that product owner to be with this team, can you train other people as product owners? If you have that big a program that you need people distributed all over the world, chances are very good. You need those cross-functional teams wherever you have some people.
That’s the really difficult sign of geographically distributed teams with Agile. If you have cross-functional teams in multiple locations, you just have the issue of communication. And that’s where you need to bring people together on a fairly regular basis, so that they make a personal connection. Without that personal connection, you can’t tell if I’m having a bad day and I’m being curt in email or if I’m in-between meetings because you’ve seen me and I’m quick answering your email. I’m not being curt or brusque, I’m just being Johanna.
We had a bunch of discussions by email and the good thing is you know me, so you know if I give you a three-word answer like "Yes, ok." That means I’m in the middle of something, I probably shouldn’t have checked my email, I did, I wanted to give you an answer. It doesn’t mean "Yes, ok." with the eyes rolling. It just means "Yes, ok." But you know me and you know what that "Yes, ok" means. You know if I say "fine" in the email, it means "fine," it doesn’t mean "fine." But until you have an in-person communication, some kind of way to build trust with the people, it’s really hard to know what these communications in email mean.
Skype or some other video-based communication helps a lot. In person is absolutely the best, but you have to build up that communication breadth, because otherwise you don’t know what the music is along with the words.
Project and program management are all about the delivery of the value to the organization. The project management is this relatively small group, maybe two groups of teams. When you need program management, you have at least three teams, probably more, that are working independently and inter-dependently. My next book is going to be about Agile program management because it’s actually very difficult to do. How many product owners do you have? Well, you need to have a product owner for the program backlog. Do you need to have a product owner for each team, for each team’s iteration backlog? - Maybe, maybe not.
But if you don’t have enough product owners can an owner for the program backlog actually have enough conversations with all the teams to be able to explain the user stories? Are the user stories epics in the program backlog? - Often they are. How do you break that down into something a team can do in a couple of days? You know me - I like user stories that can be done in one day by either the team or some subset of people. It’s perfectly acceptable to have a three- or four-day user story, but that just means it’s harder to do. That means that there is more conversation you need to have about that user story.
So, even if you have feature-based teams, not which is vertical slices through the architecture, not component-based teams, they all need to have their backlogs, they all need to know what "done" means, they all are going to be building the architecture as they build their features. How do you do that? Program management has all kinds of issues around risk, which is architectural risk, the basics of technical risk - "Can we even do this thing that we want to do?" never mind "Can we put together an architecture that doesn’t fall flat on its face?" and all the schedule risks.
That means "How do you talk about status when you have cross-functional teams delivering value into their piece? How do you then talk about status for an entire program?" I don’t have all the answers, that’s why I’m writing the book and working with clients. In Manage it! Your Guide to Modern and Pragmatic Project Management I talked about story boards because I’ve seen that work pretty well for programs where you are developing feature by feature. I haven’t seen a lot of other things. I’m working with some burn-up charts now, where you have burn-up charts for sets of features, which makes sense, but how do you say "We’re this much do these kinds of features."
If we’re talking about say a cell phone, which is my favorite example, if we have a billion features from how to make a call, if we are burning up through those features, what does it mean to have voice mail And we’re burning up to those. What does it mean to be able to take pictures and burn up through those? How do you see when you are all done for the program if you are working feature by feature? It can be hard to bring all that status together. Programs are not just larger than projects, although they are, they are much more complex. The issue of backlog, architecture, risk and status are the four biggies for program management.
There are people who have done Scrum of Scrums really well for even up to 20 teams. And there are people for whom Scrum of Scrums won’t work for three. So, it’s clearly one size does not fit all. How do you know what size you are? How do you know what you need to do? That’s the project and program management. Then, the management is on managing the system in which the projects and the programs and especially the people can be successful.
7. As talking in their largest base, as Agile becomes more successful we’ve crossed the chasm, it’s larger and more complex organizations. We’re dealing with the compliance driven organizations and so forth and they are all adopting Agile. What needs to change to make it successful?
This is where the system of work is to change, because if you want people to work in a team-based organization, where they are successful as part of a team, you have to reward them as part of the team. Individual rewards don’t make any sense at all. That means the whole system of HR has to change and the whole system of finance in the organization has to change. How do you give people bonuses? It’s astonishing: you say this to managers whose incentives line up with what they do through their teams, not what the teams deliver, if that makes any sense at all. It might not make some sense, so let me keep talking for a while.
The idea is that a team has this deliverable and the team succeeds based on its deliverable. The nice thing about Agile is you get the chance to revisit that deliverable every iteration. What if managers worked in iterations? It’s an interesting idea. Does everything lend itself to iterations? No. Lots of things actually lend themselves much more the Kanban queues than to iterations. But what if you could say "If we either do this small thing and then we’re done for now or we do this time-based thing and then we’re done for now." That could change the work of management and that’s a pretty interesting thing.
If you think about the project portfolio, that’s something near and dear to heart because I think multitasking is a sin, it’s really important to say "What do we have to do for now to really deliver value to the organization?" If the managers had to say "Every two weeks we will revisit the portfolio, but not more often than two weeks or four weeks, or once a quarter" - whatever the right number is. But it’s our job as managers to make this decision based on what we’ve accomplished so far in the organization and what we still have left to do. What is the most valuable thing that we could be doing?
A client of mine has a management team that does this. They have a backlog for themselves as managers - "What do we need to address now and what do we need to address in the future?" - that’s their backlog. So for a given four week period, because they work in four-week iterations, they work off their management backlog as well as putting stuff on the backlog for the future. If they have a crisis, they fix it. This is management after all, they are still supporting the rest of the organization, but it’s really important that they say, "We want people to write better user stories."
What does that mean? That means maybe we get training, maybe we do a retrospective that looks back at it. How did these people succeed and this team not so much. We can gather information and help people make better decisions about their user stories. The same thing for their interpersonal skills, the same thing for anything they want to do. So if that’s what they’ve been putting on their backlog and of course their backlog was filled with huge things like "build interviewing skills capability in the organization." You don’t do that in a two-week iteration. That takes time, so what did they have to do?
First they had to say "How often do we interview people? How often do we need to do this? Is it better to do this now? Is it better to do it just in time? What do interviewing skills mean?" They first had to break this down from an epic into several user stories and then they could start attacking it. They are working in iterations, which is working for them and they’re slowly but surely dealing with the obstacles that the organization, not because it’s a bad organization, has put in the way of these self-directed, self-managed teams, because the organization is not use to self-directed and self-managed teams. That’s what managers do. It’s an interesting problem.
It’s an enormous change. And of course, they are running into a real (I’m going to use the term) resistance, although it’s not quite the right term. I think it’s more confusion from their management. "Why are you working like this? If I ask you to do something, I want to hear about it tomorrow, even though I don’t actually need the results for another six weeks." Their managers are feeling threatened I think and certainly pressure to work more like the middle management team and less like the throw-it-downhill tailored approach to management. It’s a very different approach to management and it’s great for the people in the Agile teams. They are having a lot of trouble pushing it up and even if they don’t want to push it up, but just dealing with their managers it’s a problem.
The big thing is to be honest with your manager and say "Look, I don’t have to manage the day-to-day stuff with the people. The people do that. They know what their deliverables are, they know how to work together or I’m helping them learn how to work together. What you need me to do is manage and understand where do they need more skills. What is missing so that they could deliver better or faster? What capacity do I need to build in the organization?" The other thing my people need is a little consistency on what they have to do. I have to manage the project portfolio and that means I need this from you. So the first thing I think you have to do is trust or enable the trust between you as a first or a middle manager and the manager above you.
Let them know what you are doing because if you look like a black box that’s not a way to help them understand. If your manager doesn’t want to know, and just delivers to you stuff that you need, that’s fine, but most managers are not like that. I would absolutely recommend that managers one-on-ones with their managers every week, not more often than every week, but every week. Because you need to know what’s the strategy of their organization. Is it changing and all? What’s coming down and what information do I need to bring back so that as the teams finish work how does that fit into the strategy?
Or is it that we actually create a feedback loop from finished product work, which is what projects deliver back into the strategy of the organization, so we can evaluate the project portfolio, so we can decide to fund which projects, so we get finished work. That’s the feedback loop that we need to have. You have to tell your manager what’s going on. At the same time you have to make your work as transparent as possible, given all the normal caveats. Most organizations are not transparent about money, so let’s just deal with that separately, to the people with whom you work, to the project teams.
I think of managers as a champion for their team, one who helps create this system that helps create this work environment and protects the team in the sense of allowing them to do their work. Not to hold a barrier, but it’s a slightly permeable barrier, but not a highly permeable barrier. One of my clients had been doing Agile for a number of years and was really successful, got a new CEO and new VP of engineering - two guys who had worked together a long time and were very successful in other organizations. The VP of engineering said, "I don’t know anything about his Agile business, it’s a license to hack. You will go back to specs; you will go back to Waterfall."
They had very few managers and they were so surprised, so shocked by this they could not marshal any resources. They were just rolled over by this edict. Of course, they needed to hire many more managers and they went back to being a bloated organization and those folks have now since been fired and unfortunately a lot of the great people have left. So they have this fabulous intellectual property without the people who created it anymore. You want this slightly permeable barrier to protect people and to have data about what does it mean to successfully work in an Agile way.
Let me tell you about what it used to take for us from the time we committed to a feature to the time we delivered. In Waterfall or in most lifecycles that’s the entire project. In staged delivery you can get some features out earlier, but you still don’t have the entire project for that last little bit. In Agile, you commit, you deliver, you commit, you deliver and that’s a completely different approach. What does it really mean to have data? Because a lot of senior managers want data and that’s part of the manager’s job. What data do they need? Not just for defending Agile but defending a way of work that makes sense.
You might decide that iterations are too long and you want to work in Kanban queues. That’s perfectly reasonable, but you should have some data to make that decision. That’s what the manager is for: asking the questions, possibly gathering the data if the team won’t do it or can’t do it and protecting the team from really negative influences - people who want to change the project portfolio when it’s not time, people who want you to multitask on different projects, as a favor. You’ve gotten asked for favors and sometimes it makes sense to say "Yes." In that case you have to let the team know and most of the time it makes sense to say, "Let me put that on the backlog for the next iteration."
Creating that environment is what a manager is ideally placed to do. They don’t teach that anywhere, certainly not in business school.
I think by reading and by doing, and by saying "What do I need to do now for this team or these teams to be successful?" Having a retrospective with your teams to say: "Let’s look back in the last three months of your work. Is it something in the environment that could have changed, that could have made it easy for you?" It’s really important for a manager to see systemic obstacles from retrospectives because the systemic obstacles are the things that managers need to work on. Teams will say: "We can’t get our desks together because the furniture police won’t allow us." That’s an obstacle the manager can work on. The team is not going to get anywhere with that, because the team has no title-based authority, but the manager absolutely has title-based authority and can therefore do it. Those kinds of things is what the manager works on.
For this year, I’m really excited that I’m not the conference chair. I’m also really excited about my tutorial with George Dinwiddie this afternoon about coaching from multiple levels, because George and I were talking and he comes in more often as a technical coach, I come in as a management coach and we often do the other thing. I help people figure out how to do TDD or how to get to "done" or all that stuff and he talks to managers about managing the project portfolio, so it’s very funny. So we said, "Let’s do a session," because we learned a bunch of stuff so we are doing that.
I have a talk about Agile management, the essence of leadership and I’m doing a very short - 90 min - tutorial about Agile program management. It’s going to be a very fast simulation and then a bunch of debriefing so we can see what the issues are and how can you possibly go about resolving them. And then there is open space, there is all kinds of stuff I’m really looking forward to. I’m looking forward to a really fabulous conference and I hope you are too.
Thank you. It’s been a pleasure. Thank you Shane and thank you InfoQ.