Playing Value Poker in the Dagons’ Den

Agile / / / , , , ,

How often has someone on your team said “We should prioritise by business value” ?

How often have you heard someone say “We should do the biggest bang for the buck” ? – “lets find the quick wins which deliver the most value” or “Lets do the 20% that delivers 80% of the value.” The more studious people may call it “cost-benefit analysis” but it amounts to the same thing.

Yet while teams are quick to assign effort estimates – hours, days, story point or some other unit of measurement – very few teams add a value figure. When you think about it – and you only need a moment here – how can you do cost benefit analysis if you only know the cost? Without a number any attempt to “prioritise using business value” is likely to end up in decibel prioritisation, he who shouts loudest wins.

In fact, it is quite easy to estimate value in the same way we estimate effort. I’ve started including this in my product leader training workshops a few years ago and have seen game-changing results when used with clients. In one case estimating value allowed a client to remove more work in two hours than the team had delivered in two sprints.

I’m running this game in Milton Keynes tomorrow, June 18 – book now and join us for free

Here I’ll describe how to play the game, the next post will describe the benefits and how to exploit values once you have them.

In the past I’ve improvised with value poker cards but the good folk at Agile Stationery have created a dedicated deck with 6 colour coded sets of cards.

I like to set the game up like the TV show Dragon’s Den – Shark’s Tank in the USA and other names in other countries. On TV four or five investor “Dragons” sit on one side of the room while a series of entrepreneurs (usually in pairs) pitch their product for investment. After the pitch the Dragons get to quiz the entrepreneurs and, after a little negotiation, may decide to invest in the product.

In my version the entrepreneurs are played by a pair of product people – these might be Product Managers, Product Owners, Business Analysts or someone else who works on the “what should be build” question. They start by pitching the product, or if the product exists, the goals of the next increment.

On the other side of the room sit my Dragons. These might be senior managers, other product leaders, actual customers or the engineering team who will build the product. Each role brings its own take on what is happening and adds value so don’t feel that you don’t have the right people.

As in the TV show the Dragon’s listen to the pitch and ask questions. Once everyone understands the product – or increment – is going to do the game differs a little from the TV show. Now the product leaders switch to pitching individuals stories – I say stories but these might be epics, features, functions, capabilities, or whatever the unit of work is that your team use. I’ll call them stories for now.

I take one of these stories – one I think is low value, preferably the lowest value. I hold it up and read it to everyone. Next I take a pen and write “10,000bp” on it, I tell everyone that this story is worth 10,000 business points – sometimes I invent a currency on the fly, perhaps the London Dollar or the Swedish Franc. It is important that the currency is not real, if it was people would argue about the valuation but it is the ratio between values on stories that is important not the actual number itself. Finally, I post the card where it can be clearly seen – on a wall, whiteboard or flip chart.

This done I hand each dragon a set of value poker cards. Each set contains about a dozen cards ranging in value from zero to one million.

Switching back to the entrepreneurs, one reads out the story, adds any description they think helps and the dragons reply with questions. When everyone has a good understanding of what the story is I ask the dragons to put a value on it.

As with planning poker dragons are asked to select up one playing card to indicate the value they put on the story but initially keep it secret. I count down, “3, 2, 1 – show ’em” – the dragons reveal their cards.

If there is a wide variation in votes – say three people vote around the 1,000bp mark and one 10,000bp we might have a discussion followed by a revote. More often than not I simply average the scores and write the value on the story card. For example, if four Dragons have voted 500, 1000, 2000 and 10,000 I might write “3,375bp” on the card. I then post the card on the wall relative to the others. So, a 3,375 card would be below a 10,000 card.

Usually I will impose a No Duplicate Values rule so if the next card also comes out at 3,375 I’ll ask the Dragons “Higher or lower?” We’ll adjust the value a little, say up 3,500 and place it higher.

We keep going through all the stories the entrepreneurs wish to value. Usually the second product leader will be selecting the stories they think will get a high value and feed them to the first. Sometimes they will write out new stories to cover ideas which have come up during the game play.

