agile

Benefits of Value Poker (2 of 2)

Agile / / / , , , , , ,

Last time I described how to estimate value on story cards. Now, lets talk benefits. Ultimately, the real value of this game is the conversations it creates. But along the way there are plenty of other benefits. The licensed dissent the game allows creates many insights and ideas.

The most obvious benefit of Value Poker is simply: at the end of the game you have a value based priority order. A team could, simply, take the highest value story and start work on it, deliver it and move on to the second highest. What could be better?

Buy Value Poker cards

But actually, having value on the cards brings many other benefits and creates many options. For a start, having thought about the value of individual pieces ones perspective on the work to be done changes. What looked like a large chunk of work, a single monolithic product, might look like a stream of valuable features.

Value beats how-long

Moving the conversation away from “how long will it take” to “what value will it create” provides a whole new perspective. One which many have never appreciated before.

Rather than simply start at the highest value and work down conversations about the order of work become more than just technical “A depends on B.” One can think of value dependencies: customers can only get high value A they also have low value D. In which case, is D really a distinct thing, or is it part of A?

Both technical and business dependencies are exposed. All sides get to see why doing the most obvious thing might not be the right thing to do. The team might consider how else they may unlock the high value story without the need for the low value story. Maybe a subset of low-value D should be included in A. And maybe the rest of D isn’t worth doing.

Sometimes these insights only appear because teams are able to be adversarial. In most work environments people show respect. If a Product Leader ask for something few would openly say “That is pointless” or “Why would you do that?” but when playing Dragon’s Den people are allowed to openly question and think-outside-the-box. Indeed, since many have seen the game show people naturally fall into the roles and need little encouragement to challenge ideas. It becomes easy for a lowly engineer to say “I don’t see the market for this” or “Why would I buy this when product XYZ does that?”

Better than Word and PowerPoint

This in turn leads to two more benefits. First the Product Leaders need to be clear about what they want, why they want is and why they see value. They can’t hide behind PowerPoint charts or long business plans, they need to explain their point and defend their position in real-time. Product people are made to up their game.

People sometimes say to me “These two stories can’t be compared, they are like apples and lemons.” But money – even fantasy money – is a great leveller, it measures such asymmetric things. After all, the money you get paid for labouring over a hot keyboard each day can be used to pay your rent, buy a beer or take a holiday. How else could you compare the value of having a roof over your head with drinking beer?

This approach allows everyone involved to have a say. All the brain power in the room, all the knowledge, all the neurodiversity, can be exercised and used. New ideas, start flowing. Dragons and Product Leaders frequently see new or missing features which could be included enhancing innovation benefits.

In one game the Product Leads were proposing an app based around lunch time food trucks. They pitched story after story to the Dragons who gave it low value. The idea didn’t fly. After a quick consultation the entrepreneurs switched from pitching stories with benefit to food truck operators and pitched on Hungry Jo customers. The valuations rocketed. This is where the value was.

With all the discussion, the challenge, the reply, the adjustment something else happens: everyone builds a great shared understanding of what the product is supposed to do, how the entrepreneurs see it being used and who the target audience is. It becomes a great way to understand requirements and specification – far better than reading a dry document or even a PowerPoint presentation. This is why even playing this game with the engineering team can be highly rewarding.

Scheduling to maximise value

Believe it, or not, giving the stories a value can also help with scheduling – even without effort estimates. Once a story has a value one can ask “If this story is work 100,000bp today, what is it worth next month? in six months? in a year?” If the value never changes then the story can safely be postponed indefinitely because the value is always there. If on the other hand the values falls rapidly then the story needs doing soon. Sometimes, there might be more total value from doing a low value story (which will loose value soon) before doing a high value story which will hold its value.

Some readers will notice this is the start of a cost-of-delay conversation. One might now start to talk about Time-Value Profiles. Equally, only when you have value on individual work items can you really start doing cost-benefit, and biggest-bang-for-your-buck, analysis.

Finally, one big benefit I hope you’ve realised along the way: this game is a lot of fun. Not only does it help teams understand but it helps teams bond.

Want to play?

If you would like me to run this game for your company or your user group or meetup please get in touch.

Buy Value Poker cards

Benefits of Value Poker (2 of 2) Read More »

All agile initiatives are flawed (and thats good)

Agile / / / , , , , , ,

If I may paraphrase the late Madeleine Albright: “What really troubles me is that agile is getting a bad name because it is identified with imposition and occupation. I’m for agile, but imposing agile is an oxymoron. People have to choose agile, and it has to come up from below.” (Albright was talking about democracy not agile, if like me you associate agile with democracy the sentiment is no surprise.)

I’ve spent much of the last 20 years helping companies and teams adopt agile. A lot of people are cynical about agile today but I still see benefits. A lot of the cynicism comes because all agile initiatives are flawed – every single one.

