Effective Product Owners, Backlog Grooming And Continuous Delivery

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich.

Derek Neighbors: I’m Derek Neighbors.

Roy vandeWater: I’m Roy vandeWater.

Product Owner Availability

Clayton: We’ve got a few topics today. The first one we start out with is Product Owner Availability on a Scrum team. If I’m a product owner, how available should I be to the team? Should I be sitting there, waiting for them to ask me something?

Roy: In my perfect world, yeah. You’ll be sitting with the rest of the team, not necessarily waiting to be asked something but you’re available if something is needing to be asked. In the mean time, there’re some of the other things that you can do, like backlog grooming and communication with stakeholders, that type of thing.

Clayton: You’re saying actually be available…if the team needs something from me, I should be available almost immediate?

Roy: I don’t know about should. If I was a team member, that’s what I would want. I don’t know if that’s realistic to set an expectation like that. I don’t know if I can say, “You need to be available within two minutes of me having a question”. That might be a bit excessive.

Derek: I would say as close to immediate as possible, is desired. What is doable is an entirely different story, probably for every team, every organization.

Roy: Every product owner.

Derek: Every product owner. Part of availability is…we were talking about Jim McCarthy before we came in here, and the Core Protocols. One of them is presence. Physical presence of a product owner is key to availability because its not just about being able to ask questions, but there’s also a fear of how do we talk about product.

There’re so many times as a developer where you’re working on something, and you’re really talking not about code, but you’re talking about experience or you’re talking about a functionality or interpretation of conditions of satisfaction or acceptance criteria, whatever you want to call them. Where if there is that kind of physical proximity or presence, it allows for a product owner to say, “Hey, that doesn’t really matter, don’t bother arguing about it. Just go ahead and implement it.”

Or, it allows them to basically jump into the conversation almost immediately. One of the things that developers tend to do is not talk the product because they think they’re not allowed. When we come from this world of requirements, once a product owner tells us A or B, like we are incompetent if we have to go back for clarification. I think that availability to clarify is monumentally important.

Product Owner Dysfunctions

Clayton: What are some maybe dysfunctions? A lot of product owners probably are not that dedicated to the team and they probably spend a lot of time in meetings or on the phone or doing whatever. What are some problems you might encounter if you don’t have that presence of the product owner?

Roy: What I usually see is it really screws up the planning meeting for multiple different reasons. The first being, is that because the product owner wasn’t available throughout the week, I’ve seen a lot of teams wait until the planning meeting to get acceptance.

Clayton: Is that like wait until the retrospective to talk about things?

Roy: Right, because it’s the last minute that you could technically get acceptance before the next thing. Obviously, you should be doing it as soon as you finish feature, like as close to that as possible. I’ve seen a lot of teams wait until they are in planning.

The other thing that happens during planning is because the team is so fearful of needing to ask the product owner questions throughout the week and knowing that the product owner is going to be available, they’re going to want to like squeeze the product owner dry during the planning session which makes it really arduous. They try to think of everything that could possibly go wrong ever because when it does happen, if it does happen, they might not have that product owner there to ask.

Derek: I definitely think that you get a sense of people get fearful when they’re making commitments, if they don’t think they have all the information, if they think they’re only getting one chance to get the information. If you have a lot of uncertainty in product ownership during a sprint, teams tend to be more fearful to actually committing to work.

Where I think if you’ve got the higher certainty, teams tend to be a little more willing to commit to things knowing that they’re not going to be blocked by something out of their control, in essence.

INVEST Stories

Clayton: We have been talking about product ownership. Kind of related to that are stories. I was asking Derek today about that the new moniker for “INVEST” about stories. The V in there is for value. We talked a lot about delivering value to the customer.

What do you guys think about stories that might deliver value in the future but if it were shipped tomorrow no one would use it. No one would get any value out of it. Is that even worth doing? Even if it’s maybe a building block to something?

Roy: That sounds dangerous. Usually, when I hear of somebody think of a story as a building block, they’re slicing the cake the wrong way. You know what I mean? That would be my primary concern. If it’s not really adding value to the user now, then why are we building it now?

Derek: For me, I hate this whole value discussion more than anything in so many ways, because nobody can really define value. I’ve gotten into Twitter arguments over this that made me want to pound my face into the concrete.

For me the question becomes like, “What are the goals?” What are you trying to do with this product? Are you trying to make money with the product? Are you trying to influence people with the product? Are you trying to get more users with the product? Are you trying to not lose users with the product?