At the most basic levels the values suggest the order of work. Yet actually, as I’ll discuss next time, there are a lot of conversations that can now be had which were not possible before.

One time I did this exercise with a client team. The Product Lead from my team had already divided the stories into Must, Should and Could and the clients were asked to value only the Musts. Still, several stories came out with zero value. The Product Lead might have seen them as must haves but the client didn’t give them any value. Sadly, those stories represented more work than the engineering team had done in total over the last few sprints.

Next time I’ll write more about the benefit of putting value on your stories.

In addition, to Milton Keynes tomorrow I have tentative plans to run this session at events in London and Oxford later in the year, more details to follow.

And finally, if you like the idea go and get yourself some value poker cards – or, invite me to run the game for you, just get in touch.

Playing Value Poker in the Dagons’ Den Read More »

Focus on flow

Agile, Kanban / / /

I have happy memories of the days when was doing my masters degree and I would be among the first into the University library. After my morning swim I’d breakfast at the cafe opposite the library and when it opened I’d be straight in. Up to the top where I would sit for the next 3 or 4 hours completely absorbed in my studies. Reading, writing assignments and later my dissertation. I was working towards something and had complete focus. I would enter the fabled state of flow.

While flow is hard to define its an idea that occurs both personal level – as I just described – and at the organization level. Personal flow is hard enough to come about but organizational flow is an order of magnitude harder. So much more needs to be co-ordinated. You need a flow friendly system, it rarely happens my accident.

Perhaps thats why I’m so excited about both the featureban flow video I published last week and the Featureban Flow Experience workshop I’m running in a few weeks time.

Digital flow

Digital tools make flow both harder to achieve and more important. The constant stream of interrupts, e-mail, WhatsApp, notification, updates and so on, makes flow more elusive. But when machines do most of the “heavy lifting” work what remains requires human thinking. Focus and flow.

If machines companies are to get the most out of their machines the machines too need to enter a state of flow. If they are regularly stalling, maybe because they run out of parts, something fails or another human intervention is needed then they will not deliver their maximum return on investment. We, the humans, need to engine flow for the machines.

That’s why the Featureban game in the video is so important. It helps us understand the process of work, the work flow. Its kind of a throw back to the days of “time and motion men.” But really what we are doing is debugging the work system and keeping it, well, flowing. The game illustrates what happens when things go wrong and how we should respond – which can be counter intuitive.

For example, consider the players in the video: each one an expert agile/kanban coach who understands how problems arise. But it doesn’t require much before these players have created a mess. Its possible the mess would have been even bigger if the players were not such experts!

There is little anyone person can do to fix the problems. (If you want another illustration watch the old HP Stockless Production video also on my channel.)

Also notice that once Mike changes the rules of the system everyone does better. The rule changes, limiting WIP, are counter intuitive to many people but they work. Throughput is increased, output rises, and we can reason about the system.

The is also a socio-technical aspect here – as Russ Lewis points out near the end. In the first round when things aren’t going well a lot of dark humour passes between the players. I’ve worked in many companies like this: things aren’t going well and such humour is the coping mechanism for people who don’t feel in control. Actually, in the video the players are often channeling real-life complaints made by staff and management edicts which make things worse.

A lot of this dark humour replaces serious conversation about how the team could do better. The team feel powerless to change things so they don’t.

In the second round there is less humour but a lot more productive discussion as team members seek to work together to improve flow, increase output and resolve difficulties. Good flow leads to better flow. Humour gives way to satisfaction at a job well done.

3 ways to learn about flow

1. Flow may be hard to define but you know it when you see it. If you haven’t watched it yet what are you waiting for? The Featureban flow experience.

2. Now I’m please to announce that the template we used to play Featureban is now available in KanbanZone and is free to use. I’ll post instructions soon but I think you can probably work it out yourself.

3. Finally, join my online Featureban Flow Experience game on June 24th (code “ABlog20” gets you a healthy discount).

