The Board Episode 5 – What makes a good Product Owner

Kirstin Donaldson: Hi, welcome to The Board. I’m Kirstin Donaldson, Agile Coach at Boost and this is Paul Flewelling.

Paul Flewelling: Also, an Agile Coach at Boost.

Kirstin: Also, an Agile Coach. Welcome back, Paul. Paul’s been on, a somewhat of, a world tour for the last five weeks. Do you want to tell us where you’ve been?

Paul: As Kirstin said, a world tour so I started in Canada and the States for some training. I was on a scout out framework program consultant training course and then I flew onto Europe and the UK. I got to see my family, who I haven’t seen for a few years, and go and visit Turkey. Then I stopped in Shanghai on the way back to see the guys that work in our Agile office in Shanghai.

Kirstin: Boost Agile.

Paul: Yeah, Boost Agile.

Kirstin: How does it feel to be back in windy and [indecipherable 00:50] Wellington?

Paul: Yeah, I am really happy to be back. I was missing my own bed. That’s it.

[laughter]

Kirstin: So it is nice to know you missed work as well.

[laughter]

Paul: I miss work as well but the scaled agile framework. There was 40 people on that course. There was a good mix of people, mostly internal consultants in this case. Lots of big companies in the States are implementing the scaled agile framework, at the moment.

Seattle, where I was for the training, is the home of Boeing. Not surprisingly there were 15 people from Boeing on the course. But they were also from all over the States in terms of, though. In Seattle, they have the airline divisions, but there were also people there from their Space division and also their military division as well.

Kirstin: So there were some nice interesting people there.

Paul: Really interesting people. Really smart people and working on massive projects, projects such as the F-22, which is a fighter.

Kirstin: A plane.

Paul: A plane, yes.

And it blew my mind in terms of the scale of the project. There are thousands of people involved in a project like that. It is hardware and software. Obviously, all kinds of different control systems, special tools being built, special software being written to build the plane itself and so on.

Kirstin: Software is being written for machines to build parts?

Paul: Yes, that is right. It is a pretty unique environment anyway, in that kind of company.

Kirstin: And they are working with the scaled job framework, now?

Paul: They are, they are implementing it across the company. And they have Scrum teams, operating at the lower tier, and they are gradually converting their program and portfolio layers to the scaled approach.

Kirstin: It would be really interesting to hear them talk about it once they’re further along in talking about their journey but I guess they’re not going to come to me. I’m going to go do something online.

Paul: I’m in contact with a few of those guys so, hopefully, I’m finally linked in so I will remain in contact. There’re also people there from HP and Intel Microsoft. There’s a lot of interest in the Scaled Agile Framework environment and a lot of companies in the States, like I say, are implementing it. It seems to be the best alternative when you’re operating Agile at scale.

Kirstin: It’s something that we’ve been talking to people in New Zealand government about here, which could be quite well suited to the larger government departments as well. It’s something that we continue to talk to people about.

Paul: That’s right.

Kirstin: Try and encourage them and see how they might find that we all work for them.

Paul: Yeah, that’s right. I’ve worked in government here and they do things in a very similar way here. It’s perfectly feasible too. Scale Agile talks in terms of Agile Release Trains and Agile Release Train looks after one of your products. You have an Agile Release Train that’s between 50 to 150 people but there’s different ways of skinning cats and so on.

You can have, depending on how you see your program and you normally have different products contributing to a wider program. You can have different teams working on different products and then call it one Agile Release Train and so, synchronizing your activity, mapping your dependence’s and cross teams and so on.

Obviously, at the portfolio level, you’re doing pretty much what you do day to day now but you’re using a Cam Bam system to make work visible at that level. That it’s just about making work visible and understanding what is coming next so that the teams or the program management team below can have high visibility of what’s on the horizon, if you like. It’s very similar to what those government departments are doing right now, just a bit more visibility, a bit transparency.

Kirstin: A bit more Agile.

Paul: A bit more. That’s what Agile is, transparency.

Kirstin: Yeah, a part of it, isn’t it?

Paul: And collaboration.

Kirstin: Yeah, exactly.

