Portfolio Kanban: Applying Lean & Agile Principles At The Portfolio Level [Keep Austin Agile 2016]

Presented at Keep Austin Agile 2016, William Baxter explains how a true Agile transformation goes beyond the team level and team practices through his experience coaching a media company in New York City. The case study presentation explores the good and the bad, the successes and failures. A favorite tip you can implement right away? Adding team faces to your board to humanize the process and conversation. This is especially important for distributed team members.

This presentation came out of some work that I did about a year and a half to two years ago. I’ll talk to you about it in as much detail as I can, there are a few constraints, however. I am not legally permitted to tell you who the client is and exactly what they’re working on, and so on. But I’ll give you a good sense of the setting and of the problems that they faced.

This was work for a major television network in New York City. A very large organization, they had a rather large income stream about 5 billion dollars a year. This is the digital group, a relatively small group in the company, about 40 million dollars a year of direct revenue impact. But when you talk to people at the company, they tell you that digital is the future. And some of them even say, if anybody tells you digital is the future they’re already wrong, it is the present.

Now, that is a rather strong statement with that imbalance. So what is going on? This is a small group, they have a product vision. They’re going to develop these direct to consumer products. They’re going to develop products that support their existing systems, the websites, the other groups they distribute through such as cable providers. They have about nine teams all working together. The main distribution channels are cable providers and OTT, which is set-top boxes.

They’re in a space, which we will talk about in a moment, that’s undergoing a lot of disruption. How many people are familiar at all with this industry? So it’s an advertising-based industry, and in 2014 industry-wide, ad revenues fell 25 percent.

Clear out some space on your table and make room for four quadrants. Mark North, so that we know where our orientation is and we will go around and fill in the quadrants. Alright, we have a lot of coaches in the room so y’all will be familiar with this. When you first go into an organization you have to understand what their pain points are. You can’t get anywhere without that. So what are the pain points in this industry? I talked about one of them a moment ago, severe disruption. They have a lot of crosses, in this particular industry, they have this business model that is kind of going to pieces right in front of them. One of the senior executives I talked to there said, “you know I wish this was happening ten years down the road because I’d be close to retirement by then. But as it is I have to figure out how to get through all of this.”

They also have a couple of standard problems, like unpredictable lead times to delivery of new product. That’s very similar to what David talked about the last talk. They also have particular things in their world like dependencies across the teams and shared resources, that’s something we will talk about as we go. The main thing for them is that they have this 5 billion dollar a year revenue stream that is attached to a business model that’s under attack. Their business model is perhaps not viable, and yet they have contracts that run out ten or fifteen years with all the distribution channels. So they’re looking at this and saying, “Man we’ve got fat margins, we’ve got this huge revenue stream and we may not even be around in ten years.”

It’s scary business, you all have a similar experience with pain points in your roles. Let’s fill in one of the quadrants. I want you to look at what your top pain points are with your portfolio of products and label the Northeast quadrant in your workspace “pain points.”  Slap some ideas down there. Just write them out yourself, put them down, discuss them with your team and do a quick ranking. Ok, there are your two minutes. So who wants to share the top pain point that they came up with? “Reactive, not proactive.” Who else wants to share one of the pain points? “Shared resources.” “Time to implement.” “Lack of focus on too many things.” “Change in the organization” what kind of change do you have in mind? “Constant reorganization, so no one has sure footing within the organization.” Excellent point. “Enterprise alignment.” Ok. Excellent. “No portfolio.” Okay yeah, sometimes you go in and say “Hey where can I find the portfolio of you? Where do I look?” And they say “well I don’t know” or one person says “well here’s mine” and another person says “well here’s mine.” You look at them and uh there is probably some overlap. “Lack of product ownership resources.” – Ok, these are all really good examples. There are a lot of pain points and you have to understand the pain points in order to get anywhere with agile implementations. We’re going to try to tie everything else we do to the pain points here, so keep that in mind.

I want to talk about three fundamental concepts in this context. Transparency, prioritization, and alignment- those to me are the three key concepts for good portfolio management. I would say it actually extends a little more broadly, you could apply these at the team level. To me, the team level is relatively well understood. We’ve all, as an industry, been working very hard and very effectively at how to stand up Agile teams, how to help them perform well. But step up a level and look at the program or the portfolio and all bets are off completely different story.

