Posted by Daniel Burm around lunchtime: January 13th, 2012
Scaling the productowner (PO) role is tricky business. When you scale up too much within the same context, things become cumbersome. We don’t want to bring back the same centralized fear ridden ineffective decision making climate, we tried to kill off in the first place. When people spend so much time and effort to bring back entrepreneurship, they don’t want to create layer over layer of hierarchical PO/CPO relationships.
So if there is this perceived risk of fallback involved, why do we actually want to scale the PO role at all?
(more…)
Posted by Daniel Burm in the late afternoon: December 23rd, 2011
My motto regarding innovation is: being a first mover is a strategic choice, moving fast isn’t. Agile and scrum can help you move fast, so how can it accommodate innovation?
Posted by Daniel Burm in the late evening: December 8th, 2011
A walking skeleton as meant in scrum is not always feasible. That’s the first sentence of one of my previous blogs. This one starts the same but approaches the subject from a different angle. The angle here is that we teach people to make story maps based on personas; the user, administrator and so on, but we don’t actually take into account that the product has to be bought by someone and how that decision actually works. This blog post tries to tie complex buying decisions into story mapping, to find the shortest route to a sellable Frankenstein, rather than a mere bag ‘o bones.
(more…)
Posted by Daniel Burm around lunchtime: November 1st, 2011
A walking skeleton as meant in story-mapping, being the minimal marketable/ shippable feature set, is not always feasible. When working from existing system environments I am quite inclined to argue that in these situations it is often the best route to base your first product slice on risk rather than end-user value, but only if the support is there to enable you.
(more…)
Posted by Daniel Burm in the early morning: September 16th, 2011
Agile companies that want to create real ownership, have to say goodbye to traditional stakeholdership and embrace “joint company stakeholdership”. Remain to be an old-skool stakeholder in an agile environment and you will possibly act as a “stakekeeper” instead of a “stakesharer”, therefore withholding the company “staketakers” from focus on value and real ownership of results.
(more…)
Posted by Serge Beaumont in the wee hours: September 12th, 2009
In my previous posts about the definition of READY and Flow to Ready, Iterate to Done I have tried to shed some light on the Big Black Hole of Scrum: the Product Owner. This is number three in the series.
In my previous blog post I presented the stages that a backlog item flows through before it gets to Ready. But those were the ideas behind it: in this blog post I’ll show how I’ve implemented them in practice. I’ll show you two interesting examples.
Posted by Serge Beaumont at around evening time: July 4th, 2009
In a previous blog post I introduced the definition of READY, and I wanted to do another “context” blog post before starting on this one: on the difference between flowing (“kanban”) and iterating. However, I had much more to say on the subject than I expected, so the thing kept expanding… I’ll gather my thoughts and publish that one later. So for the purpose of this blog post just bear with me: I find that a Product Owner’s job is best done in a flow style. And since my dear ex-colleague Lars Vonk told me he was waiting for this post, I’ll just explain the how here. Lars, here you go… 
Update: the third of the series is also done. See here.
Not all backlog items are equal. A backlog item starts out as a rough sketch – usually just the As a.. I want… So That… stanza – and needs to be fleshed out to the extent that it can be picked up by the team in a Sprint. Just like a team has a basic workflow getting stuff to Done, the same applies for the Product Owner role. Scrum does not have any specific support for a Product Owner: somehow the Product Backlog just “happens”. In this post I’ll try to fill that gap with respect to the process that a Product Owner can follow.
I’ll explain a partitioning of the backlog that maps onto a flow, the nature of those partitions and how you proceed through them to get enough stuff Ready for the team to pick up in the next Sprint.
Posted by Serge Beaumont around lunchtime: June 19th, 2009
Yesterday I gave a presentation on the Integrating Agile conference on the answers I have found in what I consider to be the Big Black Hole of Scrum: the Product Owner role. Based on the feedback I want to blog about this subject, and unblacken the hole a bit…
Edit: the link to the second post in the series turns out to be buried too much at the bottom, so I’m adding it at the top: See Flow to Ready, Iterate to Done
The Definition of Ready
I give CSM trainings with Jeff Sutherland, and about half a year ago he had put something in his material called “the dynamic model of Scrum”. The essential feature was the addition of a READY state opposite the DONE state. The idea here is that a team needs to be in a stable, known situation to be able to perform well. It immediately struck a chord with me: I had seen so many teams thrash because the Product Owner could not give them a clear objective, the READY state was exactly the goal to work to. But what was it really, and how do you get there? By now I think I’ve got some good answers to these questions.
Posted by Machiel Groeneveld in the early evening: May 22nd, 2008
The Product Owner role in Scrum
In the Lean Software Development method Scrum there are three roles: the Team, the Scrum Master and the Product Owner. In my experience the Product Owner role is by far the most confusing and hardest role to ‘get right’ and provokes the most discussion. Even the mere definition of what this person should do is under debate amongst most Scrum practitioners I’ve talked to. I want to discuss the origins of the Product Owner role and my experience in how (not) to fill this role, especially in companies that don’t do product development.
The mythical Product Owner
I’ve seen many flavors of Product Owners and none of them really worked as they should have. Actually, rumor has it that good Product Owners actually don’t exist. Now that’s something we should be frank about if that’s true. If the Product Owner is a combination of responsibilities that doesn’t work in practice, we should find some alternative. First, I’ll explain my experience so far.