Kanban Isn’t the Answer to Bad Product Ownership
The Scrum Product Owner has a tough job. Translating business strategy into product strategy and ultimately into teeny-tiny user stories takes a ton of time and effort. Most Product Managers don’t have the time or inclination to be a good Product Owner and most Business Analysts, the people most likely to fill the gap, don’t actually own the product. I almost always recommend to my clients that a team of people work together to fill this role. I don’t really care about the whole ‘single wringable neck’ thing… all I want is well groomed prioritized product backlog, and I think there is more than one way we can get there.
Here is the deal… when teams can’t get well groomed product backlog, it is almost impossible to do Scrum. Teams spend too much time figuring out what to build during sprint planning and not enough time figuring out how to build it. Because teams don’t know how to build the stories, they never really consider if the stories were estimable, nor really discuss how they could swarm to get the stories done earlier in the sprint. This will often result in teams of people that don’t work as teams, daily standup meetings that suck, and missed commitment after missed commitment. Not fun.
Anyway… as Kanban gains popularity and mindshare, many folks think that going iteration-less is the answer. If we can’t get user stories that are small enough to deliver a handful of them in a sprint, and we are always missing our sprint commitments, the problem must be with the time-box itself. If the time-box has no value… it’s unnecessary…. it’s waste and needs to be eliminated. Maybe what we need to do is just take these big chunks of undefined requirements, run them through a Kanban, and just forget about splitting stories and managing iteration boundaries and totally avoid the issue altogether.
I’m all for eliminating waste, but let me ask you this… how does an iteration-less approach better help us know when we are going to be done?
Like it or not, this whole done thing is going to keep being a thorn in our side. It’s not going to go away anytime soon. I think people are hardwired to want to know what they are going to get for their money before they agree to spend it. Some of us desperately want this to change, and maybe it will change as business models change, but for now we have to deal with it. I know, I know… if our customers would get out of the way, just let us code, and stop asking what they are going to get for their money, life would be a whole lot simpler. I get it… it’s just not reality. At least not my reality.
Okay, back to Kanban… Kanban can answer the ‘what are going to get for our investment’ question just as well as Scrum can. Scrum answers the done question by having us know the size of our backlog and the rate at which the team can complete that backlog, in other words, our velocity. When we know both of these variables we know what we are going to get, when we are going to get it, and we have a way to communicate project status. Kanban doesn’t use velocity, but instead measures cycle time and standard deviation to help us figure out what we can deliver and when.
In Kanban, we still have a queue of necessary features, but rather than measure our velocity sprint to sprint, we measure how long different sized stories take to complete and how much variation we have in that number over time… that’s cycle time and standard deviation. When we know the size of all the items in the backlog, and the normal variation of all the items in the backlog, we can use that data figure out when we are going to be done and what we can deliver in any given timeframe. That’s good… there lot’s of ways to answer the done question… we just need one of them.
So, we’ve gotten rid of the time-box, but have we actually solved our problem with predictable delivery? For Kanban to be predictable, we need know the rate at which we deliver requirements, and reduce the variability between the requirements over time. Let’s ask this though… if we don’t know really understand what it takes to build the requirements in our backlog, are we going to know our rate of delivery? What about our standard deviation? It’s going to be all over the place. Unless we know something about what we are building and how we are going to build it our delivery process won’t be any more predictable that if we were using Scrum.
I’d suggest that in both Kanban AND Scrum… to increase flow and reduce variation… we break things down into smaller more similarly sized and well understood work items. In short, the same things that break Scrum are the same thing that breaks Kanban. And therein lies the problem… If we have to answer that pesky done question… we have to break things up small enough that we can tease out the risk and uncertainty, make fine grained trade-offs, and all get on the same page about what we are going to build. Kanban can solve lot’s of problems… and I believe we don’t even yet fully recognize the importance of David Anderson’s contribution… but here is my belief…
Kanban isn’t the answer to poor Product Ownership.
Comments (14)
Jim Benson
Mike,
Maybe the role isn’t well suited for the task. Kanban doesn’t replace the PO, but clarity may well do.
The PO is a dysfunctional response to traditional poor communication. It creates a bottleneck for information, responsibility, and blame. The role is hard to fill because of its current definition.
Maybe we should hire a PO for the PO role and ask “What was the PO supposed to do in the first place and how can we make something that works better?”
Jim
François Gyöngyösi
Well, nor Scrum nor Kanban are answers to bad product ownership… and the same applies to waterfall methodologies or whatever methodologies you want to use. It seems to me that you’re lacking context.
To give you an example, I work in IT and I am in charge of the financial planning, consolidation and reporting systems in my company. Nothing sexy but it has to be done! We have several internal customers (various groups in Accounting, Business Planning and Operations) and some of these customers have their own business analysts to represent them.
We successfully used Scrum on one of our projects recently. It worked well because the project focused on one specific business area (our Product Owner was the manager in charge of the Accounts Receivable department) and my team could focus on the project (we delayed all other changes to our systems and luckily didn’t have to provide much support).
However, we now are back in “maintenance mode”. For example, we now have requests linked to change in VAT, financial consolidation rules, system performance, sales margin analysis, major support issues, and so on. And some of these changes came from nowhere. Priorities have to be changed from one day (or a few days) to another and Scrum just doesn’t work well in this context i.e. I cannot wait for the next sprint to address some stories or provide support.
And who’s the Product Owner? Well, we started to address this question with our internal customers. Not forgetting that the IT folks have their own “stories” too (technological changes, system performance, technology watch, etc.). I guess each context is different and one has to figure out the best way forward. We’re still trying to combine the best of Scrum and Kanban (and XP when I think about it!). Agile is such a vibrant community. Love it! By the way, these are very old issues (defining priorities, project versus maintenance work, program or portfolio management, etc.).
By the way, didn’t see a word about ScrumMaster (KanbanMaster?) in your blog! Maybe he or she could help?
Jason Little
I don’t think any process is the answer to organization structure problems or other organizational dysfunctions. I’ve had mixed success with Kanban. In instances where its been effective, it’s because the team using it understands how to apply it in their context. I’ve seen teams doing mixed-bag type of work (support, maintenance and development) really benefit from it. I worked with one team that tried using Scrum and was frustrated by numerous interruptions and priority changes because of the type of work they were doing move to Kanban and really benefit from it. It was their ‘aha’!
I wouldn’t put all the onus on ‘bad product ownership’ though. I joined a team that had been using scrum for years and had no predictable delivery or velocity. As I tracked it, velocity bounced from 5 to 50 to 12 and everywhere in between. The cause was frequent interruptions and priority changes which I don’t believe is well suited for scrum. This team had tried Kanban before and to quote their manager “Kanban is all BS, you just keep working, never finish anything and never release”. They had tried Kanban without limiting wip or setting any ground rules because they didn’t understand what Kanban was, only that the existing process didn’t work. We tried again and ‘the process worked’, but we weren’t working on the right work. Once the structure of the organization changed, the system was setup to focus on the right type of work.
The bigger problem I’ve seen with product ownership is not having an empowered PO, having the team expect the PO is the ‘guy who writes the stories and hands them to the team’, having too many or wrong priorities, having a team who keeps using the same process without adapting and ‘hoping’ things get better and many other factors.
I like Jim’s comment very much, the expectataions on a product owner along with ” the single wring able neck” are part of the problem. At the end of the day, a great team understands how to adapt to reach their goals, mediocre teams at going to be happy to plug away blaming the process or PO or the organization.
Jamie
Yeah, agree with Mike, the PO is an utter dysfunction, designed by programmers for programmers because they didn’t like speaking to business people. That we speak about these processes here as if they, and a dysfunctional role, are important really does show how mucked up our thinking has become.
Scrum, Kandan, the PO, are best practice – i,.e. dogmatic – solutions to a simple problem. Software development is complex. This mismatch is why none of this stuff is working.
Jamie
Sorry, I meant to say, agree with Jim! (Sorry Jim ;-))
David Adams
To Francois’ point, any methodology will struggle or fail without good Product Ownership. In the absence of that leadership, success is difficult to measure (-therefore attain-). When you have it and reap the benefits of it (good prioritization, good conversations, shared understanding), projects tend to success. When you do not and suffer the consequences (shifting priorities, unavailable representatives, meandering development teams), projects tend to failure.
I agree with Mike in his challenge to continued attempts to identify a “single wring-able neck” which almost always creates a bottleneck for forward progress. In a methodology that promotes transparency and seeks to avoid blame, this hold-over to the blame culture probably does more damage than anything.
Unfortunately, it is this specific challenge that leads so many organizations to abandon or tinker with methodologies because “it is not working”. It is their very dogged attempts to hold onto some of these aspects of having someone to blame that continues to promote distrust between Product Owners and Product Teams. The net result is hack-job interminglings of “processes” that seek to “solve” their problem of the day (usually creating two more).
Personally, I’ve developed a name for this “methodology”:
Wat-ScrumBut-Agi-Lean-Kanban-erFall
Maritza van den Heuvel
Hi Mike
I’m a PO, and I have been now for almost four years. Some say I’m quite good at being a PO. But not a day goes by that I don’t struggle with and/or question the PO role and how it operates in many companies. This year in particular has taken me on an intense learning journey, having moved from a company where I was the single wringable neck for two products to being one of four POs, responsible for various aspects of a single product. I’m also a big fan of Kanban, and I even have my family practising it. ;-)
But I don’t see Kanban as the solution to product ownership either. I strongly believe in limiting work in progress and visualization as ways to bring the real system to the fore and exposing problems in how we work so that these problems can be addressed openly and transparently. Value streams, policies and SLAs, play an important part in helping teams pick the right work at the right time, based on available capacity.
Somebody still has to feed those value streams though. That work doesn’t come out of thin air. And if the work that is fed into those streams do not match business priorities, then the business is still not going to get the desired throughput of value. Having Kanban *localized* in your software development teams is not going to fix that.
But can the PO role fix that? I have my doubts. Right now, in most organizations, POs (either single or teams) as currently defined, stand in for the fact that their is no clear alignment in the business as a whole. It has a lot to do with poorly executed fuzzy front-end of product development – requirements gathering, understanding your markets, your value proposition, global stakeholders, aligning execution and tactics with strategy – across the business as a whole. This funnel, starting with the top leadership, and working it’s way through all stakeholder departments until it hits Product Development, is generally not functioning well at all. Oh the horrors I can tell of departments in the same company having strategic annual goals *diametrically opposed* to each other that result in *fundamentally different* development requirements …
We expect POs to fix that, because we do see the problem, but we think it’s a development problem. It’s not a development problem. It’s an organizational problem. We need to fix the funnel itself. We need to fix the business value stream as a whole and ensure that our teams are aligned with the real value the business wants to create.
And this is where I think Kanban can help. By continuing to expose the misalignment and expanding the value stream across the business as a whole, you have a greater chance of this alignment happening. But it’s not going to happen magically all by itself.
There’s something needed for it to work: Real, courageous leadership at all levels of the organization. People need to ask the right questions about the problems that are exposed and need to be empowered to contribute to fixing them. Without that, it’s just another process model that we all follow dutifully until we realize one day that it’s not working – and then we toss it out in favour of the next “New Thing”.
Maritza van den Heuvel
However … if we are going to continue with the PO role, I think PO teams are the best way to maximise the PO role as currently defined. Such teams have the potential to start fixing the broader business problem through more direct integration and collaboration in the business. I actually explored various PO team models earlier this year at the Scrum Gathering in Cape Town, building on some of your great ideas on PO teams. IF done right, PO teams can work and provide POs with meaningful work within a more aligned business context.
Tom Howlett
I think Product Owners are being treated unfairly, we generally take people from a business background and ask them to be a bridge to the developers, they need to understand the development mindset which unfortunately is completely alien to most business people. It takes time and learning to really appreciate what is required and I think the Scrummaster is in the best position to help with this. As long as the PO is collaborating with the dev team the change will come, but we can’t expect the change to happen overnight, we just need to ensure we are sowing the right seeds and providing PO’s with the support they need.
All great comments everyone. My family and I are away on holiday this week (WordPress is auto-posting for me while I’m away) and will reply when I get back. Thanks for taking the time to share your thoughts!
Henrik Berglund
Hi, did you forget to moderate my reply? Fells like i may have wasted my time contributing
Best
Henrik