Allan Kelly's Blog, page 12

Online: Honey, I shrunk the backlog

Last week I delivered a new presentation “Honey I shrunk the backlog” to Berlin Product People. The presentation is now online and can be downloaded from my presentations page.

The presentation builds on the ideas floated in my resent “Backlogs, #NoBacklog(s) and comfort blankets” post and which are finding their way into a lot of my writing.

Subscribe to my blog newsletter and get Continuous Digital for free

The post Online: Honey, I shrunk the backlog appeared first on Allan Kelly.

Backlog questions and answers

My previous post on backlogs (Backlogs, #NoBacklog(s) and comfort blankets) generated a lot of attention, including a comment from Derek Jones – his is one of the blogs I read most often. I thought I’d post my reply as a fill post so here goes:

DJ: “Why is a backlog bad? Isn’t it better to have some idea of what work needs to be done, and at least it shows that work is waiting to be done.”

As I understand it Mary’s comment that backlogs are a problem is based on inventory thinking in Lean. I think she was speaking in generic terms and saying “Lean thinkers see backlogs as a problem so maybe having a backlog is not a good thing.”

In a software process backlog work requests are akin to supplies delivered and held in stock waiting for production. Although they don’t take up physical space (and therefore cost) software requests do increase the cognitive load because they take mental space – if only to worry about them.

Part of the logic of Lean’s Just-in-Time approach is to “lower the water level” and make problems more visible. The same is true with a software request backlog: all those backlog items hide problems, sometimes the items may contradict and sometimes, like I suggest in my post, they distract from the overall goal.

As for knowing the work that is coming I’m not sure that is a good thing: again this will increase cognitive load, and when the backlog is run away the content of the backlog is not a reliable indicator of what might happen in future. I’d also add that I’m not convinced software engineers do a better job by deliberately designing for the future, in may experience an awful lot of code which is built “for future change” end up being bloated by unused options for a future that never happened and which hinder the future that does happen.

Future plans can also distract from what is valuable and needed now. The more developed a plan for the future it is the harder it is to walk away from the plan when needs change. That is not an argument for no planning or no plans, it is simply to say that one has to balance both sides.

DJ: “Now, if the backlog just grows and grows, and random items are selected for implementation. That’s not good, but the problem is with how the backlog is being managed.”

Let me turn this around: I am not saying backlogs that are under control are a problem. If a team has a “tame backlog” which is not too large and only growing at a pace noticeably lower than “velocity” then everything is good. But, such backlogs seem to be few-and-far-between.

My conjecture is: many organizations have “run away” backlogs and in such environments a better solution would be to move to a just-in-time backlog generator and sideline the backlog. One could step further and say: even when the backlog is tame it can be better to use a just-in-time backlog generator rather than a (semi-static) backlog.

DJ: “How do we know whether items in the backlog are being consistently prioritised or selected at random?”

We don’t. In my experience large backlogs are seldom prioritised with anything more granular than Moscow rules (Must have, Should have, Could have, Would like to have – rather than the rules of spy tradecraft) – in which case 60% is rated high or Must. Within those priority #1s there may be second priority set at a more granular level. When this happens the majority of the “musts” will be rated low, in effect they are “nice to haves”. Of the few genuine high-priorities the actual priority is not stable. “decibel” management means that they are regularly leap-frogging one another to be Number 1.

DJ: “The waiting time is the key. An exponential waiting time suggests randomness, or FIFO, a power law with exponent -1 suggests item selection based on consistent priorities. For details, see https://shape-of-code.com/2022/08/28/task-backlog-waiting-times-are-power-laws/“

Agreed, I would suggest the behaviours with create that distribution also undermine the reactivity (i.e. agility) of the organization. If a team really was reactive then we would expect uniform, short, lead time. Conversely, if a team really was adhering to a rational plan, roadmap, requirements document, then the lead time would be longer but would also be uniform because at some point X the stories had been captured, the work had been prioritised and was being delivered in regular fashion.

Which begs the question: is a power law distribution of work-to-do a natural phenomenon which will always reassert itself or an indicator of dysfunction?

A team following my Story Generator (aka Just-in-time Backlog) model would see average delivery times of less than half the super sprint duration because any undelivered items would be deleted at the end of the super sprint.

Subscribe to my blog newsletter and get Continuous Digital for free

The post Backlog questions and answers appeared first on Allan Kelly.

Kazuo Inamori, inventor of Amoeba Management, has passed away

It was with sadness that I read this morning of the death of Kazuo Inamori . His is not a name that is widely known in communities I move in (namely the western agile community) but he deserves to be better know, his name deserves to be up there with Shigeo Shingo and other founders of the Toyota Production system. In Kyocera, Inamori founded a company as worth studying as Toyota.

I have to confess that although I read his Amoeba Management eight years ago, and although his ideas have a great influence on my own work – as anyone who has read Continuous Digital in particular will know, I had not made time to learn about Inamori himself.

Amoeba Management is such a good fit with agile I am constantly surprised it is not better know. As you might guess from the name companies are split into multiple Amoeba, self-contained business units with their own profit and loss account. Such Amoeba could be as small as a team and fit right in with the idea of devolved authority and engagement.

This morning’s obituary in the FT (paywall) goes some way to correcting that: he was a giant of management in Japan. In addition to Kyocera he founded KDDI and was instrumental in resurrecting Japan Airlines after bankruptcy.

Nor did I know that as well as Amoeba Management he wrote many other books although only a few of them have been translated to english. I intend to correct that omission immediately and read more of his work.

The post Kazuo Inamori, inventor of Amoeba Management, has passed away appeared first on Allan Kelly.

Backlogs, #NoBacklog(s) and comfort blankets

At the first Agile on the Beach in 2011, I had dinner with Mary and Tom Poppendieck. As we talked about the conference, agile, lean and everything else I distinctly remember Mary saying “From a lean point of view backlogs are a problem. In a lean environment when you have a backlog you want to eliminate it.”

Just then, I was then working with a client with a runaway backlog. I had calculated the backlog growth and found it was regularly greater than the work done “velocity.” It was like a mortgage were the monthly payments didn’t even cover the interest. If I remember correctly, backlog growth, interest, averaged 8.5% per month. I suggested to the client and their supplier that they throw the backlog away. They, not for the first time, thought I was mad. Since then I’ve voiced the same opinion with other clients and got the same response. But the opinion is gaining ground and I’ve even encountered a couple of places were they have moved away from the backlog.

To be fair, backlogs are useful – they can have a useful role to play but that role is akin to a child’s comfort blanket. There comes a time to say goodbye to childish things.

(By the way, I’m really discussing what Scrum calls “the product backlog” rather than the ever changing “sprint backlog.” So I mean: the stuff we might work on in future and not: the stuff we are working on this week, and next.)

I’m not, yet, ready to join Vasco Duarte in declaring #NoBacklogs but my “nuke the backlog” comment in a podcast with Jenny Herald said pretty much the same thing. That comment has attracted a lot of attention and seeded good discussions. I like those discussions and thats why I resist about #NoBacklog. When we started using #NoProjects it was good for conversation, but then a few people drowned out the discussions with calls of “You are mad”, they never considered our arguments and closed down discussion for others.

So what is the backlog problem?

First, as the graph above shows: backlogs don’t “burn down” they tend to grow, and often grow faster than work is done. That becomes a problem because many people expect the backlog to reduce to zero over time and organizations consider success (“Mission accomplished”) to be a completed backlog. The cost of adding something to the backlog is near zero, but the cost, to the product owner and/or team, if refusing a backlog item can be high – all the time spent explaining why something won’t be included.

The desire to “do the backlog” leads to the second problem: an emphasis on doing backlog over delivering value. It becomes more important to do backlog items (output quantity) then deliver benefits (outcomes.)

That, combined with the ever increasing number of items, leads to problem three: a loss of strategy and sense of purpose. This is classic “can’t see the wood for the trees.” There are simply so many backlog items to do it is hard to see what should be done. (The whole “twice the work in half the time” idea that surrounds Scrum makes this worse still. Raising the outcome over output question will also get you called mad.)

Along the way a lot of stakeholder problems get created because people believe that an item in the backlog is in some way promised when it isn’t. Product Owners and Teams accept items into the backlog for an easy life even when they know it is unlikely to ever get done. This stores up future problems because stakeholders start complaining when they fail to get their items. That damages trust in the team and a vicious circle ensues.

It gets more and more difficult to prioritise anything: more items to consider, more stakeholders to placate, more promises to (pretend to) keep. This makes it increasingly difficult to follow the benefit and change course and act on product feedback.

One of the reasons I came to like OKRs, despite my initial scepticism, was that they provided a means to think about the backlog and eventually move away from it. Another reason why I am avoiding #NoBacklog is because I want to be able to offer an alternative rather than just rubbish the backlog. At the moment I think OKRs are that alternative but I’m a little bit reluctant to force OKR Kool-Aid on people.

I tell a story in Succeeding with OKRs in Agile about a little experiment I conducted with another agile coach. The question was “Are OKRs written based on the backlog you intend to do in the next quarter? Or, are OKRs set in respect of business strategy and product priorities and backlog items selected, or even created, to meet the OKR?”. The experiment showed us that OKRs should come first and the backlog was secondary.

Perhaps backlogs are, as I think Vasco thinks, a hang over from the project days. A similar point is hiding inside Project Myopia: in the project model success is doing all the backlog, but if you prioritise by business value, if you are responsive to customers, if you are practicing dual-track agile and product discovery then you may well find that not everything in the backlog is valuable or even wanted by customers.

Increasingly I view Product Backlogs as comfort blankets – what psychologists call transitional objects. Like children’s toys they help us move from one view of the world to another. When starting with an agile style of working backlogs provide comfort by mapping work to the traditional (project) model, but in time, as you become better at listening to customers and responding they are a hinderance.

I’ll be talking more about backlogs and comfort blankets in an online presentation next week to Berlin Product People, join me there to hear more. (5 September 2022).

Subscribe to my blog newsletter and get Continuous Digital for free

The post Backlogs, #NoBacklog(s) and comfort blankets appeared first on Allan Kelly.

The OKR cycle goes wide-narrow-wide

Since writing Succeeding with OKRs in Agile I’ve had the chance to work with a few companies on OKRs and deliver a some training. Structure my thoughts to explain to ideas and concepts to other people is a great way of increasing your own understanding. So much so that I’m contemplating a second edition of Succeeding with OKRs – I’ll decide once I get Books to be Written out of the way.

The OKR cycle

Hence, I increasingly find myself talking about the OKR cycle – I mention the term in Succeeding but have come to realise how important it is. The “OKR cycle” is depicted in the diagram about, it is setting the team OKRs, executing against the OKRs, then as the end of the period is in sight thinking about what comes next. As the cycle ends there you need to close out the OKRs, review what you did, retrospect (what can we do better next time?) and go firm on the OKRs for the next quarter.

Typically the OKR cycle is 13 weeks long which immediate begs the question of how it fits with 2-week sprints? I was already moving towards saying “aim for 12 or 14 weeks” but after listening to a number of podcasts and talking to others I increasingly think 13 weeks is not the best period.

I can see a good case for running 4 month, 16 week, OKR cycles. This would decouple the OKR process from all those other quarterly processes businesses have: financial reporting, sales quarters, performance reviews and so on.

I can also see a case in going in the other direction: a 10 week cycle would also decouple OKRs from the same things. But there is a catch here: OKRs fill the mid-range planning horizon and help glue strategy to implementation. If we shrink the cycle too far it will become a long-sprint. Hence I tend towards lengthening the cycle but until I get a chance to try it I’m not coming down firmly one way or the other.

The other reason to shrink the cycle is to learn faster: particularly when starting OKRs. Just like running one week sprints when a team is new to agile. When a team is new to OKRs I now recommend running two back-to-back 6 or 8 week cycles. This would give the team twice the experience of setting OKRs, using OKRs to drive iteration planning, closing out OKRs at the end and repeating. After the second cycle I would drop back to 12 (or 16) weeks.

Which brings me to the second point on OKRs – something else I hint at in Succeeding but now go further. When working with OKRs you want to follow and Wide-Narrow-Wide model.

Wide-Narrow-WIde for setting, executing and evaluating

Stage 1 goes wide when setting OKRs: during this phase you want to go wide and think broadly. Consider what you might do, what is valuable, how what you are proposing will deliver (or protect) value. Ask difficult questions, throw stones at ideas and see if they hold up. Everyone should have a say because everyone needs to feel enrolled in the objectives.

Stage 2 goes narrow: your sole focus is on delivering the OKRs, you should aim to push everything else aside. OK, caveat #1 if your house catches fire unexpectedly PUT OUT THE FIRE even if you loose you OKRs – don’t be stupid but neither should you rush to extinguish every flame prematurely. And caveat #2: if fighting fires, aka dealing with live issues (think SecDevOps) is part of your responsibilities then make sure your OKRs reflect that is part of your work – maybe use OKR #0 as I discuss in the book.

Stage 2 is the longest stage, most of the typical 13 weeks, so my egg-timer model image isn’t completely accurate but you get the idea.

Finally, in stage 3 you go wide to evaluate what happened. This is where you ask not just “Did we meet or miss the OKRs?” but more importantly: “did we do good? did our work benefit people? add value? did we further our mission and the purpose of the organization?”

Ultimately I don’t care if you miss every OKR if you can answer “yes, we added value, we furthered our mission.” OKRs are, after all, a hypothesis of what will create benefit in the next few weeks.

And no sooner are you finished thinking broad in stage 3 then you are back to the wide thinking of stage 1 and you repeat.

Subscribe to my blog newsletter and download Continuous Digital for free

The post The OKR cycle goes wide-narrow-wide appeared first on Allan Kelly.

Books to be Written new cover

Books to be written has a new, professional, cover. What do you think?

I published an updated version earlier this week with more about working with publishers.

There are some loose ends to tie up in the content now then I’m into a big end-to-end edit, the hard bit. After that I move from writing to production with copy editting. The new cover is the first step along that path.

If you buy the unfinished version on LeanPub now you will receive free updates as they are released and the final, finished, book later this year.

By the way, in keeping with the book being increasingly “done” the price has gone up $1 and it will increase again before I’m done so you can save a little money by buying early.

The post Books to be Written new cover appeared first on Allan Kelly.

Product Owner car crash story

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

The post Product Owner car crash story appeared first on Allan Kelly.

Books to be written

I’m entering the final stretch of writing for my new book so it is time to think hard about the name.

“How I write books” was only ever a working title, now I think I’ve hit on the permanent name “Books to be written“. What do you think?

Let me know – you can check out the (nearly finished) book on LeanPub right now. Almost all the chapters are now drafted.

The post Books to be written appeared first on Allan Kelly.

OKRs in 26 Minutes (video)

I was recently asked to do a short introduction to OKRs for the Digital Leaders conference. The recording is now online and focuses on the benefits of OKRs. Naturally, I put the emphasis in different places to others!

Let me now that you think: OKRs in 26 Minutes.

The post OKRs in 26 Minutes (video) appeared first on Allan Kelly.

How fresh is your backlog?

Do you struggle with an overwhelming backlog?

Do you count the number of product backlog items in your backlog in tens? hundred? or thousands?

Does your backlog contain many stories which have been there for months, if not years, and yet never raise to the top of the backlog?

Is your success judged on your ability to do the backlog?

Backlogs were a good idea when they were introduced a bit over 20 years ago but today many teams slaves to the backlog – see my posts on the Tyranny of the backlog and Purpose over backlog. One of the benefits I’ve called out for OKRs is the ability to move away from backlog driven development (BLDD).

In Succeeding with OKRs in Agile I ask suggest you either need to prioritise your backlog over OKRs (in which case OKRs are derived from the backlog you intend to do) or OKRs over backlog (in which case OKRs are derived from strategy and the backlog plays a supporting role.) In my podcast with Jenny Herald earlier this year I even say “Let OKRs drive… nuke the backlog.”

Filipe Albero Pomar recently shared his backlog freshness blog which I think is great. Freshness is a great way to think about the state of the backlog that separates the size of the backlog from the relevance of the backlog.

Filipe’s idea is simply to talk about the backlog in terms of freshness – you have a fresh backlog if your backlog items are fresh: written recently, relate to current opportunities, problems and things people currently want.

And of course, the opposite of fresh: stale, stories that have been sitting in the backlog for months, even years, stories that relate to yesterday’s problems and project, stories which people wanted last year. The existence a big backlog of stale stories means the team is seen to be not delivering, the end-date is far off because people still expect all the work to be done.

Filipe suggests backlog freshness can be measured:

1. Set a cut-off date

2. Categorise stories as fresh or stale: fresh stories have been written since the cut-off date, those which are older are stale

3. Calculate freshness as a percentage of fresh from the total: if 25 stories out of 60 have been written in the last month then the backlog is 41% fresh, and 59% stale

Thats a useful metric, I think we can do better, look at the graphic above. I group backlog items into age groups and graphed them. For completeness I added a line to indicate average story age. Clearly this backlog is not fresh – nearly half the stories are over a year old.

I like the idea of graphing backlog freshness because it is easy to understand and makes an impact. In the graph above I’ve categorised backlog items into age groups and added an average line. Clearly this is not a fresh backlog. Whether this is the way to demonstrate backlog freshness I’m not sure – I’m playing with a histogram and quartile ranges.

With some clients I’ve thought of the backlog like a mortgage. There is the principle (the existing backlog), the interest rate (the growth rate of the backlog) and the monthly repayments (stories reaching done). Unfortunately when you do this you sometimes find the mortgage will not be paid for many years, and perhaps never. (Don’t worry about estimating the size of stories, for this sort of analysis the number of stories will get you started, and if your backlog is measured in hundreds of items the small will offset the large.)

I’d love to talk more about this and experiment with some ideas, I think it could be a very useful way of thinking about the backlog.

Subscribe to my blog newsletter and get Continuous Digital for free

The post How fresh is your backlog? appeared first on Allan Kelly.