Product Owner

First get small, next get broad

Agile, Strategy / / / , , , , , ,

Small, small, small – I have spent a lot of my career arguing for small: small tasks, small user stories, small teams, small releases, small funding increments, small “projects”. I argue we should get good at small and optimise our systems for doing lots of small. I can justify my arguments – Project Myopia or Diseconomies of Scale. Small makes sense.

But…

While focusing on small is good for delivery it creates other problems. In truth, no solution is ever without consequences and few have no negative consequences, all we can strive for is more positive consequences than negative.

It is not enough to get good at small in delivery, one needs to couple that with an understanding of what is commonly called the bigger picture and which I prefer to think of as the broader picture.

The failure to situate small in the broader context underlies many of the problems we see in the work place today. Take work management, ignoring the broad leads to micro-management, disempowered staff, frustrated employees and collaboration failure.

It is also failure to see the broad that lies behind two of todays most common problems: Product Owner Failure and Run away Backlogs.

Product, sigh

Product Owners – I include Product Managers here – are failing because they are failing to see the broader picture: what is the problem we are trying to solve? how can we bring value to customers?

Product people are too often too focused on features. While I’ve recently seen some point the finger of blame at product owners/managers I think they are only responding to their environment. Companies are operating feature factors and sales are made on features, people think more when they should think better. Product people need to get out and meet customers and bring what they learn back to they can try and change the inside.

The feature, feature, feature attitude is also behind the backlog fetish which leads to backlogs stuffed full of ideas which are never, ever, going to be implements.

The discussion needs to be broadened. We need to get away from quick-wins and features, we need to think more broadly. We need to think about the big things: goals, objectives, purpose and even meaning.

Post pandemic it is common to hear of people seeking meaning in their work, no wonder so many people are dropping out of the workforce when the best they are offered is “more stuff to do.” In looking at broader goals we also need to recognise goals within goals, we need to uncover the hierarchy of (possibly competing) goals, call them out and work with them.

Thats is why I am keen to emphasise outcomes over outputs and its why its tempting to think of a great big funnel containing a machine for breaking the big into small (or Rock Crushing as my old friend Shane Hastie would put it.)

The challenge is to combine the need to focus on the small for delivery while also being able to think broadly. In part it is this challenge that has caused me to focus more on agility over agile.

The Strategic/Tactical Product model but it is not a complete solution.

Iteration, again

Another part of the solution is iteration: we spend a lot of our time in the small focusing on delivery, but from time to time we surface and consider the wider context. Thats why I embrace the OKR cycle, it gives everyone a chance to understand both and take part in both discussions.

Underlying so much of my work over the years has been a desire to remove intermediate pieces: like having a coder speak directly to a user rather than through a BA, its one of my objections to projects (which claim to show the big picture but actually represent a restricted view), its lurking in my dislike of estimates, and its part of my dislike of backlogs.

Asking people to carry the broad picture in their minds while working in the small is asking a lot. Thats why the cycle of thinking broad, setting goals, then switching into narrow mode for delivery works so well. Its fair, it includes everyone and it gives everyone the reason why we do what we do.

In short, we need to think broadly when deciding “what is the right thing to do”, then switch into the small to deliver. Importantly, we need to share not just that thinking but also the discussion. Everyone has a right to be heard.

First get small, next get broad Read More »

10 rules of thumb for User Stories

Hand-on / / / ,

There is a universe somewhere in which my blog is always on topic, I have a theme and I always produce posts which accord with that theme. However, in this universe my mind flits around and, for better or worse, this blog carries what is on my mind at the time. Sometimes that is grand strategy, sometimes hands-on-detail, sometimes the nature of digital work and sometimes frustration.

This week I’m dusting off my slides for next months User Stories workshop so I thought I’d share my User Stories 10 rules of thumb:

1 – Stories are usually written about a hands on user, someone who actually puts their hands on the keyboard

2 – If your story begins “As a user” then save the ink and delete the words, “as a user” adds nothing. “As a customer” isn’t a lot better. In both cases think harder, come up with a better “user”. Be as specific as you can.

3 – Stories which have systems in the user role should be rethought (“As Order Entry System I want the E-Mail System to send e-mail so that I can notify the humans”). Step back and think “Who benefits from System-E and System-F working together?” then rework the story with that person in mind seeing a combined system (e.g. “As a Branch Manager I want e-mail notifications sent when an order is entered.”)

4- Stories should be big enough to deliver business value but small enough to be complete in the near future, I’m prepared to accept a maximum of 2 weeks but others would challenge that and say “2 days is the max.” (Small and valuable actually constitute my 2 Golden Rules, where I also discuss Epics and Tasks.)

5 – There is no universal right size for a story. Teams differ widely in terms of the best (most efficient, most understandable, quickest to deliver, biggest bang for your buck…)

6 – In general the greater the gap (physical distance, cultural norms, history working in the domain, employment status, education level, etc. etc.) between the story writer (e.g. BA) and receiver (e.g. Tester or Coder) the more detail will be expected by one side or the other.

7 – If the User Story format “As a … I want to … So that …” isn’t readable then write something that it. Who, What and Why are really useful to know and he standard format usually works well but if it doesn’t write something that is. There are no prizes for “the perfect story.”