Whether you call it agile transformation, agile initiative, agile change or simply agile adoption all are flawed. While I like to claim success for many of the companies I’ve worked with I also see flaws in my successes.

Some agile transformations are flawed in conception. I’ve worked on a couple of these and find them soul destroying. Typically change driven from the top, a big consultancy is probably involved, there may be a roll-out plan and success is measured on some kind of “maturity assessment” – are you doing stand-ups? do you have a product owner? is your backlog burning down?

These kind of agile transformations focus on “doing agile” rather than being agile and achieving agility. I feel sorry for everyone involved but what are senior leaders supposed to do? Imagine you are the CEO of a legacy bank: you know agile is good, you know all the other banks are trying it, and you know digital transformation depends on agile transformation but what can you do? You have little choice but to call in a big consultancy and impose it top-down.

The other kind of flawed agile transformation is, to borrow a phrase from Amy Edmondson, “the right kind of wrong.” These are flawed by success, although it might not feel like that. It is hard to recognise and harder to live through. I’ve seen plenty of these too and, if I think about it, some of these flawed initiatives were my greatest successes.

Be agile to be agile

It is because agile transformations efforts are flawed that we practice agile. Agile is not the end state, it is the way you operate. There is no final, fixed, state.

It was Jutta Eckstein who I first heard describe agile as a problem detector. While some agile tools make things better as soon as applied them other help you see the problems you face. There might be an agile tool to help with the problem or you might need to fix it yourself. This is especially true at the level of the organization, Agile OKRs make this really clear.

Agile transformations which work well are flawed because success breeds success: each success lifts you higher and you can see more problems. A successful team will want to make more change. Remember by maxim: “The only thing you can do wrong in agile it doing it the same as you did 3 months ago.”

Before long successful teams find changes are needed beyond the team. Maybe the marketing department needs to forget about annual big launches, maybe the HR department needs to change bonus systems and so on. The successful agile teams sees the initiative as flawed because they need more.

At the same time, people in those other groups might be seeing the successful agile team and want to copy them. But because they face their own obstacles they can’t.

To those on the periphery of these teams – typically managers – this can look like conflict, tension, complaining, and even agile failure.

Whats happening here is learning: agile is learning. When teams are successful they don’t just learn about sprints and WIP limits, they learn what else needs changing to be more successful.

It is actually good that they see failure because failure is a great motivator for change. When something is a success why change? When something fails then fix it! Inside those problems are opportunities to be even better.

Agile OKRs

Which brings us to OKRs, and specifically Agile OKRs. One of the reasons, despite myself, that I like came to like adding OKRs to agile: because they open up new vistas to see and address problems, and thereby enhance agility.

I have been talking about OKRs as “just in time story generators” for some time, increasingly I see them as change drivers. Adding OKRs to agile doesn’t solve problems overnight, but it does make some problems clearer, like the run away backlog. Working with Agile OKRs means ensuring OKRs are set bottom-up, which demands that leaders are clear about strategy. Too often leaders aren’t clear about strategy – sometimes because they don’t have one. Agile OKRs allow us to address that problem.

The challenge is to keep the faith and keep working to fix your flawed agile transformation. It is in being agile that we become agile. Which is pretty much democracy.

All agile initiatives are flawed (and thats good) Read More »

OKRs like its 2024 not 1974

Agile, OKRs / / / , , ,

Its not 1970 any more, even 1974 was 50 years ago. I used to make this point regularly when discussing the project model and #NoProjects. Now though I want to make the same point about OKRs.

Fashion in the 1970s

The way some people talk about OKRs you might think it was 1974: OKRs are a tool of command and control, they are given to workers by managers, workers have little or no say in what the objectives are, the key results are little more than a to-do list and there is an unwritten assumption that if key results 1, 2 and 3 are done then the objective will be miraculously achieved. In fact, those objectives are themselves often just “things someone thinks should be done” and shouldn’t be questioned.

I’d like to say this view is confined to older OKR books. However, while it is not so common in more recent books many individuals carry these assumptions.

A number of things have changed since OKRs were first created. The digital revolution might be the most obvious but actually digital is only indirectly implicated, digital lies behind two other forces here.

First, we’ve had the agile revolution: not only does agile advocate self-organising teams but workers, especially professional knowledge workers, have come to expect autonomy and authority over the work they do. This is not confined to agile, it is also true of Millennials and Generation-Z workers who recently entered the workforce.

Digital change is at work here: digital tools underpin agile, and Millennials and Gen-Z have grown up with digital tools. Digital tools magnify the power of workers while making it essential the workers have the authority to use the tool effectively and make decisions.

Having managers give OKRs to workers, without letting the workers have a voice in setting the OKRs, runs completely against both agile and generational approaches.

Second, in a world where climate change and war threaten our very existence, in a world where supposedly safe banks like Silicon Valley and Lehman Brothers have failed, where companies like Thames Valley Water have become a byword for greed over society many are demanding more meaning and purpose in their work—especially those Millennials.

