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

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

How much ‘empowerment’ is there in Agile?

Does Agile imply that people only do what they like to do?
Does Agile imply that there is no more direction?
Does Agile imply that the team decides what they want to do by consensus?

Well… today Agile means a lot of things to many people.

So yes, perhaps it means some or even all of these things to some people nowadays.

But that’s not what the agile approach was about. Around the turn of the millennium, when the term Agile was coined it was a collection of values and practices some people followed to successfully deliver software where the majority of projects was over-promising and under-delivering.

Previously, I tried to debunk the myth that pull means work on whatever you like, so for today let’s have a look at self-organization once more. Doesn’t “The best architectures, requirements, and designs emerge from self-organizing teams” (the 11th principle of the agile manifesto state that teams should decide what they do, and how they do it, based on consensus? Not really. There is a lot to be said about different approaches for reaching a decision and consensus is but one of them.
The important thing at the time when the agile manifesto was written was that the decisions where no longer made by managers, procurement departments, or architects three degrees distant from the team, but instead by people within the team. But even that doesn’t mean that the team sets its own direction. It used to be quite the other way around. Like when you go on a city tour. The team (tour) members choose wether they want to get on the “romantic old town tour”, the “modern city sites tour”, or the “historic monuments tour” – but once they’re on the bus the self-organization might be about who brews the coffee, who hands the cookies and perhaps even who hands out blankets when it starts getting cold on the upper deck. But not whether you should rebuild the bus to become a biplane or whether it wouldn’t be a better idea to tour the romantic old town if you’re on the “historic monuments tour.”

From my point of view, there is a lot of empowerment in agile. But perhaps not quite as much as some people would like it to be. After all, we’re still making our living because customers buy our product or service – and customers only buy what they need (or think they need).

Or, to put it another way: without direction self-organization leads nowhere.

till next time
  Michael Mahlberg

“How can we balance agility and stability?”

… is a question I have been hearing since 2003, or so. As far as I can remember, I wrote my first piece with an ISBN in 2004 on that subject (“Agil, aber Stabil”, GI Jahresband)

But I don’t really get it.

What is there to balance?

I hear people arguing that agile would be harmful because the interfaces (be it APIs or human-machine-interfaces) could “change any time.” Or that requirements would change so quickly in agile, that it would not be possible to achieve bigger goals.

That’s actually not what was intended originally. The “Systems Metaphor” in XP (one of the first agile Methods) was meant to be extremely stable. And Scrums original 30 day iteration was meant to protect the team from ever changing requirements.

There even was a thing called “release planning” in Scrum – planning concerned with long term goals.

Most agile methods actually promote stability – the agility is about adapting to changing situations and especially adjusting the process.

So there is no need to balance agility and stability. Adopting agile practices –especially when enriched with some Kanban and Lean thinking– actually creates stability.

till next time
  Michael Mahlberg

The Trouble with Jira

The trouble with Jira isn’t (only) the trouble with Jira. It’s rather the way it gets used.

Remember “Context is king” – Jira might well be an excellent bug-tracker. As an Agile and Kanban tool the opinions definitely differ. From my personal experience with many real life implementations I would say that Jira is one of the bigger issues preventing an agile mindset. People from the Lean and Agile communities tend to agree in private conversations (and some even say things along that line of reasoning on twitter).
But as soon as corporate reality strikes, those voices get less loud and the conversation shifts more towards “It can be made to work – millions of users can‘t be that wrong.”

Well, if we have to “make do with what procurement decided to buy”, here are some things I consider to be vital to make it at least not unbearable.

Something like Jira should be a tool. But it should be only one tool. Amongst others. Not the ”one tool to rule them all.”

As long as you have

• enough machines available to permanently display uncomfortable information (and a way to secure them from unwanted access) (Permanent: Without exchanging content every few seconds – yes, that might mean e.g. two different machines, or at least displays, for boards at portfolio level and at team level. In the same room. Gasp!)
• enough rights for the people who actually use the boards to edit boards on the fly (and the same for workflows, if they choose to do so) whenever the teams needs to
• enough knowledge in the teams to be independent from central administration
• the willingness, tools, and knowledge to generate additional information (mostly statistics) outside of Jira

you’ll probably be fine. (-ish)

Otherwise – in my experience – you’ll soon hit a glass ceiling consisting of (amongst other things):

• change cycles (to Jira related things) that take longer than an iteration
• information buried in dashboards that are theoretically available but never looked at
• Reliance on Jira-provided graphs and numbers (not exactly tailored to your needs)
• An unwillingness of people at all levels to gradually modify their processes
• a general agile-tool-fatigue

Oh, and on an –not really- unrelated note: You can copy and modify a lot of things in Jira – even if you don’t have the rights to change the original.

till next time
  Michael Mahlberg

P.S.: Of course one could blame Atlassian – the company behind Jira – for introducing all those access control mechanisms and thus promoting a command and control culture in the first place.
But that really wouldn’t be fair. After all, the core of Jira is a ticketing system. Designed to control people by means of centrally designed workflows.

The whole part that Atlassian sells as “Agile” nowadays used to be a plugin, called “greenhopper.” And if customers demand “Tools to enforce Processes to control the Interactions of Individuals” then why should Atlassian remove those restriction. Oh, wait there was Individuals and interactions over processes and tools, … well… Of course there also is …and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact

What is agile coaching really?

Over the last couple of years, agile coaching has become “a thing” and a term that is used in recruiting, staffing, by managers, trainers, HR, and by many others. And even by many agile coaches themselves.

‘Recently’ (starting about five years ago) a new challenge emerged. From the world of life coaching comes the statement that “You all call yourself coaches, but none of you has a coaching education.”

And there may be a lot of truth in that sentiment.

But if we want to educate agile coaches in coaching, which kind of coaches are we actually referring to?

From memory, the prototype of the agile coach was the sports coach, not the life coach. Why? Well, the first mention of a coach in an agile context I came across is older than Agile. The XP-Coach was mentioned in eXtreme Programming explained (1st ed. in 1999, and the reference to the xp-coach on the original wiki is even older.
Later, long after the agile manifesto was written in 2001, the term “agile coach” appeared with all kinds of connotations.
Looking back at descriptions from the turn of the millennium it seems as if the agile coach in these times was more like a sports coach than a life coach.

Life coaches mostly work within the a set of assumptions that fosters the personal growth and development of the coachee. For some this might be represented in a list like:

• The solution lies within the client
• Coach and client are at an equal level (peers)
• The coach is not the one to find the solution
• The client is the expert for them self
• The coach offers a container without judgement
• Coach and client work with an open outcome

Now if we look at the (rather technical) description of the roles of the XP-Coach that somehow doesn’t fit.

To quote and paraphrase from eXtreme Programming explained:

“… the job duties are as follows:

• Be available as a development [programming] partner […]
• [make refactoring happen]
• Help programmers with individual technical skills, like testing, formatting, and refactoring
• Explain the process to upper-level managers.”

or – on a later page: – “Sometimes, however, you must be direct, direct to the point of rudeness. […] the only cure is plain speaking.” And also “[…]I am always in the position of teaching the skills […] But once the skills are there my job is mostly reminding the team of the way they said they wanted to act in various situations. The role of the coach diminishes as the team matures.”(p 146)

As I learned from Dan Brown (the Kanban Dan Brown, not the fiction author) who also happens to be a children’s rugby coach the education of some sports coaches looks at six different attitudes of coaching:

• tell (intervene and/or give directives e.g. to avoid injury)
• show (let players see the effect of actions)
• teach (educate the players on physical and nonphysical aspects [of the game])
• train (increase the effectiveness or efficiency of an acquired skill or aspect)
• sell (convince the players to ‘buy into’ the application of techniques)
• develop (work on the personal development of the players)

When I look at these lists, the sports coach seems to be much closer to the role of the coach that was outlined by XP.

And what’s more: it seems to be in much closer alignment with both the expectations of most clients as well as the expectations of most teams. For one thing only very few clients want to hire an “agile coach” with a completely open outcome. Due to the nature of agile approaches the specifics are of course not clear at the onset, but the general direction is clearly towards something that is aligned with the agile manifesto and probably includes a number of agile techniques.

So – even though I usually call myself neither an agile nor a Kanban coach, end even though I have clocked up a decent three digit number of education hours in life coaching over the past two decades or so – I mostly find myself in roles more akin to a sports coach than in that of a life coach. And that is true whether I’m working with teams or with upper management.

So perhaps we should keep this in mind if we use the term “coach” in conjunction with agile or Kanban.
What are agile coaches offering these days? Something akin to sports coaching or something akin to life coaching?

And what are customers looking for? What do they need, given where they are right now?

till next time
  Michael Mahlberg

Yesterday’s weather – it’s only an approximation!

Very recently (yesterday to be precise) I published one of my shortest blogposts ever.

What happened? I used an estimation technique from the days of eXtreme Programming called “yesterdays weather.”

The basic idea is that it is rather probable – though not certain – that the future will resemble the past. I started writing regularly for this blog in 2013 and published a post every two weeks except for a time last year when I explicitly decided to let it rest for a while.
So it was a sound expectation that I would continue to publish every two weeks. On Sunday afternoons (European time).
Or so I thought. To add insult to injury I did not only violate agile principles (adjust the plan when the circumstances change), I also violated lean principles.
How so? Well, Of course I don’t write all my pieces on Sunday afternoons, but instead on the days in between Sundays and set the the publishing date to Sunday afternoon. And fiddling with the publishing date in blogger (my blogging platform of choice – for now) is quite tedious. So I decided to increase the batch-size and create some inventory of already scheduled blogposts that I would ’only‘ have fill with the contents from my local drive.

Except that it didn’t work out like that. I did not create the content in time, and all of the sudden the inventory became a liability. Since I didn’t respond to the changed situation and the plan got carried out by bloggers scheduler, this actually went out to the market. Luckily it was only a “lorem ipsum” type of blogpost and not a vital product feature marked “to be defined before production” that went live…

Well, this blogpost from yesterday definitely reminded me, that the lean avoidance of overproduction (one of the seven wastes in Muda#Over-production)) really is a virtue… and that even though past experience is a strong indicator for tomorrows events, we still need to check the current circumstances on a regular basis.

till next time
  Michael Mahlberg

P.S.: To quote George Bernhard Shaw:
“The only man I know who behaves sensibly is my tailor; he takes my measurements anew each time he sees me. The rest go on with their old measurements and expect me to fit them.”

Out of the busy-trap: Don’t call your options backlog

When Scrum was young, one of the objectives was to make sure that the development team was able to work on a fixed set of things for 30 days in a row. (At least that what Ken Schwaber and Mike Beedle wrote in one of the original Scrum Books.) And yes, back then it was 30 days.

A little history

Having 30 days without changing requirements seemed like a very long time for the context in which Scrum –todays most widespread approach to agile– was born. Therefore, a couple of elements were introduced to sustain especially that aspect. The sprint and the notion of the backlog as an artifact are two things that play vital roles in making sure that the objectives for the 30 days really stay fixed.

The sprint has a few attributes that make negotiation between business and development much easier – like a duration, a goal and the whole notion of the fixed subset from the product backlog.

The backlog – especially the product backlog, which used to be quite different from the sprint backlog – contains an ordered list of things that the business (which actually is paying for the music) would like to have. But unless it is in the sprint it is not fixed or committed.

Enter: semantic diffusion

Nowadays many people seem to interpret the backlog as a list of all the things that must be done. And I think must should almost always be questioned. Even the word backlog gives the wrong impression about the requirements – if everything turns out right, the ‘backlog-items’ are not a burden for the dev team but instead they are options to generate value for the whole organization.

The value stream starts way before the sprint-planning(s)

If we look at the whole value chain from idea-conception to delivery, invoicing and payment, it becomes difficult to extend the concept of a sprint to the ever enlarging group of people. Which is fine, because the sprint was never meant for big groups.
Looking at larger groups of people creating value together, it becomes much more feasible to synchronize those groups via independent cadences and optimize the flow through the whole chain. And once we start looking at the artifact formerly known as ‘backlog’ it sometimes shows that, up to a certain point in time, those backlog-items are merely options – so let’s treat them like that (as I wrote a couple of weeks ago.

Naming is essential

And since words have effects, why don’t we start calling these things by their names? “We have to decide which options we select” set a different tone from “let’s look at how much of our backlog we can master.”

Make your life easier – treat options as options and only committed items as ‘backlog.’ And perhaps after a while you might be able to drop the term backlog altogether.

till next time
  Michael Mahlberg

P.S.: I find it very helpful to keep in mind that even though the Scrum terminology is almost ubiquitous today, there are only very few teams or projects really implementing Scrum. Product teams who have to deal with support issues, project teams who don’t have control over the Product, product owners who only have 2 hours per sprint for their team, scrum masters who serve 5 teams at a time – the list goes on and on.
Given these constraints it pays off to review what we want to achieve if we use lean and agile practices and employ those which actually fit the situation.

The official way to define a sprint goal…

… doesn’t exist of course.

But please:

“We’ll do stories 5712, 3211, 7621 and 3123” has never been a sensible commitment. That’s not why we have sprint goals.

The Scrum Guide states “The Sprint Goal gives the Development Team some flexibility […]” and “The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.”

So, if you ask me

“At the end of this iteration department Y will be able to sell product X via channel C” sounds much more like a useful sprint goal. And much more in alignment with the original ideas of Scrum.

IMHO, one of the most important things about the sprint goal is that little word ‘coherence’ – a clear sprint goal helps in setting priorities, aligning team efforts, and communicating with stakeholders.

Therefore, I suggest to use more than a collection of stories to define the sprint goal.

till next time
  Michael Mahlberg

P.S.: Using numbers to drive a business is considered harmful by many people – to quote W. Edwards Deming Quotes

People with targets and jobs dependent upon meeting them will probably meet the targets – even if they have to destroy the enterprise to do it.

Perhaps sprint goals made up of (story) numbers are also a bad idea.

What is a commitment anyway?

Or: The difference between “having committed to something” and “being committed to something.”

This is not about the old story of the chicken and the pig who want to open a restaurant. Even though Ken Schwaber used this adage to illustrate the difference between commitment and involvement in the early days of Scrum, it is no longer part of the canon.

The version history of the scrum guide makes that quite explicit:

“Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.”

Still I see the term “commitment of the team” quite often. In publications and in ‘real life.’

I have to confess, I am even guilty of using it myself from time to time.

Like with many things in the world, the question is how we use them. In this case it is the question of how we use the term – and the concept – commitment?

There is a fine line, but a very important distinction in who does the committing. A while back I heard some General in a movie say that he “committed 20 troops” to some task. In yet another movie a team member explained the success of his team with the fact that “the whole team was committed to the cause.” So does that mean that the 20 people the General committed to the task will feel commitment to the task and thus succeed? Probably not.

And yet the statement “The team is committed to the sprint goal” is syntactically the same wether the team has committed to the sprint goal (e.g. each team member bought into it) or has been committed to the sprint goal (e.g. some higher authority spoke on behalf of the team without their consent).

till next time
  Michael Mahlberg

P.S.: But then again you might want to consider exchanging iteration based approaches with a flow-based concept and cadences and then you might consider “Department Y will be able to sell product X via channel C” as an idea for a MMF (Minimum Marketable Feature(set))