8 – Beware stories about team members: a story which begins “As a Tester I …” or “As a Product Owner …” are red flags and should be questioned. Unless you are actually building something for people like yourselves (e.g. a programming team writing an IDE) then stories should be able end users and customers. Very very occasionally it can make sense to write something for the team themselves (e.g. “As a Tester I want a log of all database action so I can validate changes”) but before you accept them question them.

9 – Stories should be testable: if you can’t see how the story can be tested think again. If you are asked to complete a story which you can’t test then simply mark it as done. If it can’t be tested then nobody can prove you haven’t done it. However, in most cases someone will soon report it as not working and you will know how to test it.

10 – Remember the old adage “Stories are a placeholder for a conversation” ? Well, if you have the conversation all sins are forgiven. No matter what the flaws are if you have the conversation you can address them.

Needless to say more about these topics in Little Book of Requirements and User Stories.

Now just because I go around saying radical things like “Nuke the backlog” does not mean I want to ditch the wonderful who-what-why structure of user stories. You might throw away a lot of user stories but when thinking about the work to be done in the post-nuclear supersprint then by all means: write user stories.

10 rules of thumb for User Stories Read More »

Product Owner car crash story

Agile / / /

A few weeks ago I was in Sweden with clients and heard a horrific Product Owner story today – one I can hardly believe… maybe I shouldn’t, this was told to me second hand but I think it serves as an useful warning.

Reportedly a local car company has told its Product Owners to split their time three ways: 25% of their time is to be spent doing product owner work, the next 25% is to be spent in line management and the rest of the time, half their time is to be spent keeping deep technical knowledge by coding and other hands on activities.

To be clear: this is a bad idea, a bad idea, a bad idea.

Let’s start with 25% product owner work: not only is the Product Owner role the most difficult role to fill it is also the most time constrained role. 100% a product owners time is not enough to fill the role properly.

Next, line management and product ownership should never mix: product owners take their authority from being experts on what is needed rather than a position on an organizational diagram.

Product Owner – even when called Product Managers – are peers of software engineers. They are both professional with specialist skills, they need to respect each other and have constructive discussions even when they don’t agree with one another. The Product Owner is the expert in what customers want, the engineers are experts in solution building, they represent the analysis-synthesis split.

Product Owners need to be able to represent what the customers want to the engineers and engage in meaningful debate between peers. This is not going to be possible is the Product Owner is also the line manager for the engineers with the power to refuse holiday, promotion and mark staff down in reviews if they don’t get their way.

Besides, when do they have the time to do line management?

Then the massive 50% of the time spent coding or other technical work. Again this conflicts with being a true product owner (representing the customer) and holding meaningful discussions with engineers. As they only spent 50% of their time on engineering issues the PO will be the least prepared engineer on the team but the one with most authority. (I’ve written before about the mistake of making a platform engineer the product owner.)

And where is the product owner to get time for all the other miscellany that lands on a Product Owner’s plate? Reporting, statistics, testing, negotiation, etc. etc.

This company has fundamentally misunderstood the Product Owner role. They are seeing the role as an old fashioned Development Manager who was expected to be the technical authority, the team manager/leader and the one to nominate what should be worked on. (Even if they never meet a customer.)

The three things the company is asking the product owner to do are not just three different things, they are three things that should be separated. Line management is an issue agile folk struggle with because in purest terms it shouldn’t exist but in the vast majority of organization that nirvana is so far off it needs. So far at moment we are still in search of a generic model and until we get it we need to keep line management outside the team if possible.

50% hands-on is the give away here, the car company really want a technical authority, call then a senior engineer, a dev lead, or even an architect. This is a legitimate ask and should be recognised as full role. In fact, I would encourage the role holder to put a lot of time into mentoring less experienced engineers. In some engineering fields such senior engineers work as a type of tester to reviewing the work of other staff.

Finally the Product Owner role is a full, legitimate role in its own right. I suspect what is happening at the car company is they have lots of teams working on small technical aspects of the car. They feel only a few people need actual customer knowledge and contact.

It might be that the company could use the strategic product owner/tactical product owner model. Sometimes the TPO role crosses over with the Tester role and it can make sense to have an experienced engineer in the role. Still, you need someone to represent the customer point of view and another person to represent the technical side so the two can have constructive disagreement.

Very occasionally, once in a while I come across a situation where is makes sense to a very technical person drive product ownership from a purely technical point of view. Such occasions are few and far between, but the majority of engineer and managers think their case is one of those exceptions. Maybe this is one such case, but why add-in in line management? and why reduce Product Ownership to a part-time role?

In short: don’t do this.

Subscribe to my blog newsletter and download Continuous Digital for free

Product Owner car crash story Read More »

Videos: ITIL & the Product Owner

Agile / / / , , ,

Last month I appeared in two videos now available on YouTube.

First I was interviewed by Adrian Reed about the Product Manager and Owner roles for The BA Fringe. My interview appears about 12 minutes into the programme and lasts about 10 minutes.

I also joined an expert panel discussing the ITIL 4 High Velocity IT – aligning agile and lean. It was a great conversation and a lot of fun to record, we hardly mentioned ITIL but #NoProjects did get a look in.

I know, ITIL is not something I’m usually associated with but digital and agile means ITIL is changing and I contributed chapters on Product Owner and Continuous Digital (aka #NoProjects) to the recent ITIL High Velocity IT book.

Videos: ITIL & the Product Owner Read More »