I'm here with Jean Tabaka, the author of Collaboration Explained: Facilitation Skills for Software Project Leaders. Jean, could you tell us something about yourself?

I have been in the software industry for over 25 years. I started out as a programmer, eons ago, with the punch cards, etc. Back in those days and even in through my life, as a consultant, I never had contact with customers, and I did a lot of my work sitting by myself and receiving tasks instructions from my project manager. And at some point around 2000 or so, I was touching into the Agile world and realized that I felt completely flipped on my ear, and if felt good. And what I started paying attention to what was that my passions were moving a little bit from writing code to more about what sits around writing codes.

I was part of a book on physical database design for Sybase Sequel Server, believe it or not, and that is when I really started caring about what is take to actually do work versus specifically doing the work. So my work with and being a programmer, and then touching into Agile all around this methodology view, led me to caring about facilitated, highly collaborative, decision making. I came into this work of caring about collaboration from being a programmer and watching what happens when you have really facilitated and collaborative environments, so that became something so important to me that I wrote a book that came out in January 2006 in the Agile Software Development Series, for Addison-Wesley, called Collaboration Explained. The whole time I was writing it, I thought "I really care about this, I don't know if anyone else will, but I will write it down and see what happens", so the book came out.

You have written about and you are thinking about teams and collaboration. Is that where your focus is right now? Is that what you are still thinking about this year?

I am doing a lot of work with teams and the book really gave me some sort of life force around moving into "Ok, let me go and work with teams more and more around collaboration and see if the things that I brought into the book really have legs, if they really stand". It still amazes me in this day and age the number of command and control environments I go into, and what I have to do to help people believe in a different way of doing things.

Two very odd discoveries have come to me while I have been talking about collaboration and how important it is. One is that I am discovering that there are people who actually, on teams, don't want to make decisions and the new Agile coaches or Scrum masters are coming to me and saying "I've got people who don't want to make decisions", so that's one very odd situation. I had no idea what happened.

The other one is that I am discovering more of the work I do with product owners is that they are actually learning that decision making for them is becoming very complex in that they have to be collaborative and negotiating with the team when they are planning now their iterations or their sprints, and yet, behind the scenes, they have to have reliable effective tools for coming up with their backlog, their ordering, their ranking and their priorities. And this is actually a new world for them, it is a brave new world! I now actually go into groups and talk about these. I think the hardest job in Agile is being the product owner and it is all this decision making.

The first point that you mentioned was team members who'd rather not make decisions. Can you tell me more about that?

Yes, unbelievable to me. We were moving into an Agile approach, thinking that people would just fall over themselves thinking "I finally get to own my task, I finally get to own my estimates; I get to decide which things I am working on, based on my expertise, my availability, etc." I have run into teams across the world, across cultures where brand new Agile project managers or Scrum masters would come to me and say "Jean we have the complete opposite problem. We have people who will not self-assign, who will not decide the tasks or decide the estimates or assign themselves tasks - pick up tasks.

When you ask them to do that is it anxiety-producing?

Apparently so. I was with a group, just a week or two ago, where the project manager said "What do we do, Jean? People are not self-assigning, they refuse to decide the tasks. Don't I have that point just go ahead and decide them?". I said "No", and he said "Then what do I do?" and I said "You stand there with patience and conviction that they own these decisions". He said "Well, how long do I stand there?".

I mean it came down to that, and said "I can stand some place for a minute and it can be very uncomfortable for the people, but the minute lets them know 'I really am serving to you, I really am turning this over to you' and then, if the team still feels they can step up there is something deeper going on". That is when I actually counsel project managers that they have to stop and do what I call a mini-retrospective. So we need to stop right here and find out what is it that is pulling you away, feeling not safe enough and making you not have enough trust in the environment, that you feel you cannot step up and make a decision and take ownership of something.

What kind of things do you find? And how do you help them?

I have discovered that retrospectives are an amazing tool for managing these situations. So what is underlying a team's refusal to commit, refusal to make decisions or for any individual in the team to self-assign, is that there is something deeper going on. As a retrospective facilitator, I make a very safe environment and find out things like "Our architect or our technical leader has always made the decisions and we get mocked if we do something wrong. We are afraid of being mocked.

We are afraid of getting it wrong, so we'd rather have someone else make the decision." Or, I have also found that they are used to not making the decision because then they don't have to be held accountable. So we have to end up talking about the safety of making a decision wrong, and that is OK, because we are on short iterations and we are amplifying learning about our decisions and also the safety of taking on ownership; that actually the fact that you are taking on ownership is in service to the team and it is not about someone looking at you like "How could have you possibly done that?".