Focus on flow Read More »

In search of flow

Agile / / / , , , ,

Every team is in a search for flow, achieving flow requires and a view of work-in-progress – WIP – and frequently the use of work-in-progress-limit. Identification and removal of blocks and bottlenecks isn’t enough, one needs to engineer them out.

Easier said than done? – I’m glad to unveil a new video to help illustrate these ideas and a short online workshop next month for people to learn by doing.

For both I have to thank Mike Burrows for inventing a game called Featureban. The game broadly models a Kanban system and shows how work becomes marooned and how WIP-limits can help address the problem.

Mike’s original Featureban game is a physical game (download it here), I created an online version which I’ve run a few times with clients. With the help of the good people at KanbanZone, Mike and I recorded a game last month and this is the video which is now free to watch: Featureban Flow Experience.

Book to play Featureban

I’m running the Featureban workshop again in a few weeks, use the code ABlog20 to get a discount on the tickets.

Watching the video after the event reveals lessons which were easy to miss at the time. What I find particularly interesting is that the game is played by four experienced agile coaches but it still very quickly descends into a mess. Even in the second iteration when WIP limits are imposed the coaches find it difficult to work in the best way – even though they all know how to!

This shows how workers are often prisoners to the system they work within. The rules, and expectations create constrains. Changing the rules, actually imposing stricter rules, encourages people to co-ordinate work more closely.

Anyway, watch the video and draw your own lessons. Better still join me in a few weeks time – once you’ve played you will want to play it with your colleagues.

By the way, we are playing using a visual board called KanbanZone – perhaps the only visual tool I actually like! We will soon be making a free Featureban template available on KanbanZone. If you sign up with my link then you will get a free trial and can play the game yourself.

In search of flow Read More »

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 »

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 »

Are Product Owners set up to fail?

Agile, Management, Scrum / /
Product Owner choosing postits

I’ve long seen two big problems with Product Owners.

First, Product Owners don’t talk to customers as often as they should.

Second, the Product Owner role is frequently set up to be little more than a Backlog Administrator.

Now these two problems aren’t completely unrelated. If you are simply a Backlog Administrator what is the point of talking to customers?

For a while now I’ve taken a broad interpretation of the Product Owner role. Yes, it was introduced by Scrum, and Scrum defines a very powerful Product Owner (which I agree with). But, the Product Owner role has become a general term for “the one who should decides what needs doing next.” Simultaneously the role has become undermined and very few Product Owners seem to have the power to decide much more than the next couple of items.

The Product Owner role seems to make Product Managers and Business Analysts nervous. It shouldn’t, both Product Managers and Business Analysts are types of Product Owner. After all, while the Scrum definition calls for a powerful PO it says little about how the Product Owner knows what they need to know to make decisions. In my book – and yes, I cover this in Art of Agile Product Ownership – that knowledge usually comes from being a Product Manager or Business Analyst.

Recently I’ve been taking talking to my subscriber base and the issue of Product Owner comes up again and again. While nobody thinks Product Owners should be Backlog Administrators most Product Owners in the wild are just that, Backlog Administrators.

In some cases people think it is because of their situation. “In the public sector Product Owners are not honoured…”, “In Germany, Product Owners are not valued”, “In the outsourced development market the contract ties the PO’s hands.”

Actually, its everywhere. Product Ownership are failing everywhere.

In many cases I’ve seen Product Owners who are “battlefield promotions”. A coder is picked to be Product Owner on the grounds that Scrum demands a product owner and they are “The best coder” (or perhaps the worst), “they understand the system”, “its a technology project” or some other weak criteria. Real power continues to be vested elsewhere.

In other cases the Product Owner comes from “the business side” and has little understanding of the technology, how technology teams work or what is expected of them. Consequently the technology group run circles round the Product Owner.

There is a reoccurring tendency for Product Owners to become the Product Dogsbody and pick up the things that nobody else wants to do. Other times the Product Owner is seen as the team leader by those outside the team, however they hold little real sway inside the team (because they are a Dogsbody, Backlog Administrator, coder who is acting up or new to technology).