What is it you’re trying to do? For me, where’s the data that backs up that this particular story helps you get closer to that goal? If it’s a building block, “Hey, we need to do this so that we can do that,” I’m OK with that.

I get worried if it’s a technical building block like, “Hey, we need this technical building block in order to do this.” If it’s not really a technical building block but rather, “Hey, we need to implement this so that we can track this or so that we can add this additional feature, and that’s what we really want, and we believe that’s what we get there,” I’m OK with some of that.

To me, most product owners can’t tell you shit. “We’re just doing this because it feels good or because the users are screaming about it or because it’s what we pulled out of our rear end before we came into this planning meeting,” which is probably not delivering value.

If people came in and said, “We’re doing this because we’re losing users, and we really need this functionality in order to keep those users,” or “Hey, we’re trying to get into this new market or this new piece, and we need to add this functionality to compete with so and so, so we don’t lose market share of that,” then we’re having a different discussion.

I’d say if product owners aren’t talking in that kind of language, they’re probably not doing due diligence around value delivery.

Throwing Away The Backlog

Clayton: Do you think there’s some amount of…maybe fear is not the right word, but if you got a bunch of stuff in your backlog, and maybe you’re not thinking on those terms about that way of thinking about value. If you were to actually do that, it might mean that you would have to throw away almost everything.

You might have to get rid of a lot of stuff, which is scary. Is it better to keep prodding along and hopefully you can find a few things here and there that actually do deliver value, and then it’s OK that you did some stuff that maybe wasn’t so important?

Roy: So you’re getting value out of having a large backlog? That’s what it sounds like to me.

Clayton: It lets you fly under the radar to someplace…

[crosstalk]

Roy: Right, because you can say, “Hey, we need to extend the budget for this team because look how much work is left.”

What Is Product Afraid Of

Derek: Some of it is, a lot of teams or a lot of product owners get fearful of “if the backlog’s not really big, then the product’s not important.” There is something to say that there is value in being biased towards action.

Sometimes maybe if you don’t know what’s valuable, not doing anything could be detrimental in the sense that you’re not moving forward at all. However, if you’re moving forward and saying, “Hey! Action, we’re delivering stories,” you fall in the potential of iterating to nowhere where the product is just spinning its wheels.

It’s very similar to developers in the sense of, developers really get nervous about measurements. If you talk about velocity or estimating or anything, most developers freak out on that and want nothing to do with it because they think it’s going to be used against them or that they might be seen as failures. You name it.

Product owners are the same way. If you start to say, “Hey, this feature should drive revenue by X,” and it doesn’t. “I was wrong. I failed.” Or, “Hey, this is going to land us a new customer,” and it doesn’t. “Shit! I failed.”

There’s that same mental block of, “I don’t want to do the research and make predictions about what functionality is going to do for this product because what happens if I’m wrong?”

Roy: Regarding the idea of having that big backlog just to keep the big backlog around, there can also be a difference between having a cluttered backlog and a large backlog because what I’ve seen is… and what you described, keeping a bunch of random stories thrown in there that may or may not actually add value.

Derek: That would be moved to the bottom every week.

Roy: Right, exactly. You can still have a large backlog and still say, “We have a year’s worth of work or whatever in the backlog,” but have really large epics.

Let’s say you want to build out a whole new component. Instead of breaking that down early, don’t waste your time on that, just say, “We’re going to have this gigantic new component at some point or deliver that giant piece of value.”

If you get to it and it becomes a priority, then you start to break it down as it gets closer and closer to when you actually work on it. That allows you to keep a really clean backlog because most of your really far out stuff are abstract ideas that haven’t been worked out.

Break Things Down The Further Away They Are

Clayton: If we agreed that things that are further out time‑wise are maybe not worth spending a lot of time breaking down, world changes kind of thing, do you think that the frequency of your delivery or your deployment makes a big difference?

If I only deploy once every four months, does it even make sense for me to worry about defining things that I want to do in 9 months or 12 months because I’m only really ever going to deploy four times a year? Maybe…

Derek: I could see that.

Clayton: Does that make a difference at all?

Roy: There are companies that do budgeting on an annual basis. You might need it for that, to be able to justify your budget for an entire year’s worth of work. I could see a product owner needing to do that.

Its Not About The Release Its About The Release Plan

Derek: For me, it’s probably less about when you release and more about what are release plans. There are a lot of people that do release plans, but don’t really release.

When you start to do more continuous delivery, it starts to make your release plan, a hell of a lot more real. You are actually owning what you’re releasing because you’re releasing consistently.