So the retrospective at the end of every iteration is important and then, even when I go in and just find out that this is occurring with teams, I stop and have a retrospective. I was with a group of programmers who were fresh out of university and they said "We don't know what a task would be. We have never done this before, so we need help". Again it is necessary to dig under the covers, to find out. The project manager should not step back into a command and control mode of decision making, but should rather move into this mentoring role, and helping the individuals make the decision so that they gain more and more a sense of what the right things are to do, and not just have someone else decide it for them.

Your second point about a surprise that you had, while you have been processing all this information about collaboration, is that product owners, as decision makers, really face challenges with these Agile teams.

Yes. Again, my background is computer science – so here I am now, working Agile and helping mentor Agile teams and discovering that the product owners are raising their hands and saying "This is good, here in our iteration or sprint planning meetings, I get it. What do I do outside the meeting? I have stakeholders, I have user communities, I have conflicting priorities of other product owners; we are fighting with one another for resources."

And here is one example I had in particular which just surprised me so much that I was startled: I was with a group of people trying to help them think about release planning and iteration planning, about 30 people with this one organization and I said "Now, who is the product owner?" and the people in the room pointed at this one woman and said "She is the product owner" and she said "No, I am not. I will not be the product owner on this project". Delving in and finding out what was the truth underneath all that, I found out that it was extremely dangerous in this organization to step up and say "I'll own the decision", because there were so many conflicting stakeholders. Some of the work I have been doing was to try to learn a little more about product owners and decision making, so that when they come in to an iteration planning meeting, very clear about the ranking of what should be happening and what they would like as value delivery, to know where is the value definition in priority.

They need to know that: the value and the priority, before they come into the meeting, don't they? And the first couple of iterations say "have it" then it starts to slip doesn't it?

Yes, it does. The first couple of iterations, they still have got a lot of nice documentation that they had built up coming in, and then, it is somewhere around the fourth iteration where they find out that "Oh, God, I am falling behind the development team and I don't know what I am supposed to be doing with all these people barking in my ears about priorities, because we didn't use to worry about priorities when we built projects. We threw everything into the kettle and said 'It will all come out eventually'." Now they have to learn "Yes, I will listen and yes, that can be part of the soup, but these are the priorities".

What happens to a team when their product owners are becoming less and less effective at bringing them solid decisions?

Some of the symptoms I have seen have been that the product owners show up at the sprint /iteration planning meeting and they actually don't have information rich enough for the programmers and testers, the entire delivery team, to build what they think are useful tasks and estimates, items that they really feel they can stand up and commit to. And so the commitment to tasks and estimates starts to erode over time because they are being asked to commit, and yet, there is not enough information sitting and being carried in and brought in to the meeting. The product owner has some sense of what he wants but the team now are watching their morale go down, because they are still being asked to commit, they are learning how to be faster, but the product owners' information is not staying in a flow with them.

Does it affect their estimates? Does it affect their willingness, their ability to commit?

It affects all those. It affects the estimates with regard to the fact that they know less and less what should be delivered in this time box. There is not enough information, so then it affects their confidence in the process, it affects their morale and it affects the whole thing that I call "the rhythm of value delivery". The rhythm starts to fall off and we see it getting choppy, it has a lot of turbulence in it. And when teams feel that chop and turbulence, that is a classic symptom that the product owner has not been able to really come into the meeting ready with the "juicy" useful information to help the team commit to its work.

Have you found tools that can help product owners prepare so that they really can serve the teams well?

There are a couple of things I have been working on. One of them is that Agile methodologies seem to focus primarily on programmers and the delivery team, the development team. If I look at Lean - a lot of Lean principles are guiding me in making decisions about Agile practices - there is in the Lean principles a notion of flow and rhythm, and a term I used earlier, turbulence and non turbulence, smooth flow. What I realized was that product owners actually need some very similar guidance about flow, so teams are supposed to be engaged in smooth flow of value.

So, I am learning that I have to go in and talk with product owners to create teams that gather useful information in priority order, so that they have smooth flow of value definition. That is one of the things I am doing: really working with them about their own flow of meetings, their own flow of the work that they do and the teams they do it with. That leads to my second item, which is how do they pull together, potentially conflicting, fighting, competing priorities, organizations, business units; how they pull them together to show up with one prioritized backlog for the planning meeting. And this is some stuff I have read in the Harvard Business Review.

What did you discover in the Harvard Business Review that gave you insight into how to help the product owners?

First of all, what gave me insight about was that I needed to look outside of the Agile books and really look at business and things that business is paying attention to about decision making. This was in January 2006 Harvard Business Review, dedicated entirely to decision making for business owners, executives, etc. In one article about evidence based management, the authors went into the use of a model called RAPID, and they said that they found it very effective for businesses to very explicitly decide the roles that are involved in effective decision making models.

RAPID, I guess, is an acronym; what does it stand for?