We’ve got a couple of things that we’ve talked about…talking about today. One of them, which probably they’ve done quite nicely from talking about SAFe, Scaled Agile Framework, is something that came up when we were chatting with a few people yesterday about working with two teams and working off of one backlog.

In Scaled Agile Framework, there is one backlog isn’t there amongst all the teams?

Paul: That’s right. It’s the program backlog which feeds into the teams’ backlogs so that each team has its own product backlog, if you like. The band reliance are much grayer or ill-defined in the Scaled approach because that obviously seems to be working on.

For example, the example we were talking yesterday, that was someone wanting working on the API, the other team working on a frontend system which implements the API and that managing the dependencies because he’s such an [indecipherable 06:08] know-how. I mean, you could in theory as long as you know what the interfaces are and so on.

You could build a frontend before you’ve got the API, and you could just mock the environment so that you can test that and so on. You just accept the fact that you’re going to…changes are going to come through from the API team at some point and so on.

Kirstin: This is what you’ve said. Did you think there were some opportunities to have those two teams work together more?

Paul: Yeah. That’s what I saw with the Scaled approach. You don’t try and do things the hard way, you try and let the teams work in a more natural flow where they decide how they are going to implement. They may have that dependencies, how they going to work together at that level. Essentially, it’s up to the team how they decide to implement.

Kirstin: Sure. I was actually thinking though…it’s two teams. The one is staying, say, API and one staying frontend, would it not be better if they mixed up those stories so that both teams are doing some API and both teams doing some frontend so that you’ve got stories that involves API work with frontend in the same story? Is that possible or…

[crosstalk]

Paul: That is possible. No, it is possible but, honestly, it depends on the scale. I know some situations where we have dedicated teams to the API because it’s just too big or just too much to my knowledge for that end. Scrum team should be five to nine people. Once you start breaking those bands, it gets quite hard to manage.

Kirstin: Yeah, just maintaining the two teams, but it’s like some stories to fill in or that the stories contains a whole feature from backend to frontend rather than split end or frontend stories and API stories, and then each team could work on those stories differently.

Paul: That’s possible. We do that here.

Kirstin: Yeah. This is the thing. I just thought that way…because otherwise, the project that we talk about yesterday seem to me to be becoming one of those handoff project, as was subscribed. There’s a backend team, a frontend team and a testing team, so you still having that pass off rather than having a slice of functionality in the story, so your endeavor with stuff unfinished.

Paul: Let’s be very clear. I prefer what you’re describing with that. There are some teams operate in this component way. They build components. Unfortunately, the component and approach don’t really lend itself to. Those teams find it really hard to go vertical in terms of that slice.

Kirstin: The problem is they’re not going to achieve the productivity.

Paul: No. I don’t think.

Kirstin: That people who had those slices of functionality through stories can achieve in terms of working software as a value to the business engineering team or user.

Paul: That’s right. If the project scale allows it, then you should work in vertical slices. You should get as much knowledge across all of the teams about the complete depth or complete slice of the system, so you’re looking at total depth for the system, and when you move into something much bigger, then it becomes a bit harder to manage and you can’t…those so far, by the ways because you don’t have to build.

Kirstin: Sure. The idea, though, of having an entire team working on testing seems dangerous in terms of not getting things finish.

Paul: Yeah. That’s a red flag for me.

Kirstin: Yeah, I would at least expect it to be thesis within age of those teams, the backend team and the frontend team working with developers or being the developers.

Paul: If you’ve got separate test team, then it just immediately red flag because that’s a cause of delay right there because you have to hand off the work once it’s been finished. You’re handing it over to the testing.

Kirstin: I assume a lot of it’s going to come back.

Paul: The testing team has got multiple teams feeding into it. If that’s the setup you’ve got, that’s the scenario I can see you’ve got. One test team, multiple development teams, all throwing things over the fence to the test team. They can only manage one project at a time. They cannot manage multiple things at once so there will be a delay in…

Kirstin: Similarly we were talking to someone yesterday who was talking about how to shear UX resource over a couple of teams.

Paul: That’s right.