Not very much in the way of standard practice, not very much in the way of good reliable mechanisms for implementing change, there are attempts out there now. Some people are talking about SAFe; some people are talking about LESS. I’m not going to delve into those questions today but I am going to tell you about what we did with this one company to try to help them at that level. Let’s talk about each of these in turn. Let’s start with transparency.

Transparency is one of those things that you introduce at the team level when you set up a Scrum team. They become transparent in what work is in progress, in where they are in that, in how much they completed versus how much they committed to complete. How do people on the team react when you introduce transparency like that? It terrifies them, right? They say, “I’m totally exposed, someone is going to come in abuse me for not getting enough done” and you have to work through it with them. You have to make sure that they understand this is their part of the bargain. They’re providing transparency to the stakeholders, and what do the stakeholders have to do in response? They have to accept that they’re now seeing the ugly truth rather than the pretty fiction. That’s the price that they pay for making fully informed decisions, there’s no other way.

They can’t go and abuse the people at the team level because otherwise, they’re going to get the fiction again. If they want the truth, they have to accept the truth. You can work with stakeholders and teams, and develop that new relationship between the two. Now, what happens when you introduce transparency at the portfolio level? How do people react to that? They’re terrified. They feel totally exposed. They think some executive is going to come down and say what the hell is this. It’s exactly the same reaction, for similar reasons, it’s just at higher stakes. And in this case, if you are helping to coach them through this you have to work with them and say “remember we did this with the teams, remember you were on the other side of this with the teams and you helped to form a new relationship with the teams that made this work and then you had the truth so you could make your decisions, well now you’re doing the same with your stakeholders, further up in the organization.”

You have to work with them through that, and again it’s about providing the ugly truth and avoiding the pretty fiction. Making sure that everybody sees that truth together in that one place, and then they can all make decisions on the basis of the same facts, otherwise, everyone is pretending. Let’s do a couple quick exercises about this. I want you to label the Southeast quadrant of your space with transparency. Then write out some examples to discuss with your table, where lack of transparency hurts you. If you can, tie it to one of the pain points that you have. Maybe some of them will stand alone but try to tie them to pain points if you can. We’ll spend two minutes on that, go. Alright, so there’s your two minutes. Does anyone want to share one of those, where is the lack of transparency hurting you?

There is a good implicit point here that transparency is a two-way street. It has to also be about the transparency of the vision and so on. In this case, for me, that wasn’t in play with this organization because they did have a vision. However often times you go into an organization and they really need to develop that vision, they don’t have it or everybody has their own and it’s not visible to the rest of the company. Great, who else has an example? “Prioritization of the projects for maximum business value.” Great, anybody else? “Shadow projects or injects.” I usually call those black ops, because they’re there somewhere in the background, some surreptitious exercise. “Prioritizing at a tactical level rather than a strategic level.”

Let’s take another two minutes and say, what would improved transparency look like for you? So put those in the same quadrant, you can distinguish them somehow if you need to. Spend two minutes on that, just say how could we do better on the transparency front? What would that look like? Alright, there’s your two minutes. Anybody have one that’s leaping off their table? They want everyone to know. Communicate, ok that’s pretty broad. Important, but pretty broad.

Focus on the right things. There is a big value in a backlog, I say, primarily because things drop off the bottom. Not because they’re bad ideas, but because they’re not good enough. That’s precisely what gives you focus, and it’s really hard especially at the leadership level for people to wrap their heads around the idea that losing things out of the backlog is actually beneficial.

There’s a lot of impact to transparency. Let me tell you what the major thing that we did here was. We introduced portfolio Kanban where we had a lane per team, and all of the major items were represented here. Major meant sufficiently large initiative or initiative that involved multiple teams. This was the primary visibility that we added. In this particular company, we had a stroke of luck because the senior VP, who was not the sponsor but the sponsors boss, said: “yes, use my office glass for this.” So we put it right in front of him. This meant every single conversation that took place at that board took place in front of him. He got up, walked out of his office, and joined a lot of them.

When you do this, make it prominent. Put it in a place where everybody sees it. Don’t hide it off in a corner somewhere, don’t put it in a conference room, put it out in front of everyone so that it becomes a standard point of conversation. That was a big plus for us, and we used a physical board with cards on the board. We didn’t do any tooling, people were talking about tools at the beginning. My view of tools is if you adopt a tool immediately, people will do what the tool makes easy and avoid what the tool makes hard. If you use pen and paper, you’ll bend the tool to your purpose. Start with pen and paper because it is perfectly intuitive, figure out what you need and then look at tools later.