RAPID is an acronym of the five roles that - these people believe - need to be very explicitly articulated and defined before business moves into decision making. Each of the letters of RAPID is one of the five roles that a group needs to agree upon when they go into decision making.

Tell us about the five roles that make up RAPID.

There is "R" which is the recommender – think about the product owners as having to be someone who pays attention to lots of recommendations coming in, so there is the recommender role. Recommenders in Agile need to pay attention to the fact that they better have scooped up good information about their idea, and yet, they don't own the decision because that is the "D" all the way at the end of the RAPID acronym. So a recommender can bring information in, but they are fully cognizant of the fact that they do not own the decision.

"A" is an agreer. This is some who has, let's say, subject matter expertise and can actually hold a veto to a decision, so there is a decider, but think about a product owner in an Agile organization who has executive sponsors or who has very trusted advisors. I think they would fall into that agreer role.

The "P" in RAPID are the actual performers. Once a decision has been taken - think about the delivery team showing up at the planning meeting – decisions have been made about the priorities, negotiations have been held with architecture, with various user communities, with competing product teams, that have led to this moment of this planning meeting for this one group, that says "these are the decisions of the order and now you, as delivery team, we are going to take on the decisions and decide the work" - so that is the performer role.

The developer, or the doer, actually has a role within this RAPID approach, which at first I thought you are going to talk only about something that happens in the product group, but there is a crossover to development.

There is in fact. I can see them showing up in three areas: you can think of a developer even being a recommender, there will be a performer for sure because they are delivering – I refer to the value that has been ranked –, so they are definitely in the P role, the performer. But development and technical individuals on teams can be recommenders in what should be in the product backlog. I think they can be recommenders in two approaches, so I will say that a developer can show up and be a recommender, can be clearly a performer and then there is a third role, which is the "I"- input. When I am mentoring brand new teams, I talk with the product owners about the fact that they indeed own the product backlog, they own the priority of what they want delivered, but it would be criminal and negligent, at the very least, to make these rankings without getting input, without discovering useful information or recommendations. So I very often talk about the fact that, as you are prioritizing, when you have your smooth flow of meetings about making your decisions you should be getting technical input. So a developer could also be in the "I" role – the input role. Then finally there is the "D", which is the decider.

Who is the decider? Who gets to make the decision?

Well, gets to and has to - it's a double edge sword. The decider is, in our Agile world, the product owner, the person who owns the money, who owns the belief and the conviction around the value, is the ultimate arbiter, the ultimate decider, and that is so important for that person to recognize "I own the decision, but I have recommenders, I have agreers, I have performers, I have input, and so I won't make decisions in a vacuum, in a silo, without any information".

So the decider doesn't feel so much like he has been hung out in the wind?

No, hopefully not. To go back to my example, I was in this large group and this one woman would not, although everyone was pointing at her, be the product owner, so I wish I had these tools back when I was talking with this woman, because I would have wanted to say "OK, let's stop and find out. Pull your business community together and let's have explicit discussions about who are the recommenders, who are the agreers, who are the performers and then who are the people who represent the input". And when you have all this alignment and understanding, you are explicit: names are put with these things. Then being the decider shouldn't make you feel left alone and hung out in the wind. There really is this model that we have all signed up to, about the importance of having one decider.

Is this full proof?

Actually, one of the good pieces of information I got in the article was that there are two major roadblocks to having benefit derived from adopting this model. The first one that they mentioned was, in fact, the one that I had run into, where there was no decision maker so no one would stand up and say "I will own the decision, I will own the value definition, the value proposition". The other roadblock, which I have seen too many times in my life, is that there are too many deciders. So there has not been an explicit recognition of who will ultimately own the decision. This is a tricky slippery slope because it can start to look like command and control.

As we are in the Agile world, as we are working with collaborative teams and wanting participation in all these different new ways, and then trying to help product teams do the same, paying attention to your decision modes is so important, because for me, in my passion, the easy fall back is command and control and I just don't want that to happen.

In 2006 you were thinking about teams and collaboration and leadership inside the self-organizing team, and now you are realizing that there is another bottleneck outside which is in the product order domain, so where do you go from here?

It's a wonderful journey of watching collaborative teams and helping them with becoming more and more participatory in all the work around that, and then discovering the poor product owners are sitting out there, trying to figure out how to get their things done. I’m becoming more and more passionate, at this point is actually reaching back into the real fundamentals of Lean - the notions of flow and pull and innovate.

To me, those sit out and round, and cradle and hold the whole Agile movement; they help me understand the business imperative around Agile: smooth flow of value, the ability to pull value, and to have the business be a truly innovative business. My work with collaborative teams has helped me see what is happening with the poor product owners. I want to help them and that means that, once we have all of that in smooth flow, I really want to watch, organizationally, how we have decision making that responds to change, invites change and then drives change. To me, that is when the decision making is really working.