Simply “doing stuff” at work is not enough. People want to make a difference. Which is why outcomes matter more than ever. Not every OKR is going to result in reduced CO2 emissions but having outcomes which make the world a better place gives meaning to work. Having outcomes which build towards a clear meaningful purpose has always been important to people but now it is more important than ever.

Add to that the increased volatility, uncertainty and complexity of our world, and the ambiguous nature of many events it is no longer good enough to tell people what to do. Work needs to have meaning both so people can commit to it and also so they can decide what the right thing to do is.

In 2024 the world is digital and the world is VUCA, workers demand respect, meaning and to be treated like partners not gophers.

OKRs are a powerful management tool but they need to be applied like it is 2024 not 1974.

OKRs like its 2024 not 1974 Read More »

User Stories are not Story Points

Agile / / / , ,

Funny how somethings fade from view and then return. Thats how its been with User Stories for me in the last few weeks – hence my User Story Primer online workshop next month.

A few days ago I was talking to someone about the User Story workshop and he said “O, I don’t use Story Points any more.” Which had me saying “Erh, what?”

In my mind User Stories and Story Points are two completely different thing used for completely different purposes. It is not even the difference between apple and oranges, its the difference between apples and pasta.

User Stories are lightweight tool for capture what are generally called requirements. Alternatives to User Stories are Use Cases, Personas Stories and things like the IEEE 1233 standard. (More about Use Cases in the next post.)

Story Points are a unit of measurement for quantifying how much work is required to do something – that something might be a User Story but it could just as easily be a Use Case or a verbal description of a need.

So it would seem, for better or worse User Stories and Story Points have become entangled.

The important thing about Story Points is that they are a unit of measurement. What you call that unit is up to you. I’ve heard those units called Nebulous Units of Time, Effort Points or just Points, Druples, and even Tea Bags. Sometimes they measure the effort for a story, sometimes the effort for a task or even epic, sometimes the effort includes testing and sometimes not. Every team has its own unit, its own currency. Each team measures something slightly different. You can’t compare different teams units, you can only compare the results and see how much the unit buys you with that team.

To my mind User Stories and Story Points are independent of one another and can be used separately. But, it is also true that both have become very associated with Scrum. Neither is officially part of Scrum but it is common to find Scrum teams capture requirements as User Stories and estimate the effort with Story Points. It is also true that Mike Cohn has written books on both and both are contained in SAFe.

Which brings me to my next post, User Stories v. Use Cases.

User Stories workshop – 20% discount for blog readers

(Images from WikiMedia on CCL license, Apple from Aron Ambrosiani and Pasta from Popo le Chien).

User Stories are not Story Points Read More »

Big and small, resolving contradition

Agile, Continuous / / / ,

Have I been confusing you? Have I been contradictory? Remember my blog from two weeks back – Fixing agile failure: collaboration over micro-management? Where I talked about the evils of micro-management and working towards “the bigger thing.” Then, last week, I republished my classic Diseconomies of Scale where I argue for working in the small. Small or big?

Actually, my contradiction goes back further than that. It is actually lurking in Continuous Digital were I also discuss “higher purpose” and also argue for diseconomies of scale a few chapters later. There is a logic here, let me explain.

When it comes to work, work flow, and especially software development there is merit in working in the small and optimising processes to do lots of small: small stories, small tasks, small updates, small releases, and so on. Not only can this be very efficient – because of diseconomies – but it is also a good way to debug a process. In the first instance it is easier to see problems and then it is easier to fix them.

However, if you are on the receiving end of this it can be very dispiriting. It becomes what people call “micro management” and that is what I was railing against two weeks ago. To counter this it is important to include everyone doing the work in deciding what the work is, give everyone a voice and together work to make things better.

Yet, the opposite is also true: for every micro-manager out there taking far too much interest in work there is another manager who is not interested in the work enough to consider priorities, give feedback or help remove obstacles. For these people all those small pieces of work seem like trivia and they wonder why anyone thinks they are worth their time?

When working in the small its too easy to get lost in the small – think of all those backlogs stuffed with hundreds of small stories which nobody seems to be interested in. What is needed is something bigger: a goal, an objective, a mission, a BHAG, MTP… what I like to call a Higher Purpose.

Put the three ideas together now: work in the small, higher purpose and teams.

There is a higher purpose, some kind of goal your team is working towards, perhaps there is more than one goal, they may be nested inside one another. The team move towards that goal in very small steps by operating a machine which is very effective at doing small things: do something, test, confirm, advance and repeat. These two opposites are reconciled by the team in the middle: it is the team which shares the goal, decides what to do next and moves towards it. The team has authority to pursue the goal in the best way they can.

In this model there is even space for managers: helping set the largest goals, working as the unblocker on the team, giving feedback in the team and outside, working to improve the machine’s efficiency, etc. Distributing authority and pushing it down to the lowest level doesn’t remove managers, like so much else it does make problems with it more visible.