Kirstin: What we came round to was [indecipherable 10:52] UX person in the team. How they would like to shear. It is one of those situations where it really needs to work for all those people not for Scrub masters. It’s really nothing to do with us.

Paul: There is a really good book called, ‘The Principals of Product Development Flow’ by Don Ryanatson, and he talks about the key metric that you have to measure and analysis as your coastal delay, that’s the key thing. If there is a delay in that UX resource being available, you have to measure the cost of that delay and work out whether it’s acceptable to the organization or not. If it’s not acceptable then you have to do something about it.

Kirstin: The other option we were talking about, do you perhaps need UX resource? Sometimes it does come down to that if it can’t be resolved by the team and by UX resource. The problem with a smaller company, I know with ours that sometimes work ebbs and flows, so it can be difficult.

Paul: That’s right, it’s a balance.

Kirstin: It happens to us all the time. It is a balance.

Paul: That’s why the cost of delay is so important. If the cost of delay is that you can absorb it in the cost of the project, that’s fine. If you can’t absorb it, if it’s becoming too big, then you have to do something different.

Kirstin: You have to weigh it up against those periods where things have it.

Paul: That might mean you hire contractor, that kind of thing.

Kirstin: Something else that came up yesterday from one of our team members was, working with smaller Scrum teams as a Scrum master. I’ve worked with a number of smaller teams here at Boost as a Scrum master and I did find myself being someone who offered and was asked opinions on the project quite a lot.

If you are working with, quite often, it’s just one developer and one designer and they really needed someone else to kick things off against, to discuss things with. It is a little bit harder in a smaller team to talk about solutions when there are just two of you. What Jo was saying is it appropriate for a Scrum master to get that involved? It’s very tricky in a small team.

Paul: Small teams, when you outside of the Scrum definition of team of five to nine, it does have its own difficulties or dynamics that you have to manage. One of those is when you have only got one developer or one designer, so two members of the team they are really limited to the ideas, sharing and so on. They don’t have backup, they don’t have support in terms of, and they don’t have all the answers because effectively they are a two man team.

Kirstin: One of the things we did on one of the teams I worked with that was mainly one developer working on it. When we saw that he was suffering from a lack of team environment we put him in touch with a developer from another team, which was actually you at the time, to bounce ideas off because we could see he didn’t have that and he was really struggling. That helped.

Do you remember that a little while ago we did that?

Paul: Yes, it does really help. It’s much better than that person struggling through on their own in terms of trying to get the answer. It’s much better to be able to share those ideas, it just requires a bit of investment from the outside team member.

If they are not invested in what you are doing then they can have a superficial view of the problem and they end up giving you ideas that take you down the wrong track. If you do have an outsider involved they have to be invested in the project as much they can be.

Kirstin: I find as a Scrum master on a smaller team I ended up working as part of the team, so for stories involved in user testing for example, I would often get involved. I found myself being a strategy resource quite often. Then I did have buy into the project not just as a facilitator but also as a team member. That tended to work quite well, participating in stories makes it easier to be their sounding board.

Paul: That’s right, because I’m a former developer I’m a good sounding board for the…Having worked in Scrum teams I can encourage people to take certain directions.

[crosstalk]

Kirstin: There was another project recently where you were technical coach, because actually there is a newer member of Boost that was involved and we wanted to give him some support.

Paul: What I have to make clear to project teams that I work with like that, that I am not an authority and they shouldn’t be listening to my…

Kirstin: You’re not telling them what to do, you’re helping them discuss ideas. I suppose it is good to make that clear otherwise they might be confused and think, I’ll just do it that way.

Paul: That’s the last thing you want, that’s one of the things Scrum is trying to prevent from happening, people that don’t have the knowledge telling people that do have the knowledge what to do.

Kirstin: It’s funny, in this conversation today we have gone from the opposite ends of the scale. We have got that massive enterprise scale. We’ve got smaller teams in a place like New Zealand where there are a lot of small to medium businesses deal with challenges we are talking about now.

Paul: Scrum does work at the smaller level really well.

Kirstin: We have been doing it for a number of years now and have definitely found it to be much more successful than previous ways of working.

