Agile

Employees: growth driver or cost to trim?

Walmart doesn’t operate here in the UK, I was never impressed by the store when I lived in the US and rarely shopped there. My mental image is “pile it high, sell it cheap” – which was actually Tesco. Evil empire exploiting workers and customers alike. But, it seems I’m wrong. My image might have been correct once upon a time but Walmart now follows something called the Good Jobs Strategy: they invest in their workers, train them, pay good wages, give them more meaningful work and reap benefits which more than pay for the extra costs. Rather than being a cost employees drive growth.

The dominant operating model of many companies may well be pay-as-little-as-possible, avoid training and any other non-essential costs, accept high staff turn over and have supervisors police and micro-manage employees. Yet there is another model which seems workers as a growth driver and it delivers higher returns.

While there are examples from health care, manufacturing and elsewhere it probably easiest to see the Good Jobs Strategy in retail companies: Trader Joe’s and Costco in the US, Zara and Mercadona in Spain, and here in the UK Richer Sounds.

I’ve been hearing about Good Jobs Strategy for a few years now and finally read Zeynap Ton’s The Case for Good Jobs a few months ago. Yet I’ve hesitated to write about it because Ton’s case is rooted in the “low-paid” occupations like retail. I generally work with high-paid knowledge workers – engineers, sometimes accountants or marketeers, and so on.

Yet the logic applies whatever the wage level. When salary costs are higher the cost of recruiting and onboarding is going to be higher too. The same arguments I’ve been making under the banner of “agile” apply to good jobs strategy: listen to employees, expect them to do quality work, trust then and enrol them in process improvement.

Today’s standard business strategy is often to keep staff costs low: pay as little as possible, avoid costs like training and if possible keep staff on “zero hours” contracts so there is no need to pay them if they are not needed. But, if you apply a little systems thinking here and look at what happens you realise this model is failing employees and employers alike.

Because wages are low employees are always on the look out for (slightly) higher paying jobs. So staff are prone to move often. Which means that employers are constantly spending to recruit and onboard new staff. That also means that staff don’t know much about the product offering, say, where to find things in the shop; which in turn means customers service is poor and customer loyalty is low, opportunities to up-sell and cross-sell are lost. Staff are costs to be limited.

Working for such an employer is not a lot of fun. Staff might need to hold two jobs to pay the bills. So why should the staff commit? Why should do anything more than they need to? – especially when the employer doesn’t go anything more then the essentials. Why should they smile? And why would they stay when someone else offers 10¢ and hour more?

McGregor’s Theory-X “Works are lazy” becomes a self-fulfilling prophecy.

Now flip it around: Good Jobs Strategy is Theory-Y thinking, staff are growth drivers.

Such companies invest in their staff, pay decent wages, train them, trust them and allow discretion in work. Now staff stay, so hiring and onboarding costs are reduced. They understand how the business operates and what the product line up is so customer service improves, customer loyalty increases, up-selling and cross-selling increase and the world is a happier place.

Many will say I’m dreaming, that is not how the world operates. Maybe, but Zeynep Ton has collected the evidence and shows that it does payback. Walmart is the evidence, it used to follow the standard strategy but for over 10 years has followed good-jobs and the results show.

I suspect at some level everyone, CEOs included, innately understands this. Thus the question is: why do companies undermine themselves by not treating workers well?

Unfortunately, the answer is that bad jobs are so normal that anyone (CEO included) who suggests something different undermine their own positions. CEO feels compelled to keep costs low because it is the standard model and everyone – shareholders included – expect it. And if the CEO feels the pressure all the other managers will too.

Now, why am I writing about retail jobs in a blog more concerned with high paying occupations? It is because I see the same thing. Recently I came across a company that moved technology engineering to high-cost Finland because it saw the engineering standards would pay back. Paying high wages for quality work was cheaper than paying low wages for rubbish.

Forget low wages. The people I work with – the likes of product managers, software engineers, even managers – all get paid far more than minimum wage but they still suffer from a lack of training, lack of trust, lack of discretion and excessive tasking (micromanagement). High staff turn over and lack of business knowledge are the result.

Secondly, the more I work with OKRs the more I see that company purpose is really important. Anyone who has joined my OKR training workshops, or seen recent presentations, will have seen my “Eggs”. Near term goals (the objectives for this quarter) need to support longer term goals (the product goal or annual OKR). That goal needs to support the greater mission goal, and the mission goal needs to support the company purpose.

Goals nest inside goals. Several levels, but ultimately you need an outermost goal. That needs to be purpose. Without purpose there is nothing to align goals, and weak purpose (“make more money”, “do more stories”) isn’t very useful, meaningful or motivating.

