Mike Cottmeyer on Agile Project Management, Building Effective Teams
In this interview, recorded at Agile 2009, Agile Evangelist Mike Cottmeyer talks about some of the challenges that matrixed organizations often face when trying to build an agile team. He also describes his five-phase roadmap for scaling agile as well as "Scrum of Scrums," a mechanism that allows the organization to encapsulate multiple teams within the enterprise. While the US market is not yet ready for a full-fledged 'agile certification', according to Mike, there is still a great deal of knowledge to be gained from getting your PMP and Scrum Master certifications. When it comes to managing real world software projects however, there is perhaps no better teacher than experience.
The complete transcript of the interview has been provided below.
DZone: Mike, can you tell us a little bit about what you're working on?
Mike Cottmeyer: Aside from my work at VersionOne, out talking with clients and helping clients become more effective agile organizations, I'm doing a lot of blogging, a lot of writing. Conferences are coming up so we're doing a lot of speaking and talking. And I've got a book deal so I'm going to be writing a book over the next year.
DZone: You’d written some interesting articles on your blog about agile and scalability. Can you talk a little bit about some of the problems you're seeing in the industry around taking agile and scaling it across the organization?
Mike: One of the first things that I encounter quite often when I'm working with an agile team is that what organizations fail to do is to actually create agile teams, as kind of silly as that sounds. We're still dealing with a lot resource management, a lot of matrixing, a lot of local optimization kinds of problems. And so one of the first things that I look for when I'm going in to coach with somebody is can they form a cross‑functional team that delivers some sort of value to the organization? Teams just struggle with that because typically they're working for QA managers or dev managers or something like that, and they're matrixed across multiple projects. So if an organization can start with the concept of team and then build their agile enterprise around all of these agile teams, they've got a much greater chance at being successful.
DZone: What constitutes the ideal agile team in terms of roles and functionality?
Mike: The ideal agile team is basically a construct that means we're going to organize a group of people around delivering end‑to‑end features back to the business. So that team has developers, it has QA testers, analysts, UX people, product people, [and] customers -- anything that it needs to actually deliver that end‑to‑end slice. A lot of large enterprises, we're finding, are actually not organized necessarily around that end‑to‑end slice. They're organized around possibly like a component within a larger system's architecture, not a layer within the architecture but a major sub‑system kind of component. When I think of the ideal agile team, what I think about is a group of people that have everything necessary to be able to deliver some capability back to the business, whether that be a service in like a service‑oriented architecture, or a feature that a customer would actually consume.
DZone: There's often a sort of tug‑of‑war between the functional manager's needs and the project manager's needs in matrixed organizations. How do you achieve a balance between resource allocation there?
Mike: That's kind of a loaded question that you've asked because agile doesn't really talk about so much about the role of a resource manger or a functional manger within the enterprise. And it also doesn't necessarily carve out a really clean place for the project manager to insert in. Scrum basically talks about the team, it talks about the Scrum master and it talks about the product owner. Where a resource manager often comes in is that they have people matrixed into various Scrum teams. They're responsible for the people within their discipline, but those disciplines are out there working across the various projects. What a resource manager can do is they can focus on helping those people work within a single team and not try to split their time across multiple teams across the enterprise.
Because agile is built around this idea of teams working together, getting into a cadence, understanding each other, building trust, self‑organization, and what kills it is when managers are popping people out and allocating people to teams at 10% to 15%.
DZone: Mike, you've talked a bit about five‑phase roadmap for scaling agile. Can you elaborate a little more on that?
Mike: As we get out into complex enterprises, what we're finding is a lot of the guidance given by Scrum, XP is really geared toward just small teams. And Alistair [Cockburn] was talking about this yesterday in his keynote [at Agile 2009], we have to get past that small six‑to‑eight‑people dogma and start explaining how to do this in larger enterprises. Me and my writing partner Dennis Stevens, what we were articulating is this roadmap that you mentioned, where we start with the idea of teams, because I think as I mentioned earlier teams are the building blocks of agile organizations. We actually have to start figuring out how to bring projects through teams, rather then create teams around projects.
So the first level of the roadmap has to do with learning, organizational learning about how to create teams. What teams are, how they function, how to measure their performance, how to get them to work together.
The second level has to do with horizontal scaling. So now that we've got a team, we want to replicate that team out across the enterprise, so there's certain things that the organization has to learn about how multiple teams within the enterprise will play together.
The third level of scaling has to do with projects. Now what we've got to do is we've got to get those multiple teams across the enterprise working together towards common enterprise goals.
The fourth level has to do with portfolio management. Now it's multiple projects possibly spanning multiple teams. How are we going to coordinate those activities across the team to deliver those ultimate enterprise value streams.
What happens is, that's where it gets interesting. We start going past Scrum and we start looking at Lean. We start looking at Kanban, we start looking at the theory of constraint. There are lots of things up that level. And then you can take it one level further and the development organizations are no longer constrained. They're no longer a problem we're trying to solve.
And now we have to start looking at how we're to apply agile out to the enterprise. What does an agile marketing team look like? What does an agile sales team look like? What does an agile support team look like? Or an agile infrastructure team?
So what we're doing is laying this five‑phase model so we can engage with a customer and help them put together a systematic roadmap with specific learning outcomes at the end of each, so that they can have a very steady, predictable and responsible agile transition.
DZone: What are some of challenges associated with bringing together a agile team that can work through multiple projects, that isn't necessarily scattering or coming together based on project needs?
Mike: The most common objection has to do with specialization of skill sets. The example that everybody likes to throw out there is the DBA. That one guy that knows how to make the enterprise data warehouse run. I've encountered things where we've got a Flash developer or something like that, very specialized skill sets. I mean, those are real issues that organizations have to deal with. So one of the things about agile is that we try to get this idea of specializing generalists in place so that people can do more than one thing at a time. So that's my starting place. If we can get people that can do more than one thing, that becomes the nucleus of the team.
There have been situations where if that is indeed the reality, you have that specialist, that specialists becomes a constraint for the team. And we'll have to get them on a part‑time basis. Maybe we'll get them allocated within a sprint, maybe we'll get them allocated for the life of the project.
But that is the biggest challenge and that's why people want to matrix because they want that highly paid DBA to be busy all the time. And what happens is by time‑slicing him, he in effect slows all of the teams down.
DZone: Going back to that model of scaling agile, you've talked about this notion of of a “Scrum of Scrums.” How does that work?
Mike: It's interesting because I've been talking about the Scrum of Scrums idea for a while now. When I was at AgilePalooza last week with Jeff Sutherland and we talked about this idea of Scrum of Scrums. You know the guy that invented Scrum is sitting next to you, you get an opportunity to pick his brain. And he had the best explanation for it. The best I've ever heard and he talked about it as an abstraction mechanism that allows the organization to encapsulate multiple teams within the enterprise. The basic definition that we often hear about the Scrum of Scrums is, well the Scrum masters get together on a daily basis and they talk about impediments and resource usage.
I think Jeff Sutherland's explanation of the Scrum of Scrums gives us a little more flexibility. So on my blog I tend to write about four primary models. I talk about the Scrum of Scrums when there's no dependence between teams. A product owner team when we need to be able to coordinate requirements across teams. I don't necessarily like this title, but I call it a product owner with architects, when we need to be able to coordinate technical dependencies across teams.
The fourth kind is called an integration team where various parts of the organization actuality have to come together and deliver an integrated piece of software.
So the model that you choose for the Scrum of Scrums depends heavily on the kinds of dependencies that you have between the teams. Very low dependencies between the teams then we've got a very lightweight Scrum of Scrums. The more dependencies that we have, we have a little bit of Scrum of Scrums overall.
DZone: Switching gears a bit, Mike, you've written and presented quite a bit about project management. If I have my Project Management Professional (PMP) certification, does that give me the tools and skills needed to manage software development projects today?
Mike: I think what kind of the question underneath your question is, what is the value of a PMP certification? So I've been a PMP for five or six years and when I got the certification, to be honest with you, I wasn't a huge believer in certifications. The process in general is that you have to demonstrate a certain amount of work experience. You have to demonstrate a certain amount of education in the field. And you have to take what's a really hard test to be able to demonstrate that knowledge back to the Project Management Insititute (PMI). So what it really does is that the certification shows the dedication to your field and demonstrates that you have a common language, a common baseline understanding to be able to communicate with other project managers and the organization.
The PMBOK doesn't address software project management specifically. And it doesn't address software in the industry at all. Having your PMP, it doesn't necessarily prepare you to do that kind of work but if you have the background and experience in managing software teams in any capacity, having the PMP demonstrates that common language to make sure that you kind of understand the depth and breadth of what it means to be a project manager.
DZone: Is there a need for certification in the agile space?
Mike: I was involved a couple years ago with the APLN when we wrestled with the certification issue. And my belief is that, at least the agile community in the US is not ready quite yet for an agile certification. My personal belief is that, much like the PMP where it gives you an understanding of where you've been and a dedication to the craft and a certain knowledge baseline, I'm actually a believer in agile certification. And an offshoot of some of the work I did with APLN is that we actually put together an agile project leader certification. It was picked up and it's currently being run by the DSDM consortium over in the UK. The challenge with it is much like with the PMBOK or even with a Scrum master certification right now, is that what does it really say about your ability to run a software project?
And I don't think it says a whole lot about your ability to run a software project. But what it does show, it does show a commitment to your industry and it also shows that you have demonstrated a basic level of understanding in that particular knowledge space.
As long as we properly constrain what it is we're certifying, I think it's a great entry point to generate learning, to generate interest, to generate momentum. We just have to be careful about what it is we're saying about certified practitioners.
DZone: Now, Mike, you're working on book, which I believe is coming out early next year. What will it cover?
Mike: Yes. The book is tentatively titled "Rethinking the Agile Enterprise". And the five‑phase model that we talked about is going to be the core of the book. But then interwoven into that five‑phase model are several themes. One of the primary themes of the book is that we need to stop thinking about how we're actually doing things and start thinking about why we're doing them and what it is that we're actually trying to deliver. One of the things that I talk about quite a bit in this context is this role of product owner in Scrum. As agile goes into an organization and people try to scale Scrum, very often they say, "Well OK, we want to have a product owner on every team. We want to have a chief owner."
And they take the metaphor of a product owner very literally within the organization. When I look at the role of a product owner, what I see is an abstraction of lots of things within the business that are difficult to deal with. Things like prioritization, business alignment, proper elicitation of requirements and key design decisions. Those are the things that the product owner brings to the table. So I don't need product owners in my enterprise as much as I need those core capabilities within the enterprise to give the team proper input so that the can develop working software.
And so what our fundamental premise is that we can start breaking down those organizational capabilities that we need at each level. It might be a product owner and a Scrum master that we need to satisfy that capability. But if that doesn't work in our particular environment we can't just throw our hands up and not succeed. So what we want to do is look at those core capabilities and figure out how to scale those capabilities within the enterprise.
So that's probably the simplest overview of the book. And then we're going to run a couple of other themes around continuous learning and chain management and such like that. But that core distinction between how we're doing things versus what we're delivering in a scalable five‑step roadmap to enterprise agile adoption.
DZone: Well we look forward to publishing chapters from your book and talking about it upon release. Mike, what advice would you give to both aspiring software developer managers and those who are tasked with the very difficult task of managing software projects to their successful end?
Mike: One of the tings that I coach project managers on quite a bit is to gain as much as knowledge as absolutely possible. We can get very specific about whether we believe in Scrum, or whether we believe in XP or whether we're PMI guy or a DSDM guy or whatever. My general bend is that we need to understand as much about the different methodologies and all the different approaches. Because inevitably when we go into a enterprise context, we're going to have to inspect and adapt and choose situationally‑specific methods of delivering projects. And if all we have is the Scrum arrow in our quiver, we're going to be very limited. If all we have is the PMI arrow in our quiver, we're going to be very limited.
We're going to need lots of tools at our disposal to help make our organizations successful. To the extent that a new manager or new software project manager can expand their knowledge and embrace lots of different ways of thinking, I think that that's positioning themselves to be successful.
DZone: Mike, on behalf on the DZone community I'd like to thank you very much for your time today.
Mike: Thank you very much.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)