Paul: That’s right and the games you get from using the Scrum approach far outweigh the disadvantages.

Kirstin: Even the challenges make it interesting. Trying to find a way to make it work as long as we keep improving on what we have been doing previously, which we still are. What else have we got today? Distributive Scrum teams we were talking about yesterday during a meet up as well. There were some interesting things coming out. The most challenging thing that we find when we talk about distributive teams is time zones.

Paul: Exactly.

Kirstin: Not so much Auckland [indecipherable 17:29] Christchurch, UK, China, US.

Paul: There are plenty of tours about to manage communication over a distance, like Skype for example.

Kirstin: There is, it doesn’t usually come down to a problem at all.

Paul: It’s not a problem at all. It’s exactly what you said, it time zone. In the time zones, the hardest I found was when I was in the UK. At the moment the UK is thirteen hours time difference.

Kirstin: It’s impossible isn’t it! It’s not just that it’s hard to get hold of people at the right times. It’s that you’re in a completely different mind-frame at each end. One person’s sleepy about to go to bed and the other person’s just got up and ready to face the day or vice a versa.

Paul: Yeah, that’s right.

Kirstin: It just feels really different talking to each other. You were telling me yesterday that we were going to be doing some stretchy work with the Chinese soon, and that you were going to work to their day.

Paul: That’s right. That’s what they’ve asked, if their day would start at eight a.m., which is one o’clock our time, one p.m. our time. We’re going to start at one p.m. and we’ll go through till 10 o’clock at night.

Kristin: The other way around it wouldn’t really work, because if they worked to our day, they’d have to be up before we went to bed basically.

Paul: There’d be a five hours time difference, so they’d be getting up at three o’clock in the morning.

Kirstin: That just doesn’t work.

Paul: Or four o’clock in the morning.

Kirstin: Where as one till 10 is OK?

Paul: Yeah, one to 10, at least it’s so we wouldn’t be asleep. We might be asleep.

[laughter]

Kirstin: You won’t to because you’ll be working.

[laughter]

Paul: That’s right.

Kirstin: It’s not out of the rounds of possibility.

Paul: It’s not a big time shift, where as 4 a.m. in the morning is.

Apparently we did…the point is that it’s open to negotiation and we could shift those times then. If next time we did this meeting, we wanted to say, have a normal day for ourselves and you guys need to get up at four or five o’clock in the morning. Then there is no reason…it’s not a huge shift.

Kirstin: I wouldn’t be getting up at four o’clock in the morning to do some of this Scrum stuff. I feel physically ill if I get up that early.

[laughter]

Paul: I’m more of the morning writer, so I’m alright with that time.

Kirstin: That’s not morning, that’s the middle of the night. [laughs] Anyway, it’s quite interesting. I’ll be interested to hear how that works out for you, working on the China time zone.

Paul: Yeah, it’s the reality of living in New Zealand. We do…especially if you want to tune into Webinars in the states, you have to get up early in the morning or nothing.

Kirstin: Or just don’t watch it live.

Paul: Yeah, that’s the other thing.

Kirstin: Always behind. We are actually in front though aren’t we? We do see the day first. Unfortunately the rest of the world’s behind us. Anyway, what else we got? There was something that you were talking about was, how do you have a team recognize that they can still make improvements?

Paul: That’s an interesting one. The team has got to a point where they have plateaued. They’re usually high performing or there much…that’s the general pattern with the Scrum team is they Form – Storm – Norm.

[laughter]

Kirstin: Form – Norm – Storm.

Paul: Is that the three?

Kirstin: Forming – Storming – Norming.

Paul: Yeah, so they have normed. Suddenly that norming, because they were on such a storm, on an increase in productivity, suddenly the norming feels like they’re not making any more progress. They have plateaued in terms of their increasing productivity.

Often the teams will come to you and say, “we don’t feel like we’re being productive” or “we want to increase our productivity” or they might even say, “we were already high performing enough”…we’re high performing so let’s just…

Kirstin: What happens in retrospective when a team believes they’ve gone as far as they can go? Do they just not come up with any issues?