But the thing is: we can’t blame the Product Owner for any of this. They have been set up to fail by people who don’t understand or respect the Product Owner role, real power is withheld from the PO. Possibly because giving the PO power can seem like reducing ones own power.

As a result the role as an operational necessity (because Scrum or SAFe say there should be one) rather than the Strategic Role which is should be.

Perhaps one mistake I’m making here is: using the term Product Owner. Perhaps it is too connected with Scrum, and in the same way that Scrum has been devalued maybe Product Owner has too.

So, how do we fix this?

I’m not sure. Perhaps we should dump the title Product Owner, maybe everyone should use Product Manager – although that title too is misunderstood. Product Leader could be an option but I’ve also heard complains about that. Product Expert? Product Analyst? Product Person? – would any other name help?

In the past I’ve run a Strategic Product Owner workshop which aims to give POs the skills to operate more strategically. But for this to happen someone at a more senior level has to ask for the workshop and ask POs to be more strategic.

One option, is for Product Owners to meet customers. This will both inform their decision making and give them the legitimacy that comes from customer contact.

A brave PO can simply start thinking and acting more strategically, they can put themselves in the driving seat and start making decisions. While I think this would often work it requires a brave person who is willing to risk their job. (And please, meet some customers before you grab the controls!)

Ultimately the good, knowledgable, powerful, product people are key to achieving agility, failure to give such leaders power puts limits on success.

Subscribe to be the first to hear of new posts

Plus download Continuous Digital for free get occasional discounts and gifts

Are Product Owners set up to fail? Read More »

An irrational(?) fear of low-code solutions

Technical / / / , , ,

I see no-code and low-code (or is is locode?) advertised and sold as a good thing. The “replace the programmer” movement has long existed. But it scares the hell out of me – let me tell you why and maybe you can tell me why I’m wrong.

In many ways ERP systems are the original no-code platforms. They are sold as “no coding required, just configuration”. Over the years I’ve worked with many clients who have, or are building, such systems. SAP, Oracle and Dynamics are the best known but there are many of others like Agresso and several descendants of PickOS (e.g. Rocket) which are similar.

Like no-code/low-code, these systems claim configuration is all that you need. While you might be able to programme these systems if you really need too (SAP has the Cobol ABAP language, while Microsoft offer X++ for Dynamics) they aren’t sold or marketed that way. But this is where the problems start.

Configuration is more than just clicking on settings and navigating down to a checkbox. You are instructing a machine how to work and those configurations need testing. While you can safely assume the system knows how to calculate 15% sales tax on a transaction is it applying the rules correctly? What about exemptions? And, in the case of VAT, the location?

As I’ve said before, this creates at least a cultural problem because the people who “configure” these systems (which might mean using ABAP, X++, table configuration, SQL like rules and more) don’t consider themselves programmers. That in turn means they shun things like testing, source code control, versioning and ideas like cohesion, coupling and abstraction.

In fact, some of the systems I’ve just mentioned don’t even support these ideas. When I first encountered SAP I tried to have a conversation with a “consultant” (not a programmer note) and discuss versioning. I failed, the gap between their model of the (SAP) world and mine was so different we were speaking different languages.

I’m told SAP has got better but in some no-code ERP systems there is no concept of exporting configuration. You can create and test your changes on one machine but if you want the same thing on another you have to go and repeat your pointing and clicking. This just seems brain-dead to me.

This might all work in the small but as your solution grows and grows, as you need to make changes in many places, it becomes more complex. And since there is no source to control and no concept of versioning how do you go backwards? What if your configuration is wrong and you need roll-back? Go and reverse your point and click.

This also bodes badly for testing. As the rules and options get more complex you will want to test them to make sure all the changes work together as intended. How do you replicate them to a new system? – if you are lucky they are all in an XML configuration file but now you are back to source code control which is foreign to many non-programmers. Worse still, because these system have few options for “unit testing” (or just small tests), you tend to need to test the whole thing which makes tests more complicated to create, slower to run, and less useful.

