Let me admit, after the firestorm that was #NoProjects I’ve avoided saying #NoBacklogs but I have to admit, if you have heard me say “Nuke the backlog” or seen my “Honey, I shrunk the backlog” presentation its natural tag to use.
Any, have a listen and let me know what you think.
Management has changed. Or at least, it has for the most successful. Unfortunately some people have yet to get the message and too many are stuck – managing or on the receiving end – in the old world.
While some reject the idea of managers and management entirely I don’t. I think the anti-management ethos is a reaction to bad management and outdated management thinking. “Management” is a messy, varied field, it is a practice, part administration, part leadership and several other parts too. Unfortunately, few managers ever study or reflect on management practice. There is a lot of poor, outdated management out there.
New technologies, new thinking and a new generation mean the idea of management, and what it does, needs updating. If management had a standard model it is the model of General Motors and General Electric in the post-war years. The model continued into the 70s and 80s as the baby-boomers replaced the managers who learned their craft in the war years. Today the management baton has passed to Gen-X and Millennials with a Gen-Z workforce.
These generations have attitudes and expectations of work which means management needs to change in order to do their job. Managers who follow Alfred Sloan’s model are going to have problems. While I love the visionary writing of Peter Drucker it too is a historical document.
Obviously technology has changed but technology has always changed, that is the nature of technology. Remember: technology change demands process change. That is why management can’t stand still.
Sloan’s writing about GM was replaced by Grove’s writing about Intel. Google replaced GE as a role model to work for, and Spotify replaced P&G as something a bit different. The “agile transformations” of the last 10-20 years have been about that process change as digital tools permeated every workplace.
Unfortunately some fields move more slowly so there is an impedance mismatch: think about accounting standards, or the way banks fail to consider knowledge as loan collateral. (Capitalism without capital contains a great discussion around topics like these and again demonstrates the change.)
In the last few years many of the new ideas and management trends have found a home under the Agile umbrella. Even I am guilty here with Succeeding with OKRs.
It is hard to work out which begat which: did the agile movement give us #NoProjects and lead to Product over Project, or was it the ascendancy of Product model in digital which drive agile adoption?
Eric Trist might have documented self-organising teams in the 1950s and General Mills might have experimented in the 1970s but it was the agile movement which brought them into the mainstream (even if they are still the exception).
But as “agile” absorbed more and more it has itself become harder to define because of that breadth.
Does agile include diversity? – I’ve asked before is agile dyslexic. Both the standard management model and the agile manifesto were created by men. Women, not to mention other groups, have since contributed and emphasised different ideas.
Organizational learning and Psychological safety are key to making agile work but should they be considered part of agile? The former pre-dates agile while the latter seems to be a movement on its own. Similarly Beyond Budgeting fits very very nicely with agile and shared-leadership but it isn’t a standard part.
I wrote last time about the Good Jobs Strategy, and in my work on OKRs I emphasis purpose in work. Should good jobs and OKRs be added to agile? Certainly they are part of modern management.
Agile isn’t big enough to add all these. To do so makes it unwieldy even if they are all fellow travellers on the road to realising Theory-Y.
Agile has always had the potential to be about more than IT. Indeed, as more industries adopt digital tools they need both agile and other ideas to get the most from those tools – including AI. The evidence that agile like processes work in healthcare, hotels, law firms and elsewhere is growing. (I’ve got some experience here and I’m actively seeking “outside IT” opportunities now, so I want to learn more.)
Recently I’ve taken to calling agile and all these other ideas: Modern Management.
Taken together all these ideas are consistent and compatible. They represent a break from General Motors and GE so they break from the standard management model. Management as commonly conceived in 2000 doesn’t cut-it.
If you consider yourself an agile coach or consultant today you need to have these ideas in your tool box. The toolbox used to be labeled “Agile” and those who knew the word thought of it as very IT. Now needs to be called “Modern Management” – there is are more tools and the ideas are more widely applicable.
Succeeding with OKRs in Agile is on sale this week only – September 9, 2024 at Amazon.
For this week only the e-book version of Succeeding with OKRs in Agile is $2.99 / €2.99 / £2.99 instead of $9.99 / €9.95 / £9.95 – that is 70% off.
The print version is reduced by 50% or more depending on market, from $19.95 to $9.95 – although some of these cuts price have yet to come through on the print version.
Other markets have similar massive price reducting this week only – there are a few exceptions because Amazon set a minimum price in some markets. And price-cuts are limited to Amazon, princes on Kobo and elsewhere remain the same because of the mechanics of the price cut.
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.
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.
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.
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.
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.
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.
“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 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:
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.
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.