Working in the small is only possible if there is some larger, overarching, goal to be worked towards. So although it can seem these ideas are contradictory the two ideas are ultimately one.

Big and small, resolving contradition Read More »

Software has diseconomies of scale – not economies of scale

Agile, Management / / / , ,

“Practical men, who believe themselves to be quite exempt from any intellectual influence, are usually the slaves of some defunct economist.”

John Maynard Keynes

Most of you are not only familiar with the idea of economies of scale but you expect economies of scale even if you don’t know any ecoomics. Much of our market economy operates on the assumption that when you buy/spend more you get more per unit of spending.

At some stage in our education — even if you never studied economics or operational research — you have assimilated the idea that if Henry Ford builds 1,000,000 identical, black, cars and sells 1 million cars, than each car will cost less than if Henry Ford manufactures one car, sells one car, builds another very similar car, sells that car and thus continues. The net result is that Henry Ford produces cars more cheaply and sells more cars more cheaply, so buyers benefit.

(Indeed the idea and history of mass production and economies of scale are intertwined. Today I’m not discussing mass production, I’m talking Economies of Scale.)

Software Milk
Software is cheaper in small cartons, and less risky too

You expect that if you go to your local supermarket to buy milk then buying one large carton of milk — say 4 pints in one go — will be cheaper than buying 4 cartons of milk each holding one pint of milk.

Back in October 2015 I put this theory to a test in my local Sainsbury’s, here is the proof:

Collage of milk prices
Milk is cheaper in larger cartons
  • 1 pint of milk costs 49p (marginal cost of one more pint 49p)
  • 2 pints of milk cost 85p, or 42.5p per pint (marginal cost of one more pint 36p)
  • 4 pints of milk cost £1, or 25p per pint (marginal cost of one more pint 7.5p) (January 2024: the same quantity of milk in the same store now sells for £1.50)

(The UK is a proudly bi-measurement country. Countries like Canada and Switzerland teach their people to speak two languages. In the UK we teach our people to use two systems of measurement!)

So ingrained is this idea that when it supermarkets don’t charge less for buying more complaints are made (see The Guardian.)

Buying milk from Sainsbury’s isn’t just about the milk: Sainsbury’s needs the store, the store needs staffing, it needs products to sell, and they need to get me into the store. All that costs the same for one pint as for four. Thats why the marginal costs fall.

Economies of scale are often cited as the reason for corporate mergers: to extract concessions from suppliers, to manufacture more items for lower overall costs. Purchasing departments expect economies of scale.

But…. and this is a big BUT…. get ready….

Software development does not have economies of scale.

In all sorts of ways software development has diseconomies of scale.

If software was sold by the pint then a four pint carton of software would not just cost four times the price of a one pint carton it would cost far far more.

The diseconomies are all around us:

Small teams frequently outperform large teams, five people working as a tight team will be far more productive per person than a team of 50, or even 15. (The Quattro Pro development team in the early 1990s is probably the best documented example of this.)

The more lines of code a piece of software has the more difficult it is to add an enhancement or fix a bug. Putting is fix into a system with 1 million lines can easily be more than 10 times harder than fixing a system with 100,000 lines.

Projects which set out to be BIG have far higher costs and lower productivity (per unit of deliverable) than small systems. (Capers Jones’ 2008 book contains some tables of productivity per function point which illustrate this. It is worth noting that the biggest systems are usually military and they have an atrocious productivity rate — an F35 or A400 anyone?)

Waiting longer — and probably writing more code — before you ask for feedback or user validation causes more problems than asking for it sooner when the product is smaller.

The examples could go on.

But the other thing is: working in the large increases risk.

Suppose 100ml of milk is off. If the 100ml is in one small carton then you have lost 1 pint of milk. If the 100ml is in a 4 pint carton you have lost 4 pints.

Suppose your developers write one bug a year which will slip through test and crash users’ machines. Suppose you know this, so in an effort to catch the bug you do more testing. In order to keep costs low on testing you need to test more software, so you do a bigger release with more changes — economies of scale thinking. That actually makes the testing harder but…

Suppose you do one release a year. That release blue screens the machine. The user now sees every release you do crashes their machine. 100% of your releases screw up.

If instead you release weekly, one release a year still crashes the machine but the user sees 51 releases a year which don’t. Less than 2% of your releases screw up.

Yes I’m talking about batch size. Software development works best in small batch sizes. (Don Reinertsen has some figures on batch size in The Principles of Product Development Flow which also support the diseconomies of scale argument.)

Ok, there are a few places where software development does exhibit economies of scale but on most occasions diseconomies of scale are the norm.

This happens because each time you add to software work the marginal cost per unit increases:

Add a fourth team member to a team of three and the communication paths increase from 3 to 6.

Add one feature to a release and you have one feature to test, add two features and you have 3 tests to run: two features to test plus the interaction between the two.