Start simple. I’m a big fan of stupid simple. This is stupid simple. There’s a new column where you park new stuff, there is a column per team. We learned a few things about this. One is, it’s really important to set this up fast. Setting this up will take you longer than you think. This is not an exercise for a day, this is going take you a couple of weeks minimum. Surprising, but true. The second thing you’ll find is that it freaks people out because there are so many things on the board. And you’ll start to hear push back like, “We can’t set that up, there are so many things, how can we look at this?”

And you have to have those conversations if you can’t look at this and set this up here, how in the world do you expect to implement all this stuff. How do you expect to manage all of this stuff? This is the easy part. Another thing is to humanize it. We put this up, and then we tried an experiment: We took pictures of the teams and put them at the top of each column. And that made a huge difference in shaping the conversation. It put a human face on it. People stopped saying resources and started naming names and talking about people. The entire tone of the conversation changed for the better. Humanize it. Put a face on it. This is especially important if you have distributed teams where you don’t see everybody all the time. Make sure that it has a human face.

Now not everything worked. I think it’s always important to inject into a presentation like this thing that didn’t work, in addition to things that did work. Early on we thought we’re going to use an opportunity canvas as the basic entry on this board, a la Jeff Patton, and Marty Kagen. That bombed horribly. Product owners just rejected it. A couple of them tried it, and I said to them, “just do the fifteen-minute version it doesn’t have to take long” and they balked. So that was an utter failure. So we just dropped it.

Prioritization is next. This is the key to maintenance, we already started talking about the fact that things dropping off the bottom of the backlog are actually beneficial. That’s only going to happen if you prioritize. Now one of the first things that happened, in this case, is that senior VP with the board on his wall walked out of the office one day and read this and he said two things. He said “you know, we’ve had this information for a long time, it’s just scattered all over the place. It’s in five different places, this is the first time I’ve ever seen it in one place.” The second thing he said is, “why are we doing that” and there was our first win right there. We were able to drop something. You always have to look for that opportunity. That impulse to throw things away and the genuine argument that took place around it was wonderfully clarifying. That really helped us. So that is about prioritization.

What I want to do is collect a set of prioritization methods. If you have one that you use, stand up and shout it out, and I’ll just take notes. “Business value,” “Loudest stakeholder” “Customer satisfaction.” “Product owner says so.” “Alignment to company goals.” “Impact versus effort.” “Cost to build” There are a lot. Let me do a quick survey of preference. How many think the cost of delay is what they prefer? Raise your hand you can vote more than once. We got two! Ok, that’s almost zero. What about business value? That looks like about half of the people. Customer satisfaction? How a bunch of you, maybe ⅓. Product owner says so? Remember we’re talking portfolio here not teams.

The one that I didn’t hear, that I think is more common than any other is highest paid person’s opinion. Almost every organization I have walked into as a coach actually does highest paid person’s opinion. Why? Fear, attempted alignment in this sort of hierarchical way, lack of metrics for any of the other, capitulation, they promised the customer – it’s sales driven, the sales guys have gone and sold something and then they say “well we’re already committed. You can’t back down now, it’s too late.

My contention is this, that it’s better to have one than not to have one. Even if your method of prioritization is HiPPO highest paid person’s opinion that’s better than not having a method of prioritization and just doing it all ad hoc. Why? Well if you have a very metrics based method of prioritization it can become predictable. Even if it’s not metrics based and not predictable, at least it can become anticipatable. And you can do that even with highest paid person’s opinion. You can go and have the conversation with that person and get a sense, have some idea, of how things are going to shake out.

Let’s label the southwest quadrant “prioritization” and what I want you to do as a table is choose a method and then write out what information you would need in order to support that method. Different methods require different things, if you’re using HiPPO you need access to that person with the highly paid opinion. Write out what you need for the method that you choose. Take a couple minutes. OK, there’s your two minutes. Would anybody like to share what you picked and what information you identified as a necessary input to that prioritization method? You want to do business value prioritization and in order to do that you need a strategic level prioritization over the overall business goals, so that you can check against those. Who else has something to share? What if you wanted to do wait is the shortest job first? Does anybody choose that? How about the cost of delay? Does anybody choose HiPPO? What did you choose? Business value. Alright, what do you need to prioritize business value? Agreed on the definition of what value is. And by definition do you include an estimate?  

