2. Could you tell us about yourself a little bit?
Sure, as Mike said my name is Mike Cottmeyer I am the Vice President of Pillar Southeast, and when I do training a lot what I joke is that I ask people what their real title is and what their Agile title is, so my real title is again VP of Pillar Southeast but my Agile title is coach, Agile transformation coach. So I like working with large organizations, helping them figure out how to do this kind of stuff to scale.
Prior to joining Pillar I was with Version 1 and what we do is we go out into these larger organizations that have purchased software and they are trying to figure out how to really run an Agile organization. And what I would find quite often is that there were a lot of teams out there doing Agile and they are trying to figure out how to get teams working together effectively so that the velocity of the team level corresponds to actually value a larger enterprise level and so I got kinda passionate about that and so a lot of what I have been writing on for the last year, year and a half is really in terms of how do we take Agile beyond the team? When we have dependencies between teams in larger complex enterprises, how do we handle the coordination mechanisms of cross teams, and in a way that preserves business agility. Because often what happens is that people don't understand how to do Agile across multiple teams, large complex enterprises so they start doing very non Agile kinds of things, prescriptive, waterfall kind of heavy weight architecture, large small upfront planning than we would like. So figuring out how to maintain team level agility while still having business agility, I think it's the next problem that we are trying to solve in the Agile community right now.
Quite often if you look at the guidance surrounding scaling Scrum and things like that it almost assumes that we have a product organization, and that features all necessarily roll up to the top and it's kind of hard to explain that without a white board, but the organizational structure around you and the nature of your business impacts quite a bit, how you need to adopt Agile when you go past the single team. And so what I find more often than not that I am recommending to customers is Agile at the team level, maybe Scrum at the team level, if Kanban is interesting to you and you think that ads value then we can do Kanban at the team level, but what we are really learning is that the value stream, the enterprise value stream is not encapsulated within a single team. So when the value stream is more complex and I have got multiple teams that play, then I need a mechanism for being able to manage how value comes out of the organization, when it's again just larger and more complex. So, often times I am talking Agile at the team level and I am talking Lean/Kanban across teams and even multi level Lean Lean/Kanban where we have an enterprise value stream we might have a product level value stream maybe an operations value stream and then all of that enterprise kind of tracking as cards move through then goes down into team level product backlogs.
So, the way that I kind of think about this is that, this is often hard to do if you don't have some sort of top down intent within the organization. S lot of times Agile gets adopted at the team level and in effect really becomes a local optimization within the enterprise. The team's doing great, they've got great culture, maybe they've got a coach or something like that, but when you get in you start to figuring out why they are not ultimately successful because they've got all these dependencies with the rest of the organization. And Scrum is really designed to minimize these dependencies or encapsulate them within a single team. So when you are dealing with multiple teams, again this is where the top-down intent comes in, we need a little bit of organizational design, so where you can make intentional decisions about where to spend Agile teams, where it makes the most sense.
And I've been doing a talk of Better Software this summer where I talk about several scaling constructs to deal with project level management, product level management, where we create almost like a higher order team, call it a product team or an integration team, something like that, Scrums of Scrums a little bit. Although I think that's a little bit different, where this is actually a team which is iterating or, whatever, pulling or whatever it's compound and they've got a flow of value at that level. And that team's job is to break the backlog up, get it allocated out to the teams and then they are also responsible for making sure that the team's output is rolling up into some enterprise deliverable like a value story or something like that.
So, the one that I tend to come back to quite a bit, I give David Anderson credit, back in the early 2000s I read his book "Agile Management", we've been doing a lot of things in that space in bringing the idea of theory constraints to Agile I think is really key in dealing with that explicitly. Because very often what happens is when you have multiple teams in Agile environment and those deliverables have to roll up; what ends up happening is that one or more of those teams will become a constraint. And if I've got a constraint team in a multi-team delivery kind of environment it doesn't do me any good to get better at the teams that are doing well. So that's not where I want to invest coaching, that's not where I want to invest maybe even in tools or in process or anything like that.
Shat I want is to find the constraint parts of the organization and elevate those so they can start producing at a level that helps me get value out of it. And it gives me a language for being able to talk to customers about, you know, where do we need coaching, where do we need not, what's doing well, we can visualize the flow of value and then make really targeted investments in terms of where we want to put our resources. So, theory of constraints, minimizing waste, balancing the work across teams, you know, making sure that we are actually flowing value and we are not just focusing on better velocity, because often times velocity and value, while there is kind of a correlation between the two, in more complex enterprises value and velocity don't always match up.
So, I started writing a lot last year about the idea of the product owner because I would go in different organizations I would just see people struggling with that over and over again. And I'm a big believer in product ownership and I think that the teams need to have somebody that they could go to for unambiguous information and clarification for the backlog. I think that's critical. We're big believers in trying to bring product owners into the teams. It's just that in larger more complex environments the team can have a product owner but that product owner often isn't totally autonomous in their ability to make decisions. What we find is that, as you start dealing with the product owner role in more complex organizations; what we find is that there is not typically a single point of ownership of it. So I tend to create teams of stakeholders that have responsibility for doing the backlog, there might be a single point into the team, maybe it's a business analyst or somebody, or somebody serving as a product owner proxy for the team. But quite often there is project managers involved, there is product managers involved, and so what we try to do is use language around product ownership.
In the book that I'm writing we're breaking down some of these roles into what you might consider core-capabilities, what are the aspects of the product ownership that we need to make sure are covered? And then creating teams of people that can affectively steward the vision for the project, but also give the teams enough detail to go for it and build. And I think when we insist, there is a time and a place where a single product owner makes sense, and if it does that's great and that's probably the simplest way to do it. But when a single product owner doesn't make sense we need a credible language for being able to discuss what to do and in multi-team environments I love to see somebody as a product owner proxy on the team. And then across teams quite often are created a product owner team which has everybody from the lower teams and then their job is to go ahead and make sure that the backlogs are managed across all the other teams and to provide that integration point.
So, how I visualize Agile enterprises, I think we've really talked a little bit ago, is really multiple value streams. So we have kind of enterprise value stream which might have one set of stakeholders, maybe is CIO or CFO and some really strategic senior level product management kind of leaders at that level. They have a need to groom their enterprise backlogs and so in some ways that cloud of stakeholders is making decisions that flow into the rest of the organization. So that's kind of a team, and their job being this on-going grooming of the enterprise backlog. Kind of underneath that you might have like a product level background where they are taking the constraints and the guidance from the enterprise team and then turning it into strategic product decisions, what are the large features, what are the minimally marketable features, what are the value stores, whatever language you want to use and they are managing the flow of value and they are decomposing those items into feature levels that are actually going to go into the teams' backlog.
If now we take that and we bring it down into the next level. And so I kind of envision this not only just a flow of value that a team at that level is responsible for, but also ongoing grooming effort to, just like a product owner for a single team would take the feed-back from the team and use that to shift the backlog around, to put more detail into it, to learn as they see the emerging product, the higher levels within the organization need to be able to do that as well. So I think of like small users stories flowing through the enterprise level, but maybe at that level they're one to three months big. At a product level they're two to four weeks big, at a team level are two to three days big. And so that's this constant decomposition rolling back - up and then tracking the flow value at lots of different levels within the enterprise .
So, I think that we use a lot of the principles that we know from Agile, we get things up on walls, we use big visible charts. And again I think that one of the greatest contribution of this the Lean/Kanban movement is focusing on the value stream and end. So, as I visualize this and as soon as we bring at the customers and try to get everything up on the wall, I envision Kanban boards at the enterprise level with different states that these larger kind of enterprise user stories are going through, set work in process limits, manage to those constraints. And then those large items get broken down, they get sent into product level kind of compound boards, flow of value, breaking things down, work in process limits, that kind of thing. And then ultimately there's items getting broke down into the teams and then the team level backlogs, again, not so concerned whether to use compound or Scrum velocity burndown what have you.
So, that's how I tend to visualize it, but what it becomes as an exercise of getting everything up on a board. Being able to make intentional decisions about what things you're going to bring at different levels at different times. Respecting and managing to the constraints which is really the key. Because what happens is that when we're not paying explicit attentions toward the constraints are we just keep people busy, we say "Hey, that team is not doing anything, we need to give them some work". Well, if we give them work, but yet they need other teams, the other parts of the value team to be successful, and we are not aware of that, then they are busy but they are not ultimately going to add value into the product. So from a management perspective, when I start thinking of managing the system, so now I'm looking at where is my constraints, where I need to deploy resources - you know - money, coaching, additional people, that kind of a thing, to help elevate and remove that constraint? And, so, management, now, plays a role in helping to manage the system and you have self-organizing teams which are kind of the unit of capacity within that overall value stream, I guess.
10. You have some level involvement with the Agile PMI? Could you talk about that a little?
Yes, sure. So, my core - competency really, at the end of the day is project management. I'm passionate about that and that's kind of a strength. I've done lots of different kinds of projects management, we've done ad-hoc, just by the seat of your pants, we've done waterfalls, we've done RUP, I say we - me and my career have done all these things. I'm passionate about helping project managers understand there is so much value that Agile and Lean, and Kanban and theory of constraints bring to the profession of project management; it saddens me when I introduce these ideas and people are so kind of trapped in a large upfront plans and charts and the real detail planning and such. And so one of the things that I'm particularly passionate about is bringing the Agile message to the more traditional project management crowd. And my message in the being something to the affect that this is another set of tools in ways of thinking, and ways of problem solving, and ways of doing risk management, that can help you in certain contexts. So you don't want to go to people with the idea of "Hey, you've got to throw away everything you knew", we're trying to give them an additional set of tools that help them in their organizations to deliver projects better. So I've got involved in the Agile PMI Community of Practice, it's been lead by Jesse Fewell, there's lot of interesting things going on in that space right now and I think we're going to see some neat things happening and I think it will do nothing but just move our community forward.
11. What do you thing might be one of the bigger barriers in thinking to that community adopting Agile?
I think that there's a - a lot of folks just, they think in terms of I need to know everything before I can start anything. And there's a lots of language within the PMBOK around rolling way of planning, progressive elaboration, in breaking projects into phases, you can take that language and show them how to take some of our Agile concepts and lean concepts and Kanban concepts and blend them with what they know and, so I think that the general predisposition of a lot of traditional crowd is that they start with kind of fundamental assumption that with enough planning, with enough forethought up-front work, that you can make a predictable credible plan. I actually had one guy here, in Atlanta, tell me one time that if you can't plan your work you're either irresponsible or incompetent. I think that's what he said, because his general predisposition is that we can know everything up-front. And what I try to tell people is that there is times that we not only can't now everything up-front but there's sometimes that is not a good idea to even try to know everything up-front. We want to be able to inspect and adapt, and let the product emerge based on feed-back cycles.
And when you put these concepts in language, that a traditional PMI certified project manager understands and it resonates with them, they go "Oh_"; I've got a guy attend a talk that I did at PMI here in Atlanta couple a weeks ago, and he goes "Thank you, you really de-mystified a lot of that for me". Because we talk about Scrummasters and sprints and iterations, we've turned the language that they understand up-side down. When we talk about Agile in terms of time, cost, scope, risk mitigation, how we handle human resources, I know that we don't like to call people resources, but when you use language that they understand and you explain that concept, then they go "Ok, I get it". They can understand how to use it and then I think once we helped them understand how to get started then they start experiencing what it means to deal with uncertainty and how you manage uncertainty in projects. And I think they get it, right, there is really a smart group of people and they just start with a fundamentally different paradigm about what it means to deliver project work.