Paul: They keep coming out with the same issues, and they feel like they can’t deal with them. They’ve seen that issue before.

Kirstin: They just put in the, to hard pile.

Paul: For a Scrum Master, at that point, your job is to use different techniques to try and flush out what those issues are and whether they are. If it’s a non-issue, then I’d say there is probably no point in wasting time trying to go deeper, but if you feel like there is an issue that needs to go deeper, then you need to find different approaches to get the team to tackle that idea.

Kirstin: A bit further. For example, you can do a, records analysis “The Five Why’s”.

Paul: “The Five Why’s” or the “Fish Bane Analysis”, that kind of thing, anything that goes into records.

Kirstin: Their both in Mr. Darby’s book right?

Paul: That’s right.

Kirstin: The “Rich Victor’s” book?

Paul: “Force Fed Analysis” is the other good records book.

Kirstin: Yeah, that’s in Mr. Darby’s book as well.

Paul: Yeah, that’s right. They’re really good techniques. The thing with the team they’ve got a type of forming as they go, you have to remind them that Carson, which is one of the agile principles which is, not the agile principles, sorry. It’s the in line philosophy of all agile is that Carson is a continuous improvement.

If you’ve reached the peak of your performance then you’re not really applying the principles of Carson or continuous improvement. You’re erasing all your morals. Then the next thing is to try and encourage the team to look at what they’re doing and understand.

There’s always room for improvement in my mind. For example, the team recently, they highlighted that they thought flow was that big issue. They got to a point where they understood Scram working really well but they couldn’t work out why some of their sprints were better than others.

Sometimes they had a very high velocity. Sometimes they had a low velocity and lots of stories carrying over into the next sprint.

Kirstin: There wasn’t a consistency?

Paul: There was not a consistency. The flow wasn’t there. They really focused on their flow. We used a number of different tools to analyze their flow, one of those being the accumulative flow diagram. Basically, just analyzing your keys and where things are getting delayed.

Whether it’s in the preparation for a story or when the story is being worked on, or waiting for acceptance or testing. You’re just analyzing each point in your process and saying what’s the delay? Which is queue is backing up?

Kirstin: Other things like that?

Paul: Yeah. We did that and those guys reduced as a result of that. They analyzed what they were doing and they reduced the size of their stories, which is one of the principles of Kan-ban to reduce the exercise and to reduce the unit of work.

Kirstin: To increase productivity and flow?

Paul: To increase productivity because increases variability and increases…

Kirstin: Increases productivity?

Paul: Yeah. Increases work flow. That team, that was there. Like I said, that team was already high performing but they recognized that they had some issues that they had to deal with. All teams have issues that they’re so high productive forming teams. It’s a shame that they got to the point where they feel like can’t deal with outside of their remit there. It’s not possible to address that issue. It’s a wider organizational issue.

Which is when the massive agile coach really comes in, it’s their job to unblock and go to work. Those issues are the meaty bits. That’s the time that the agile coach actually has a…

Kirstin: Which brings me on to another issue too which I may say, happens a bit. With my perspective it must be with the grand process. Firstly, it’s quite obvious that if you’re working with a new team you should lay out how it works. Which you might call prescriptive but it’s slightly the wrong word.

You need to teach them when the meetings are, what the meetings are, why the meetings are. Ideas like making stories small. How to sizing and things like that. I guess what we’re talking about is as teams are getting used to the new process, how rigid should we about enforcing process?

Paul: That’s a good question. It comes fairly regularly for me, in terms of the team. It wants to change something within Scram. Do we need to size our stories anymore? For example, the coach’s job then is to ask them, when they want to size stories what do they think…is to understand what is pushing their desire to not size stories? If they understand the principles well enough, then I don’t see why you can’t stop sizing stories.

If the reality is that you got all of your stories to similar sizes and they’re all two or three points in size. There’s no variation than that. You’ve reduced your unit of work to similar sizes than why size your stories?

Sorry, I thought we just lost the service little bit here. We’re getting a little bit of buffering, [laughs] distracting me. I guess that’s right. You had a team recently that wanted to stop sizing stories.