In part this is because human minds can only hold so much complexity. As the complexity increases (more changes, more code) our cognitive load increases, we slow down, we make mistakes, we take longer.

(Economies of scope and specialisation are also closely related to economies of scale and again on the whole, software development has diseconomies of scope (be more specific).)

However be careful: once the software is developed then economies of scale are rampant. The world switches. Software which has been built probably exhibits more economies of scale than any other product known to man. (In economic terms the marginal cost of producing the first instance are extremely high but the marginal costs of producing an identical copy (production) is so close to zero as to be zero, Ctrl-C Ctrl-V.)

What does this all mean?

Firstly you need to rewire your brain, almost everyone in the advanced world has been brought up with economies of scale since school. You need to start thinking diseconomies of scale.

Second, whenever faced with a problem where you feel the urge to go bigger run in the opposite direction, go smaller.

Third, take each and every opportunity to go small.

Four, get good at working in the small, optimise your processes, tools, approaches to do lots of small things rather than a few big things.

Fifth, and this is the killer: know that most people don’t get this at all. In fact it’s worse…

In any existing organization, particularly a large corporation, the majority of people who make decisions are out and out economies of scale believers. They expect that going big is cheaper than going small and they force this view on others — especially software technology people. (Hence Large companies trying to be Agile remind me of middle aged men buying sports cars.)

Many of these people got to where they are today because of economies of scale, many of these companies exist because of economies of scale; if they are good at economies of scale they are good at doing what they do.

But in the world of software development this mindset is a recipe for failure and under performance. The conflict between economies of scale thinking and diseconomies of scale working will create tension and conflict.

Originally posted in October 2015 and can also be found in Continuous Digital.

To be the first to know of updates and special offers subscribe — and get Continuous Digital for free.

Software has diseconomies of scale – not economies of scale Read More »

Fixing agile failure: collaboration over micro-management

Agile, Management / / / , ,

I’ve said it before, and I’m sure I’ll say it again: “the agile toolset can be used for good or evil”. Tools such as visual work tracking, work breakdown cards and stand-ups are great for helping teams take more control over their own work (self-organization). But in the hands of someone who doesn’t respect the team, or has micro-management tendencies, those same tools can be weaponised against the team.

Put it this way, what evil pointed-headed boss wouldn’t want the whole team standing up at 9am explaining why they should still be employed?

In fact, I’m starting to suspect that the toolset is being used more often as a team disabler than a team enabler. Why do I suspect this?

Reason 1: the increasing number of voices I hear criticising agile working. Look more closely and you find people don’t like being asked to do micro-tasks, or being asked to detail their work at a really fine-grained level, then having it pinned up on a visual board where their work, or lack of, is public.

Reason 2: someone I know well is pulling their hair out because at their office, far away from software development, one of the managers writes new task cards and inserts them on to the tracking board for others to do, hourly. Those on the receiving end know nothing about these cards until they appear with their name on them.

I think this is another case of “we shape our tools and then our tools shape us.” Many of the electronic work management tools originally built for agile are being marketed and deployed more widely now. The managers buying these tools don’t appreciate the philosophy behind agile and see these tools as simply work assignment and tracking mechanisms. Not only do such people not understand how agile meant these tools to be used they don’t even know the word agile or have a very superficial understanding.

When work happens like this I’m not surprised that workers are upset and demoralised. It isn’t meant to be this way. If I was told this was the way we should work, and then told it was called “agile” I would hate agile too.

So whats missing? How do we fix this?

First, simply looking at small tasks is wrong: there needs to be a sense of the bigger thing. Understand the overall objective and the you might come up with a different set of tasks.

Traditionally in agile we want lots of small work items because a) detailed break down shows we understand what needs to be done, b) creating a breakdown with others harnesses many people’s thinking while building shared understanding, c) we can see work flowing through the system and when it gets stuck collectively help.

So having lots of small work items is a good thing, except, when the bigger thing they are building towards is missing and…

Second, it is essential teams members are involved with creating the work items. Having one superior brain create all the small work items for others to do (and then assign them out) might be efficient in terms of creating all the small work items but it undermines collaboration, it demotivates workers and, worst of all, misses the opportunity to bring many minds to bear on the problem and solution.

The third thing which cuts through both of these is simple collaboration. When workers are given small work items, and not given a say in what those items are, then collaboration is undermined. When all workers are involved in designing the work, and understanding the bigger goals, then everyone is enrolled and collaboration is powerful.

Fixing this is relatively easy but it means making time to do it: get everyone together, talk about the goals for the next period (day, week, sprint, whatever) and collectively decide what needs doing and share these work items. Call it a planning meeting.

The problem is: such a meeting takes time, it might also require you to physically get people together. The payback is that your workers will be more motivated, they will understand the work better and are ready to work, they will be primed to collaborate and ready to help unblock one another. It is another case of a taking time upfront to make later work better.

Fixing agile failure: collaboration over micro-management Read More »