Ok, alright. Cost benefit analysis requires two imputes. You need an estimate of the benefit, you need an estimate of the cost. Typically when we talk about estimation we’re talking about cost estimation. But that’s a very incomplete picture, and so it’s hard to use that as a sufficient basis for prioritization. In the case of the team that I worked with, we ended up doing cost-benefit prioritization and the stakeholders managed the exceptions to that. There are always exceptions. The example that comes to mind in this context is that there were some legal requirements. Users were required to have a pop-up that they signed off on new terms of service and that had to be done by date X and so that jumped the queue. They, for the most part, stuck to cost-benefit analysis and they used this information.

This is what a work item looked like on our Kanban board. We had the name of the project, a team, the description, we had dependencies, we had an owner. That was the big thing for us, always have an owner because they were the one that had to answer all the other questions about this. Then we had BV which is business value and LOE the cost estimate and that was the basis for the discussion. And then we had notes, and that was an interesting adventure in itself because some people put nothing there and some people wrote voluminous essays there.

We discovered the need to find the right level of detail, that actually takes some time to shake out. Another reason to push and get this setup very quickly because there are all sorts of shaking out that happens downstream from there. Some people are writing all these details and some stakeholder wonder over and say you know, can you just cut out the noise please we don’t care. You have to find the level. The main things for us, in this context, where we did agree on a method. There had never been an agreed method before and based on that method we prioritized things top to bottom on that board. We decided to go top to bottom because we didn’t want to put one team down here. On that basis, then we had those conversations like with that senior VP who said: “what is thing down here at the bottom?” “Why would we even think about doing that, that has business value but there is no way that rises to the level of making the cut.”

So then we ended up, one of the first things that happened is one of the stakeholders said I want to draw a line here and say everything above this line is going to be implemented by day X. That didn’t really happen but what did happen is we drew another line. The first one that said, everything above here is actually in flight now, being worked on. Then we drew another line below that, that said everything below this we should consider dropping. So we actually got that benefit of things being dropped from the backlog.

Now, what didn’t work? What didn’t work was that there were still a whole bunch of black ops projects. In this case, there was a very strong personality in charge of the technology group that felt that it was imperative that he comes in, make sure that all of his projects got done and didn’t really feel compelled to put them on the board. They just went back-channel, and you can imagine what the impact was on the flow here. It gummed up the works pretty badly, things were stopped all over the place.

So what did we do? Well, we started highlighting the blockers. We found the loudest, most obnoxious sticky we could find and we would put up the blockers. If something got blocked for a period of time that went into the notes section. If something was delayed for a week because a resource got borrowed that went into the notes section. So that later on when somebody said “why did this take so long” we could look at that and say well, this happened, this happened, this happened. It’s an interesting thing when you do this because when you start highlighting dependencies and blockers the thing lights up like a Christmas tree. No one can pass it without getting sucked it, it was terrific.

The discussions had begun, and so that was the big breakthrough for us. The thing lit up, everybody engaged around it, and the discussion really began in earnest. All because we had put this up, made this visible, made this transparent and focused on prioritizing.

The last component here is alignment. If you take one thing away from the talk today and ignore everything else, I’d like it to be this: alignment is a practice, not a state. Alignment is not a state you achieve and then you have, but rather it’s something you have to constantly maintain and adjust because circumstances change, environments change, business conditions and landscape change, people’s minds change.

This is very akin to the change in backlog that occurs between sprints after you get your feedback from your stakeholders at the review session at the end of a sprint. You get feedback and that changes your plans. This is very similar. That reaction in the backlog, in a product backlog to stakeholder feedback, is a kind of alignment. The reason it’s so important to focus on the practice and not the state is that understanding that change is how you approach this. It means that you approach this by setting up that cadence, or that rhythm of maintenance meetings and communication. In our case, we had a regular meeting which we will talk about in a minute.

What I want to do with you first is say where do you, in your organization, lack alignment? So let’s go to the Northwest quadrant, call that alignment and write out your ideas about where you lack alignment in your organization and rank them with your table. There are your two minutes. Let’s do one quick addition to this. Why don’t you write up your agenda for an alignment meeting, You’ve figured out what you need to do to align, how you’d like to approach that, so what’s the agenda for that? Who needs to be there? What do you need to touch on? What things do you need to accomplish? What outcomes do you want from it? Take two minutes and quickly write that agenda.