Paul: That’s right.

Kirstin: Have they stopped sizing?

Paul: No, they haven’t.

Kirstin: But they had a good chat about it.

Paul: They had a good chat. They realized it was lots of them. They’ve had new team members join so they realized story points are still an important part of the conversation. They really trigger that conversation around what’s involved with completing a story.

Kirstin: Leading to decide for themselves. If they had decided not to size stories any more, that’s really something we have discussed before about breaking the rules, isn’t it? Is it shoe hairy?

Paul: Shoe Hairy, yeah that’s it. The first stage is follow the rules. The second stage is bending the rules. Third stage is writing the rules.

Kirstin: I guess it is a bit of second and third stage think, bending and writing the rules. If it works, it works. Particularly with a very well established team. It is interesting that they had taken into account the new members of the team and decided to stay with the way it is at the moment. Maybe there will be time in the future that if the team stays pretty static in terms of members they will revisit the idea.

Paul: That’s right. It’s the coach’s job to talk to the team and work out if they understand the underlying principles, the Agile principles. If they do, then there’s no reason why you can’t have that discussion about changing the rule.

Kirstin: As opposed to saying, “Oh no you can’t do that because this is absolutely something we must do in this process every single time.”

Paul: Very early on though, the usual things that crop up is, “I don’t see the value in stand ups. Why do we bother with stand-ups? I don’t see the value in retrospective whys. Let’s not do retrospectives.”

Kirstin: Go back to the story that I’ve repeated before in here. When a team I was working with, an internal team on an internal product decided to make a change in regards to the retrospectives. Which was they didn’t want the product owner coming to the retrospectives any more. He didn’t attend.

What he found was the team was coming up to him in the course of the sprint to raise things that would normally come up in the retrospective. He rejoined. The point being there is that the team still decided. They had to discover for themselves why that wasn’t working. It wasn’t like, “You can’t exclude the product owner from this meeting. It’s not the done thing”? Fine, let’s see how that works out.

Paul: It’s a really tricky situation when a team that needs a Scrum comes up to you and says, “We don’t want retrospectives.” Or, “We want to change the retrospective.” What do you do in that? I would say there are two schools of thought. Either we drop the retrospectives and let the team work it out for themselves. If they haven’t gotten that much experience with retrospectives, then they probably haven’t seen the value in the retrospective in the first place.

Do you just push them through to make them see the value of the retrospective? Do you find different ways of running the retrospectives? Do you allow them to run their own retrospectives, for example?

Kirstin: That’s a choice. I personally say, “Let’s persevere with another couple then revisit the idea so you can get a taste for how they work.” It’s a compromise for a new team.

Paul: Joe does a great thing. Joe is behind the camera at the moment so you guys can’t see him. He does something cool, an opposite thing which is something they have in the States. They describe the complete opposite of how they are feeling. This is quite a technique. It is called reverse brain storming or something like that. Instead of brainstorming how an idea would look. You brainstorm how it wouldn’t look. You brain storm….

Kirstin: For example, if you weren’t finding the retrospectives were valuable, you might say something like, “I’m finding retrospectives really valuable at the moment.”

Paul: Say the team suggests no longer running retrospectives. You could reverse brain storm and say, “What would it look like if we didn’t run retrospectives”? Instead of saying, “What are the values in retrospectives? What is the value in not running the retrospective”? It just sees things from a different angle. It’s another Dolby technique.

I’m probably paraphrasing and misquoting the technique. It is something I have found quite useful in my retrospectives when people are stuck on fixing an idea or trying to work out how to resolve a problem they’ve got. Often, reverse brainstorming helps.

Kirstin: We are having problems with the stream at the moment. It keeps buffering. We might wrap it up for today anyway. Given its 11o’clock. Thanks for joining us. We’ll see you in two weeks time.

Paul: Please, if you’ve got any ideas for things you would like to see on future shows, please get in contact with us.

Kirstin: Very happy to discuss what you would like to talk about.

Paul: We would actually love more audience participation. We’re looking for your questions please. Thank you.

Kirstin: Thanks.

You can check out this episode on our Livestream page.