Nuke your backlog?

Agile / / / , ,

When I deliver “Honey, I shrunk the backlog” and when I tell people “Nuke the backlog” there are a few questions and talking points which come up again and again. So, if you read my last post and have been asking yourself how you live with a backlog you want to nuke… read on…

Lead with goals

“My boss won’t stand for me deleting the backlog” I empathise. I know it happens.

At the same time I wonder: does your boss really care? – I’m sure some of them do, I see many Product Owners who are really “Backlog administrators.” Their boss is certainly leaning over their shoulder checking on what being done. If this is your case then your boss is the real Product Owner, sorry to say this but you are really a goffer.

In this case you want to educate your boss, you want to start having discussions about a better way. This is going to be a long and hard path. There is no sure fire advice I could give you here, except to suggest you give me a call.

Assuming your boss give you some leeway then go and start a conversation about your bigger goals. Beyond “delivering backlog items” what are the goals your goals? More specifically, what are driving at for the next 10 weeks?

Start to have a conversation about goals bigger than backlog items. Build a routine, a super cycle, around your sprints with the boss and team to discuss bigger goals. Then, during the cycle drive with the goals. If there is a suitable backlog items that contributes towards the goal(s) then do it. If not, write it out and do it immediately.

Either way, whether you are doing this to work around a boss or as a mechanism to tradition to a backlog-less world the same idea applies: create a super cycle, set goals every 10 weeks (approximately) and then drive through the goals rather than the backlog.

Drive with the goals and put the backlog in the back seat, it is secondary. The aim is to avoid nuking the backlog by letting it fad into irrelevance.

Write an “use by” expiry date on new backlog items.

For any item you do add to the backlog make sure it has an expiry date. That is: a date after which it will be removed from the backlog. Giving every backlog item a life expectancy won’t help you today, but it does mean that in the months ahead some items will “self delete” from the backlog.

After a while you might want to visit older items in the backlog and (if you can’t delete them immediately) assign them “use by” date.

I am sure a few people will say “O this need will live for ever.” In which case you can put a long date on it, say 10 years. But that also tells you: there is no urgency. You can do this item anytime in the next 10 years and add value, it can wait.

Better still, write a “best before” and a “use by” date on the item.

The best before date will tell you the date by which an item should be done to maximise benefit. After that date the benefit will decline, it might still be worth doing but it is not as beneficial. The “use by” date now tells you the date on which it has no benefit.

Now when you are reviewing the backlog you can see which items can be pushed back and which items need doing sooner. This is a little bit of a double edged sword for the requester, if they say “If I don’t have it in 2 months it will start loosing value” then it is more urgent, but also if it doesn’t make the cut soon then it can be removed soon.

Keep an ideas list

When you have a great idea, or when someone suggests something you could do add it to an ideas list – not the backlog. In fact, don’t show the list to people, don’t promise anything to anyone. This is your list for things you don’t trust to your memory.

Some people operate their backlog like this already but many people assume that if an item is in the backlog it will be done one day. Others measure the backlog and forecast dates. But ideas may never be done so they complicate this thinking.

Personally I like to think that great ideas will either get remembered or rediscovered. That said, I also write down lots of ideas. However, I frequently throw my ideas lists away. So if at 11pm I think of something I’ll write it down, three weeks later if it is just moving from one list to another I’ll cross it off. I rewrite my “todo” and “priorities” lists regularly.

If it helps then just keep ideas some other place. One team I worked with created a “Sprint 99” – a sprint so far off in the future it was never going to done. They parked all the good ideas there so they had them for reference and if they needed them but there was no suggestion they would ever be done.

You will also want to think carefully about what you tell people when they say “I’ve got a great idea, can you add it to the backlog?” You want to be honest, but you don’t want to create a long conversation. So you might want to say something like “Great, thanks, I’ll add it to our ideas list, if it becomes a block please come back to me and we can talk some more.” In other words, put the ball back in their court to show the value of the idea.

I’ll admit I’m nervous about this suggestion. Part of me things it will inevitably become to be seen as a backlog. I think important things will get remembered, and things which aren’t important can just as easily get lost when put among 1000 other things. Still, I know some people will take comfort in this idea so give it a try and let me know.

This pieces was first published on Medium, Nuke the backlog.

Nuke your backlog? Read More »

Pull, don’t push: Why you should let your teams set their own OKRs

Agile / / / ,

There is a divide in the way Objectives and Key Results (OKRs) are practiced. A big divide, a divide between the way some of the original authors describe OKRs and the way successful agile teams implement them. If you haven’t spotted it yet it might explain some of your problems, if you have spotted it you might be feeling guilty.

The first school of thought believes OKRs should be set by a central figure. Be it the CEO, division leadership or central planning department, the OKRs are set and then cascaded, waterfall style, out to departments and teams.