Where when you release infrequently or you deploy infrequently, you can constantly move your release date around. You can start to say, “Oh, it was supposed to be six weeks, but now, it’s going to be 8 weeks or it’s going to be 10 weeks or it’s going to be 12.”

You can keep moving that stick and have that perpetual, “Let’s just add more shit into the product before the next release.” Where if you have that continuous deployment happening, you don’t get the ability to say, “Let’s keep dicking around with our release date. It’s going to our customers at the end of the week, at the end of the…,” whatever…

[crosstalk]

Roy: With or without this feature.

Derek: No matter what.

Continuous Integration vs Deployment

Clayton: You mentioned continuous delivery or deployment, there was a good infographic that was going on that simplified those two terms. I believe that continuous delivery was, everything’s automated from my checking the code, and the tests run on the CI server and maybe it gets deployed to some staging place and acceptance tests run.

The action of actually deploying that to the customer is a manual step. Whereas, continuous delivery was more of…

Roy: Continuous deployment.

Clayton: …the whole thing was all automated. Sorry, deployment, yeah.

Derek: Integration versus deployment, right?

Clayton: The idea, and you had mentioned maybe Twitter and Facebook have a model that’s like this, where I make some code changes and it goes out. It doesn’t necessarily go out to facebook.com, but maybe, it goes out to some subset of the server so that some part of the user base might get that, and that kind of thing.

Roy: Roll that out to everybody outside, and know that it is completely automated.

Clayton: No, I would guess most people, especially if you consider yourself an enterprise kind of company, the idea of pricing commit and your search control and having that go out..

Roy: So any developer could commit a code directly to our users?

Clayton: Yeah, and the idea that everything is green, we ship, is probably pretty scary. Do you think a lot of people could gain from having a system like that?

Roy: Man, talking about having to own your work. Talk about pride in the work.

Clayton: That’s true.

No More Feature Freeze

Roy: I mean, seriously. One of the early stories that had came from Twitter and had impressed me is they had gone online live with Oprah. Biz, or one of them, was on…maybe with Ev was on Oprah and they were doing deploys during the airing of that show.

That would be normally completely crazy if I’m some big company, if I’m Ford or something, and we have this big Super Bowl ad running, I probably am going to tell everybody, “No deployments for the next two weeks because we have to deal with all this traffic where…”

Clayton: Feature freeze.

Roy: With a company, like Twitter, the problem is they had to. They didn’t have a choice. Their system was growing so dynamically that adding an extra million users during an Oprah show had a real effect to the performance of their system to where, “OK, yeah, we could wait until the west coast showing views,” and then, start screwing around with things.

But then, the experience is crappy for everybody. Or “We could go in and see this performance bottleneck that we see right this minute, make the change, deploy it to a small subset of users, make sure that nothing is coming back failing. Then, let it propagate into the entire base.”

Which is a worse move? Looking bad performance‑wise or trying to fix those on the fly and then, if something goes wrong, having to recover.

Part of it is when you got to continuous deployment, you are a whole lot less afraid of doing those things because you do it all the time. If you’re deploying every commit, your process is probably pretty damn solid if something goes wrong, being able to roll back.

If you only release once a year, your process is probably so crappy, that if something goes wrong, it is like…

Clayton: A week‑long thing.

Roy: …catastrophe for months to clean it up. That plays a lot into it as well.

Continuous Integration As The Buiding Block

Clayton: One of the things I really like about continuous integration is the idea of having the code, basically, be able to compile and run all the tests. All the benefit you get from that is so far beyond the fact that you have a good CI server, but all the work that goes into making that actually happen, I think the same thing is true for continuous deployment.

Although, at a much larger scale. If you only deliver once a year, it’s OK if everyone spends two weeks doing a bunch of manual stuff because it doesn’t seem that painful.

If you’re doing it every two weeks or something, that subsequently going to get automated real quick and you’re going to fix a whole bunch of stuff. Especially, the roll back stuff, the fear just goes out the window at that point.

Roy: If you’re doing continuous deployment where it’s going out as a constant stream, then it becomes even more so. Then, if you check‑in some bad code that breaks a build and I need my feature to go live now, we need to have that conversation now because it needs to be out by the end of the day, so none of that stuff gets postponed.

Clayton: Probably, the chances of people breaking the build as casually as they would, otherwise, is probably much lower.

I think that wraps it up. We’re at our 15 minutes here. Thanks you guys.

Derek: Thanks.

Roy: Bye‑bye.