Good jobs strategy ties together other ideas. In a bad jobs environment there can be no psychological safety, which in turn means no organisational learning, so process improvement (agile) is shot though, there is no improvement process, effectiveness and productivity are hobbled. You need a good jobs strategy to make it all work.

OKR adoption is one place to start breaking this cycle but there are others. Start by surfacing issues and improving jobs. If this makes sense and you’d like to move in this direction please get in touch or book a call to chat and lets see what can be done.

Employees: growth driver or cost to trim? Read More »

6 ideas to boost productivity

I keep hearing about the need to raise productivity on the radio – well, here in the UK we have a new government and raising productivity is one of their big themes. So I sat down with my pencil and paper and put a few ideas together which I thought I’d share.

It is actually quite difficult to pull out a stand alone “do this and you will be more productive” type thing. As many have said before: there are no Silver Bullets – or at least very few. Still, there are things you can do and there are people, like me, who are more than happy to help.

Before I get stuck in it is important to say is: measuring productivity by output can often mislead. More output isn’t necessarily more or better outcomes. Outcomes can be complicated things to pin down. While we can’t put a financial value on everything examining the money can be a short-cut. To complicate matters, sometimes doing less, even producing or doing nothing can raise value. Think of all the features Apple leaves out of its products which increase their value, or think of software bugs you don’t write. Fixing bugs can increase your output, and therefore your apparent productivity, but not having them in the first place give the customer a better outcome.

Now some thoughts…

1. New technology demands new ways of working

Sometimes you can buy a new machine which increases productivity – like the handheld food processor in my kitchen. This saves me a lot of time cutting up onions. But more often than not to get the full benefit of new technology you need to also update the way you work, the processes and practices.

While a machine may increase productivity there are almost always more benefits, more productivity, to be had if you change the way you work. This is true everywhere, and its why I’m having more conversations about how non-technology companies, often small companies, can benefit from adopting modern “agile” management ideas.

2. Do less to produce more

I feel like a broken record but again and again I see companies which would produce more if they tried to do less. In other words: Reduce work in progress.

The mantra is: Start one thing, do one thing, do it to the end. Then, only then, start another.

Time and time again I see companies, teams, and people which are simply trying to do too much at anyone time. The trick is to sequence them. If this describes you than please watch the Featureban video I released a few week ago.

3. Visualise, understand then improve your work

There are few single shot improvements to be had but if you spend time understanding your work, tracking it with a visual management system, collecting some statistics and analysing where the time goes there are always things you can do to improve it. Chances are time (and therefore productivity) is not lost because one step or person is slow, rather there is an impediment in the flow which needs fixing.

If you don’t already have one then create a visual board to see your work. I’m a big fan of physical boards but I accept most teams today want something online so I recommend KanbanZone.

Now I could talk and talk about how to set up such a board and I will happily do so if get in contact – but if nothing else create one and get everyone’s views on how to use it.

4. Separate work by variability and duration

Once you start to understand your work you will most likely find that there are different kinds of work take different amounts of time (answering one e-mail is quick, writing a blog takes time) and variability (most e-mails are quick, but occasionally one takes hours). Using this understanding you can separate the work into different streams and plan your time around the streams. This will increase productivity.

5. Sacrifice one person

In some cases it makes sense to “sacrifice one person” to do the seemingly random, late breaking, small pieces of work which so often arise. The rest of the team can then focus on the bigger, time consuming, stuff. Of course, make sure you rotate the sacrifice every week or two.

6. Daily reprioritisation

I start each day by rewriting my priorities. With clients I sometimes have team leaders review all team priorities at the start of the day (just before the stand-up meeting if you have one.) That might not mean you produce more but it should ensure the most valuable things get done which will increase productivity.

Now I could write a long list on Monday and work with that. But actually, taking a few minutes each day to go over priorities – even if they haven’t changed – is more productive.

Overall…

I’m sorry to say, these options might require investment and time. Chances are the most obvious productivity enhancing options have probably already been used up. So some time, and perhaps money, need to be invested. The good news is that your accountant should be able to capitalise expenditures so your net value increase.

Of course, the sooner you start the sooner you get the benefits. This is where I might be able to help so let me sell myself for a moment. I’ve helped many companies over the years improve the way they work so please get in touch.

6 ideas to boost productivity Read More »

Help – a survey about product leaders

I’m running a little survey – 5 minutes of your time – about the people and roles who decide what should be done, or perhaps what should be built. The people who are often called Product Owners or Product Managers, and often Business Analysts, perhaps Requirements enigneers or… a myriad of other titles. I’m generically calling these people Product Leaders or Product Authorities.

