Sunday, September 30, 2018

The Product-Owner as an antipattern

Do you know a project with a real product owner?

The clue is in the name. It actually consist of two parts. ‘Product’ and ‘Owner’. Most POs (as product owners in my neck of the woods tend to be abbreviated) neither have a product nor do they own it.

Recently the PO topic came up in a discussion about The Rules of The Scrum Process. (FWIW: Scrum is not a process but a process framework and thus the ‘rules of the game’ apply to the meta-level and transcend only transitionally to the implementations)

Case in point: Does Scrum allow the PO to be present at the Daily Scrum? Notwithstanding the endless options to find the right answer (see sidebar),

e.g. due to the different possibilities to emphasize todays scrum guide’s “The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.” –one could either stress the internal meeting part or the others are present part, or the multitude of possible interpretations for the quote “Anyone who needs to know what’s going on with the project can come to the daily scrum and listen”[emphasis added] from Ken Schwabers original book, [p40].

the most important question for me was:
“Why is it so important to answer that question?”

It turned out that the developers in that team where afraid that the PO would be worried by what he would hear in the daily scrum, the scrum master was afraid that the developers would not speak as openly as necessary if the PO were to be present.

For me this situation contains an alarming amount of alarm signals with regard to the scrum values of openness, courage, and respect as well as for the scrum pillar of transparency.

If Product Owners are frightened by the things they hear in the daily scrum –and worse: take action based on the information they gather from the daily scrum- the Scrum Master has a lot of work on her –or his– hands to establish transparency and foster courage. (But please keep in mind that it’s not yet possible to install values.)

A tangent on this topic was that the Product Owner doesn’t understand the developers and thus should not hear them talk amongst themselves about challenges they face. To me, “The PO doesn't understand the developers” is a very good description for a (team-) culture that is quite dysfunctional for Scrum.

[So perhaps scrum isn’t the best choice for the situation at hand - how about trying FDD or DSDM? But I digress]

Of course the Product Owner doesn't have to know everything. Quite the opposite actually: they are even encouraged to delegate. According to the 2017 Scrum Guide: "The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable."

Of course, if the Product Owner does delegate some of their work to the team, that would probably turn up on their task-list as well. And since “Ensuring the Development Team understands items in the Product Backlog to the level needed” is also part of the PO’s responsibilities, they would have to interact with the team even more. Probably even become part of the team. Which would nicely fit with the old eXtreme Programming value of the on-site customer.

So why did I call the Product Owner an anti-pattern?
Because most of the time they aren’t. They neither have the final say regarding the ordering of the items to implement, nor do they have a real chance to influence the economical outcome of the work. They simply don’t own the product.

So perhaps –whenever we see a Product Owner who isn’t– let’s take a step back from using the Scrum term of product owner and look around for things that are actually happening (Kanban people might call that: “start with what you do now”).

Perhaps even try to look out for some other agile process templates which maybe fit your reality more closely.

till next time
  Michael Mahlberg

Sunday, September 16, 2018

What is a commitment point anyway?

In some way, commitment is part of almost all project work. The term used to be part of the planning ceremony/event in Scrum (actually it has been for quite a while since one could find the snippet ‘commit’ outside the ‘values’ section of the scrum guide. See the history of the Scrum Guide, section “Changes between 2010 and 2011” for Details) and the term ‘committed work’ comes up over and over again when talking about flow based systems. (Those flow-based development processes often come together with application of the Kanban Method)

Commitment in Scrum

Even though the notion of committing (and thus promising) to the result of the planning meeting has been thrown out of the window some years ago, the notion is still very much alive out there in the fields.
The general idea here is that the team commits to a Sprint Goal often backed by a bunch of backlog items, and the ‘commitment’ here is the (not always realistic) idea that the team will deliver and reach the sprint goal by the end of the sprint. Which is actually consistent with what Ken Schwaber wrote about Scrum in the early years – you might remember the ill-suited story of the chicken and the pigs that also vanished from the Scrum Guide between 2010 and 2011.

The main takeaway here is that with this kind of planning commitment relates to the result and says nothing about the way the work is performed.

Commitment-points in Kanban-Systems

In the World of Kanban the notion of commitment is different since Kanban is not a software development process but a set of principles and practices for process improvement and organizing work.

Many of the processes which teams create with Kanban tend to be flow based and thus ‘commitment’ most often refers to a point in the workflow where the ‘unit of work’ is committed into the system. From here on its flow is governed by the process policies (working agreements) and WIP-Limits.

A while ago I wrote about a problem with unbounded –or uncontrolled– columns for requirements and how it can be addressed by making only promises about things that are under voluntary control. This is actually the introduction of commitment points.

The change from red to green in the last picture of that article illustrates the commitment point for the development workflow. From here on the work is committed into the system.

Effective difference

Commitment in Kanban controlled flow processes is an attribute of the system, not something that Managers can hold against the team. It is not a promise for some point in the future (the System under development will be able to...) but it is the fact that this item is now in the system and will be worked on according to the explicit policies the team agreed upon.

And that is a promise that –most of the time– can be kept. Together with other attributes of Kanban-Enabled Systems this makes for much more reliable forecasts based on systemic behavior and measured data.

Sunday, September 02, 2018

What is the ideal WIP?

Well - that depends.

Simulations like TeamFlow seem to indicate that a WIP-limit that is slightly below the number of people in the team is ‘optimal.’

On WIP-Limit size

But then again, there are so many constraints possible. If you want to encourage pairing in a software development project (teamsize/2) - 1 might be better. If you want to allow for some slack perhaps (teamsize/2) + 1 might get you there. And of course the handling of commitment points – the points, where work enters the controlled part of the system – also matters a lot. Do you start to limit your work in progress only after the analysis has been done? Or do you start at a the conception of an idea? Do you have different limits for different types of works? And how about policies when you the exceed those limits?

On finding right numbers

For me it is not so easy to answer the question about the right limits. That’s why I find it important not focus exclusively on WIP-Limits when it comes to implementing Kanban, but also to embrace the other principles. Especially “Agree to pursue improvement through evolutionary change” together with the practice to “Improve Collaboratively, Evolve Experimentally.”
This also means, that one should follow the scientific method formulate the hypothesis about the way you want to influence the system (or process), designe an experiment to verify or falsify that assumption, execute the experiment and only thereafter implement the change. Or design a new experiment if the hypothesis was falsified.

till next time
  Michael Mahlberg