Some go as far as to say “the key results of one level are the objectives of the lower levels.” So a team receiving an OKR from on high take peels of the key results, promotes each to Objective status. Next they add some new key results to each objective and hand the newly formed OKR to a subordinate team. The game of pass the parcel stops when OKRs reach the lowest tier and there is no-one to subordinate.

The second school of thought, the one this author aligns with, notes that cascading OKRs in this fashion goes again agile principle: “The best architectures, requirements, and designs
emerge from self-organizing teams.” In fact, this approach might also reduce motivation and entrench the “business v. engineer” divide.

Even more worryingly, cascading OKRs down could reduces business agility, and eschew the ability to use feedback as a source of competitive advantage and feedback.

Cascading OKRs

Cascading OKRs are handed down from above

We can imagine an organization as a network with nodes and connecting edges. In the cascading model information is passed from the edge nodes to the centre. The centre may also be privy to privileged information not known to the edge teams. Once the information has been collected the centre can issue communicate OKRs back out to the nodes.

One of the arguments given for this approach is that central planning allows co-ordination and alignment because the centre is privy to the maximum amount of information.

A company using this model is making a number of implicit assumptions and polices:

  1. Staff at the centre have both the skills to collect and assimilate information.
  2. That information is received, decisions made and plans issued back in a timely fashion. Cost of delay is negligible.

However, in a more volatile environment each of these assumptions falls. Rapidly changing information may only be known to the node simply because the time it takes to codify the information — write it down or give a presentation — may mean the information is out of date before it is communicated. In fact the nodes may not even know they know something that should be communicated. Much knowledge is tacit knowledge and is difficult to capture, codify and communicate. Consequently it is excluded from formal decision making processes.

The loss of local knowledge represents a loss of business agility as it restricts team’s ability to act on changing circumstances. Inevitably there will be delays both gathering information and issuing out OKRs. As an organization scales these delays will only grow as more information must be gathered, interpreted and decisions transmitted out. Connecting the dots becomes more difficult when there are more dots, and exponentially more connection, to connect.

This approach devalues local knowledge, including capacity and ambition. Teams which have no say in their own OKRs lack the ability to say “Too much”, they goals are set based upon what other people think — or want to think — they are capable of.

Similarly, the idea of ambition, present in much OKR thinking, moves from being “I want to strive for something difficult” to “I want you to try doing this difficult thing.” Let me suggest, people are more motivated by difficult goals that they have set themselves more than difficult goals which are given to them.

Finally, the teams receiving the centrally planned OKRs are likely to experience some degree of disempowerment. Rather than being included and trusted in the decision making process team members are reduced to mere executers. Teams members may experience goal displacement and satisficing. Hence, this is unlikely to lead either to high performing teams or consciences, responsible employees.

Any failure in this mode can be attributed to the planners who failed to anticipate the response of employees, customers or competitors. Of course this means that the planners need more information, but then, any self-respecting planner will have factored their own lack of information into the plan.

Distributed OKRs

Distributed OKR setting

In the alternative model, distributed OKRs, teams to set their own OKRs and feed these into any central node and to leaders. This allows teams to factor in local knowledge, explicit and tacit, set OKRs in a timely fashion and determine their own capacity and ambitions.

One example of using local knowledge is how teams managing their own work load, for example balancing business as usual (or DevOps) work with new product development. As technology has become more common fewer teams are able to focus purely on new product development and leave others to maintain existing systems.

Now those who advocate cascading OKRs will say: “How can teams be co-ordinated and aligned if they do not have a common planning node?” But having a common planner is not the only way of achieving alignment.

In this model teams have a duty to co-ordinate with both teams they supply and teams which supply them. For example, a team building a digital dashboard would need to work with teams responsible for incoming data feeds and those administering the display systems. Consequently, teams do no need to information from every node in the organization — as a central planning group would — but rather only those nodes which they expect to interact with.

This responsibility extends further, beyond peer teams. Teams need to ensure that their OKRs align with other stakeholders in the organization, specifically senior managers. In the same way that teams will show draft OKRs to peer teams they should show managers what they plan to work on, and they should be open to feedback. That does not mean a manager can dictate an OKR to a team but it does mean they can ask, “You prioritising the French market in this OKRs, our company strategy is to prioritising Australia. Is there a reason?”

A common planner is but one means of co-ordination, there are other mechanisms. Allowing teams the freedom to set OKRs means trusting them to gather and interpret all relevant information. When teams create OKRs which do not align it is an opportunity not a failure.

When two teams have OKRs which contradict, or when team OKRs do not align with executive expectations there is a conversation to be had. Did one side know something the other did not? Was a communication misinterpreted? Maybe communication failed?

Viewed like this OKRs are a strategy debugger. Alignment is not mandated but rather emerged over time. In effect alignment is achieved through continual improvement.

These factors — local knowledge and decision making, direct interaction with a limited number of other nodes and continual improvement — are the basis for local agility.

Pull don’t push