Anyway, if you can spare me 5 minutes it would be grate to have your answers – survey is here, just a few questions.

Help – a survey about product leaders Read More »

Spending when uncertainty is high

I recently stumbled across David Rogers’ book The Digital Transformation Roadmap and found myself nodding in agreement with page after page. Many of the points and arguments Rogers advances are expressed in my own Continuous Digital, I see two differences. First off Rogers is an established academic at Columbia Business School, so he approaches the topic with rigour. Second, he tackles the subject from a digital business starting point, Continuous Digital grew out of the agile and #NoProjects movements. Still, they end in the same place.

One of his models keeps coming up in my discussions with Product Leaders again and again, he calls it the Rogers Curve. Like I do in Continuous Digital he points out that the venture capital industry funds technology products very differently to corporations. A corporation minimises risk by doing lots of up front research, validation and planning. Then, if everything checks out authorises big expensive projects. When things go wrong (because the research missed something, validation was flawed, plans were too optimistic, delivery was more difficult than expected, or, importantly, the time spent making sure the money wasn’t misspent delays the work so much it has lost value) then it is difficult to cancel work because the momentum is high.

Conversely, venture capital firms invest far smaller sums of money on far less evidence, research and planning. Additional funding is only given if ventures make progress on validating the model and delivering. VC firms offset risk by placing many “small bets” which they expect to lose. As long as a few bets succeed big they will make money overall even if they lose most of the time.

In Continuous Digital I argue that all technology work should adopt this model. Rogers suggests something slightly different. His Rogers Curve combines the two. He says: when uncertainty is low then use the traditional project model with the upfront validation. However, when uncertainty is high then use the VC model.

Uncertainty might come from using a new technology, entering a new market, creating a new product for an existing market, or some other source. Naturally, certainty comes when none of these is true. Which begs the question: “why bother?”

Remember that much uncertainty is actually risk. According to economists: profit is the return for risk. If you eliminate the risk then eliminate the profit.

Imagine for a moment you see a market opportunity. You see that existing technologies can be repurposed to meet this opportunity. You easily ascertain that potential customers want the product and will pay. Best of all, you see that little work is needed to seize this opportunity. The stars align. You are in business. But, if you can see this opportunity and how to fill it the chances are others can too. If they haven’t already done this then they can quickly copy you. You have no defence from competitors. No risk, no reward.

Back to the Rogers Curve. This provides a great way of looking at future work: do we feel safe? Yes, then big up-front investment. Or do we feel uncertain, exposed to risk? In which case give it a little funding, review and refund often. And be ready to walk away.

One problem I do see with the curve is the “But we know” problem. Specifically, I remember one executive sitting opposite me and saying “We know what needs doing. We know who are customers are and what they want.” Needless to say they didn’t. The company became a lot more successful when they started acting as if they didn’t know (and sacked that executive.)

This happens all the time. People and companies are sure they know what is wanted – cognitive biases are at work. Version 2 technology rewrite projects are a classic example. These always have big problems. There is an assumption that the “only thing” version 2 needs to do is everything version 1 does, just on new technology. These projects always end up in trouble (but that is another post.)

Part of me thinks this curve is unnecessary because the little-and-often funding model will work in a certain world just as it works in the uncertain. But, corporations aren’t set up to work like that. Corporations are set up to fund and run big projects with lots of upfront work. In other words: corporations are not optimised at doing lots of small.

Jumping to a new model in one go is hard. Far better for the corporation to carve out some innovation money and a ring fenced a unit to spend the money. Call it an innovation unit, a lab, an incubator or whatever. Within this unit manage investments differently using a VC-style governance process. The money needed will be far less than one big traditional project to start with.

This unit can accept small innovative ideas with little market research, validation or planning. The minimally viable teams which are funded here are tasked not just to build the thing but to validate the ideas, exploring options, understand potential customers and everything else a start-up would do.

Now at this point some readers will be saying “We do that.” As Rogers points out, and I’ve seen myself, companies do do this but only sometimes. They don’t do it systematically. Nor do they do it repeatedly. Running these types of initiative, and more importantly governing them, is itself a skill set and process which needs developing itself.

Many companies can point to instances of innovative products managed in an innovative way. But such initiatives have to fight through a system which is designed to stop them. They succeed despite the system not because of the system. How much more successful could the company be if it created support mechanisms?

Spending when uncertainty is high Read More »

Benefits of Value Poker (2 of 2)

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?

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.

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

Playing Value Poker in the Dagons’ Den

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.

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

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

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.

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

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 »