Next think about recovery: what if your machine is hacked or just fails? Even if you can move the configuration to another machine how many of your systems are dependent on the name of the original? – after all, machine name is a configuration option, your non-programmers probably haven’t abstracted it and worst of all, you have to manually find and change every example.

Perhaps worst of all, your configuration, your solution, is very very dependent on your platform. In my younger days I ported C++ from Unix to Windows and back. It could be tough but you could do it. Try porting your no-code solution to another platform. No-code means lock-in.

Many of the practices which make programming into software engineering are about creating a road back: version control, source control, build, deploy and, of course, tests. The problem is that when no-code solutions throw away code they may be throwing away all of these things too.

So, am I irrational to worry about no-code and low-code? – if some no-code/low-code advocate would like to explain to me how these problems are addressed I’d love to hear from you.

Subscribe today and get Continuous Digital ebook completely free

Photo by Pankaj Patel on Unsplash

An irrational(?) fear of low-code solutions Read More »

Agility over agile, more than word play

Agile, Business / / /

Is it just me or is the world moving away from agile and towards agility?

That may sound like a silly question. I’m prepared to admit it come as much from what I want to happen as to what is happening. Perhaps it is confirmation bias, but it feels like there is a change in the air. It’s a change I’m all for – I was talking about the need for agility over agile over 10 years ago (Objective Agility).

It might seem like a small semantic change to go from “agile” to “agility” but it is a change from “doing agile” to “having agility.” It is a move from “means” to the “end”. From “the way of doing things” to the “outcome.” Rather than emphasis “the way people work” the emphasis is “what is the end result?”

That is a good thing. By definition agile methods, and agile frameworks (Scrum, SAFe, Kanban, even Xanpan) describe how to work. There is an assumption that if one works that way one will achieve agility. In reality there are many different routes to agility. Some look like Scrum, some like Kanban, others don’t. Some people find their own way to agility.

I always introduce agile by asking: “What do you want agile to do for you?” The agile toolkit can be used for many ends.

With agility the answers are pre-defined: agility is both ability to move fast but also the ability change direction and manoeuvre with haste. In order to do that information is needed (learning), and that information needs to be acted on (decision making) – feedback loops again. Maximising agility means pushing that learning and decision making down to the lowest level: giving the people who do the work authority and trusting them. This is where digital tools come in and is why digital transformation demand agility.

Agile Beyond Software

There are two forces driving this change. First off is the expansion of agile beyond software development and into many other fields. As I’ve said before: digital tools spread the agile virus.

As other fields – marketing, law, research, and more – adopt methods which were originally for software engineering some tools need changing. Sure, some tools work just the same – think daily stand-up meetings. Others need rethinking: test first thinking needs a little work when testing is not the norm. And some don’t work at all: Unit testing.

A couple of years ago I saw Scrum forced on people not in software. These people did not always work in teams, they time sliced between different activities and who had to handle a lot of unplanned, urgent, work. The emphasis was on “doing agile” rather than “being agile”. Despite some valiant work it was a mess.

As we apply agile thinking away from software we need to emphasise the outcome rather than the method.

Business Agility demands more

Second, talking about agility, and in particular business agility, puts the emphasis on the whole – the wider context. That is to say: you can have the most agile team ever but the wider organization can stunt agility. The wider organization also needs to hear customers and adjust efforts: budgets, portfolio, governance and other teams also need to work agile so the whole enterprise can have agility.

Summary

Yes: agility over agile might be semantics but it is an opportunity to change the emphasis:

  1. Prioritise outcomes over methods
  2. Seeking agility outside of technologists means embracing more variation in how teams work
  3. It is not enough for teams to be agile, the wider enterprise needs to challenge how it works

Finally, agility is not binary. One might work agile or might not work agile, but agility is measured on a scale. How much agility does your company have? – it might be zero, it might be 10, it can always go higher.

Agility over agile, more than word play 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 »

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 »