Those of you versed in the benefits of pull systems over push systems might like toes this argument in pull-push terms. In the top down approach each manager, node, pushes OKRs to the nodes below them. As with push manufacturing the receivers have little say in what comes their way, they do their bit and push to the next in lucky recipient in the chain.

In the distributed models teams pull their OKRs from their stakeholders. Teams ask stakeholders what they want from the team and they agree only enough OKRs to do in the coming cycle.

This may well mean that some stakeholders don’t get what they wanted. Teams only have so much capacity and the more OKRs they accept the fewer they will achieve. Saying No is a strategic necessity, it is also an opportunity to explore different options.

Pull, don’t push: Why you should let your teams set their own OKRs Read More »

It’s the workflow, stupid

Agile / / / , ,

Sausages making illustrates workflow brilliantly! – For years I used this picture of sausages makers to describe the way teams work: meat goes in, sausages come out.

If you put pork in you get pork sausages out

If you put chicken in you get chicken sausages out

If you put beef in you get… in the aftermath of the 2013 horse meat scandal I used to joke “You out horse meat in you get beef sausages out.”

What comes out bears a strong relationship to what goes in.

If you put project A meat in in you get project A sausages out

If you put project B meat in in you get project B sausages out

Sure it works best if you have a dedicated team and you only put project A requests in. When A is finished the team switches and focuses exclusively on project B. But you know what it? It still kind of works if you mix as you go along.

When a team works on multiple different projects in parallel it is not so productive – reduced focus costs, switching between things costs too. It will be a damn site harder to make forecasts about what will be done when, answering the “when will it be done” question will be tougher. But it still works, you can still make forecasts just they will be even less reliable.

By extension, if you put business as usual meat in you get business as usual sausages out. If you put DevOps meat in you get DevOps sausages out. If you put company admin in you get company admin sausages out. Get the picture?

While it is great advice to “focus on just the project/product” the vast majority of teams I’ve ever worked with are not in a position to do that. Turning work down is above their pay grade.

Seeing the whole

In Xanpan I called this “Team centric”. The project you are doing is less relevant than the workflow you are operating. Xanpan explicitly discusses how to integrate “urgent but unplanned work” with planned “project” work, I’ve extended the thinking with OKR Zero.

When things go wrong teams become like a saturated sponge. People can’t see the correlation between what goes in and what comes out. Trust is reduced, more reporting and even policing is added. The workflow becomes more complicated, less predictable and more costly.

It is no use looking at the project. Each project is only part of the picture. Neither will looking at the BAU, DevOps or urgent but unplanned work help either. They are only pieces.

You need to look at the whole: the workflow, the sausage machine that makes the sausages.

It is of little use looking at the pork sausage project and asking how many pork sausages will come out next week if the team is also doing BAU and making some chicken sausages on the side.

Nor is it any use talking about the pork sausage project if every time the team turn the handle they have to stop. Check with accounts, check with the security team and check customers – all of whom have their own workflow. Customers who just want the team to “get on and deliver it.” Every time a team needs to interact, get permission, get feedback or anything else with another team, things slow down and grind to a halt. Other teams are most likely struggling with similar things so they all block one another.

Often when this happens, because people have the best intentions, and because they want to be productive, they start doing something else. Pork sausage production stops while they wait feedback on sausage sales. So they start producing chicken sausages. Then just as chicken sausages start coming out the pork feedback comes in and everything must switch back. But now the chicken meat is unwrapped and getting warm. By the time they get back chicken sausages it has gone off.

It’s the workflow, stupid. Let me suggest again: watch Stockless Production.

No one person

Everyone, and every team, is linked together in workflow so it is difficult for one alone to make a difference. Working harder, producing more often makes things worse not better. Individually people are pretty helpless.

Such workflow streams are full of work-in-progress, WIP, they are overloaded. This is really “work hopefully in progress” (WHIP). It is bad when one team is overloaded but when it is excess strategic wip the whole organization struggles. It is difficult to know where to begin fixing thing. You still have to start fixing it at the team level but until multiple teams start fixing there is not much improvement to show.

No one person can fix this. No single technology can change it. Maybe not even a single team. Everyone is connected. Only by looking at the whole can things be fixed.

Unfortunately this is where project warriors come along. They insist that everything is a project – which increases administration. One or two projects get expedited and are forced through but everything else deteriorates.

Saddest there are know solutions: work to completion, reduce workpiece size, operate a pull system not a push, work within capacity, allow for shit to happen (unplanned but urgent work) and don’t overload the team – in fact don’t load them more the 76%.

That is workflow management. The devil is in the detail, there are no big easy solutions – if there were they would have been applied already. Workflow management cuts across projects. Managers have a role to play here but not project managers. Project management is too narrow.

It’s the the workflow, stupid.

So finally, an advert: I’d love to help, call me, e-mail me, LinkedIn, WhatsApp, whatever medium you like, just ask.

It’s the workflow, stupid Read More »