Agile

The Excess Strategic WIP problem

Try pouring a bottle of milk into a glass with milk already in it. You have a choice: stop or tidy up the mess afterwards. That is my work-in-progress (WIP) analogy, if you try and do too much – no mater how much you want to do it – you will end up with a mess.

Agile folk are well versed in the problems created by too much WIP and how to deal with it – check out the Stockless Production video if you want to see. In the last six months I’ve been seeing a particular variant on this problem with I’ve come to label the Excess Strategic WIP problem.

In the latest report the manager told me how the team completed a great quarter with 3 priorities – set via OKRs. The senior management team were so impressed they asked for 19 priorities in the next period.

Right now I don’t have a “paint by numbers” solution, fixing this problem is more involved. I’m starting to understand it and I’ll make some suggestions later. Ultimately this a failure of leadership to say “No”. That failure is itself rooted in a failure of leadership to appreciate what is happening on the ground and what doing the worker are up against: the number of strategic initiatives or the amount of business as usual.

In a team it is easy to spot excess WIP using a visual system like a whiteboard or card system. When you track work like this you see an awful lot of work sitting in the “in progress” column. Typically there is more work than people on the team and the work isn’t moving. Some of the work may be actively marked as blocked but more likely most of it is nominally being worked on.

It can’t all be worked on at the same time because despite having two eyes, two hands, and two sides of a brain human’s can only really do one thing at a time – even new parents. I label this work “WHIP” – work hopefully in progress. While it is, in theory, being worked on, most of it is just sitting there waiting for a multi-tasking (i.e. time slicing) person to come back to it.

The good news is when you can see the WHIP you are half way to solving the problem: there are well known solutions. Accept less work, impose work in progress limits, sequence work by adding queues to the board, educate people to work on one thing until it is done, etc. Once you can see the work you have a feedback mechanism, you can take action and, thanks to the feedback mechanism, watch it reduce.

But Strategic WIP is more difficult. Strategic WIP is the stuff the organization decides in really important, the stuff the most senior leadership decides should be happening. The Excess Strategic WIP Problem occurs when those strategic priorities are greater than the organisation’s ability to deliver on them.

While some of this work may be transactional (“Build a Mega Widget”) much of it is transformational (“Adopt Agile working”, “Increase diversity”, “Tighten security”). Such things involve changing the way other work is done: changing the processes, changing the criteria, increasing awareness. The feedback cycle is long but to get started people need to devote time: attend training, arrange kick-off meetings, discuss approaches with consultants/coaches, etc.

In one case I saw this year the organization has, for years, been asked to do more than it is resourced to do. While a few months of such a mismatch might have been manageable the cumulative effect has been to create organizational debt and demoralised staff.

The second case I saw isn’t a result of under resourcing, if anything that organization has too much – money, people and perhaps equipment then they know what to do with. But because their management model resembles a sponge it is impossible to know when the organization has taken on too much. While some pockets were overworked I’m sure other pockets were idle.

In both these cases “lean” was a dirty word. Both organizations had been subject to lean programmes that had stripped out “waste” but, from what I could see, removing that waste had created both organizational debt and demoralised staff. Having removed “spare” staff those left were juggling. Staff didn’t have time for “agile” and their diaries had no space for daily essentials let alone another change programme.

The third case came to light when discussing OKRs. The company had a successful quarter were they focused on a few objectives that success seems to have bred the next failure when the organization requested many objectives.

Actually, this case brought it home: taking on too many, or being given too many, OKRs. I’ve heard of teams tackling too many OKRs so many times in the last year. (In fact, I should name this “Excess OKRs Problem”. This occurs whenever you have more OKRs than you can count on one hand. Don’t tell me your team is big enough to do so, check out Focus is not divisible so limit you OKRs.)

In a way, the Excess OKRs Problem is better than the Excess Strategic WIP Problem because you can see it. One can say “OK company, you have asked us to deliver 15 OKRs here, we need to sit down and talk about this.” Like visualising your work in progress excess OKRs is a thing you can identify and address, it is the reason to talk.

(Note: unlike User Stories which should always be small, OKRs should never be small. OKRs should be big, meaningful and preferably strategic. No team can take on 16 meaningful OKRs, even 5 is too many.)

One of the problems with excess Strategic WIP is that it can be difficult to see, there are different teams involved and in different places. Conflicting priorities are hidden. People on the ground may see problems but the senior people – the people creating the WIP – are too far removed. Those people may not want to hear people saying “You are asking too much”. They may have too much riding on getting multiple work streams done. They may be deaf to the cry of pain when people say “too much.” They may have too big an ego to accept that what they are asking for is a problem. And it may be politically unacceptable.

“Political” is an important word here: several of the cases I’ve heard of, and some of those example above, are Government agencies.

Because excess strategic WIP is difficult to see it is difficult to build a feedback loop and difficult to take action. How do you know when the problem is too much WHIP and when people are “crying wolf” ? – which in itself implies a problem of trust and maybe a belief that “everyone is lazy, we need to push harder.”

By its nature “strategy” is big, which means that the feedback cycles are long and the problems of excess strategic WIP take time to play out. What is a WIP problem looks like another failed strategy.

While I would like to think OKRs can help with this situation – because they force teams and organizations to take stock of what they are working on – they may be making things worse because OKRs include an ambition agenda. Teams are encouraged to “shoot for the moon” and build “10x solutions”. There is good logic here: if one aims for a “10x solution” (i.e. a solution 10 times better than the status quo) and falls short the “failure” may still be “better” (e.g. “5x”) than if one had aimed for a “2x solution” and succeeded.

Ambition with OKRs should not be about doing more OKRs, rather ambition is within the OKRs, a challenge that makes you approach it differently. One can draw a line here between having one OKR which aims for “10x” and having 10 OKRs but I suspect the subtlety will be lost on someone asking for “more than you think you can do.”

So whats is the solution?

I’m not sure there is a silver bullet but I would want to … make the problem visible, perhaps a portfolio level kanban board. I would want to build a feedback loop so I could measure change. I would want to show the strategic people the visualisation.

Management education has a part to play too. I can believe many senior managers would benefit from understand what WIP is, the problems excess WIP can cause, the way excess WIP plays out on a day-to-day basis and how it effects people’s working lives. And perhaps most of all, address trust and the belief that “we just need to push harder.”

That might also mean some of the Lean waste lessons and OKR ambition lessons need to be revisited.


Subscribe to my blog newsletter and download Continuous Digital for free

Return of the sprint goal? (Infographic)

Most of the sprint goals I’ve ever seen are rubbish. Pretty much “do the random collection of stuff we’ve decided already.” Such goals are meaningless – save time by skipping them.

If a team adopts OKRs then I really hope they move towards more goal based working, in which case the sprint goal starts to have meaning again – although maybe the OKR replaces the sprint goal?

Either way, I see an opportunity to move away from backlog driven development (BLDD) and towards a more purposeful style of working. So it was interesting a few weeks ago when Gareth Davies from Parabol (online meeting exercises and such) sent me over this infographic and a link to a blog on Sprint goals. Food for thought.


Subscribe to my blog newsletter and download Continuous Digital for free

How I write books (my new book)

Regular readers will know I write books – quite a few by now, it gets embarrassing.

Being an author is a great conversation starter, when people hear you’ve written a book or two they want to know more – everyone seems to have a dream of writing their own book. It also means that people seek me out to ask my advice about a book they are writing, or thinking about writing.

So, I’ve started to write down all the advice I give to people in a new book – How I write books.

I’m following my usual pattern so you can buy early versions on LeanPub now – I released it last week and it immediately sold a few copies. As usual at this stage everything is in a state of flux; spelling, punctuation, grammar and all that jazz will be fixed later. Of course, anyone buying now will get free updates as they become available all the way to the final version.

If you do buy, then please let me know what you think.


Subscribe to my blog newsletter and download Continuous Digital for free

The only thing you can do wrong, and the opposite of agile

The only thing you can do wrong in agile is to work the same way you did 3 months ago.

Corollary: The opposite of agile is static.

“The only thing you can do wrong” is born out of two things: my belief that agile is all about learning and putting learning into action.

Second, the proliferation of “agile tests” – maturity models, things like the Nokia Scrum test and the mental models in our own minds which condemn teams . Failing these tests means you label the team something like “Agile in name only”, “ScumBut” or “ScrummerFall”. I’ve seen my own share of these teams but honestly, I don’t care. Motivation to change a bigger issue, as long a the team are trying to improve its just a question of time – you might be “AINO” but if you keep trying you will become “Kick-ass agile.” (Plus, as an agile consultant these teams are potential clients, send them to me!)

If you are learning and attempting to act on that learning you will make some false moves, you will need to undo some changes but over time you will move forward.

You need to learn in three domains: Solution domain – the tools and technology you use to craft solutions and systems; Application or problem domain – understanding the problem/opportunity you are trying to solve/exploit, understanding what customers’ need and what the market will pay for. (I tend to think of this as the demand side); and the Process domain – the way you work, your processes and practices, the most obvious place were “agile” fits in.

The boundaries between these domains are fluid you need a learning culture in all three.

More recently I realised that “the only thing you can do wrong” has a corollary:

        The opposite of agile is static, not learning and not changing

20 years ago agile advocates invented Waterfall to be the enemy – sure the cascade model, à la Royce, was industry standard but nobody, NOBODY, called it Waterfall – believe me, I’m old enough to remember first hand. Agile was described by reference to what agile was not, and that not was named “waterfall.”

But that is wrong.

The secret is in the words: Agile implies movement and action.

Not moving is called Static, so the opposite of agile is static.

Once you accept agile means movement and change the next question is: how fast?

Rather than agile tests and “agile maturity models” we should be to measuring the speed of change and the speed of improvement: how fast are the team learning and acting on that learning? how successful are they at that?

When I floated this suggestion on LinkedIn a few days ago a few people pushed back. One argument was that I was advocating “change for change’s sake”. I’m not. You are free to not change, you are free to not change if you wish, all I’m saying is don’t call that agile, ‘cos its not, that is static.

Not changing is static, and static is not agile.

Now maybe static is the right thing for you. If your team can repeat their way of working, if they are predictable, and if the team and stakeholders are content then then change! Embrace static.

I’m doubtful such a static position is anything other than a short term Stable Intermediate Form. Static implies a stable environment, one in which at all forces are in equilibrium: nobody is asking for faster delivery, nobody is changing their ask, nobody is complaining about technical debt, overwork, predictability and so on. If people are not complaining then celebrate, you are living the dream! Just don’t call it agile.

“Finished” software is static because nobody changes it. Software ages because it stays unchanged while the world around it changes.

A second argument was that constant change was not good for people. Now I’m not arguing for constant big change, or constant top-down change. In my mind agile change is largely incremental – sure sometimes you need a big change but most of the changes are small.

I also challenge the assumption that change is top-down and that change is done to people. In my experience when those doing the work are enrolled in the change process, when they can see the potential benefits then it is a different matter. In my experience “change resistance” is more likely “resistance to being changed.”

Finally, “last 3 months”. That time frame comes from my intuition, it is a period long enough to see if change has happened without demanding that the team are never repeating themselves. I imagine the team moving from one Stable Intermediate Form to another Stable Intermediate Form over those 3 months. Feel free to suggest another time frame but if you think 3 months is not long enough to see change then how long? 4 months? 6 months? 12 months?


Subscribe to my blog newsletter and download Continuous Digital for free

User Stories by Example: certifcate added to the free courses

A couple of months ago I made my online User Stories by Example tutorial series free. One client suggested that the series would benefit from a certificate at the end. Good idea, I’m always open to suggestions.

So, I’ve added a new tutorial to the series: exam and certificate – rather than just give a certificate of attendance to anyone who plays the videos I’ve set a little test. There is a bank of questions which are randomly selected and should cover the five areas of the tutorials. Score over 60% on the test and you get a certificate which lists the key topics covered.

I’ve set a small fee for this, once you have paid you have 21 days to do the exam and you can sit the exam as many times as you like.

As always, if you have any suggestions or other feedback please let me know. And if you have any ideas for new questions send them over, I’d love to increase the question pool.


Subscribe to my blog newsletter and download Continuous Digital for free

Agile OKRs extra – yet another book

I blogged last week that I had begun work on a new book – How I Write Books which is now a work in progress at LeanPub – signup and be the first to know when the draft is published.

Well a funny thing happened while I was setting up my tool chain to write that book: I found another book! Well, perhaps half a book is a better description.

Succeeding with OKRs in Agile Extra is a companion to last year’s best seller, Succeeding with OKRs in Agile. But it isn’t a complete book in its own right, it isn’t really a sequel, it is a companion. It contains a mix of material. Material which didn’t really fit in the first book, material with was’t needed, ideas which didn’t develop far enough and some unfinished chapters.

As such it is like my Xanpan Appendix, unused material which is still interesting and might appear elsewhere in time.

I really want to work on How I write books so I don’t have any immediate plans to progress extra. If you enjoyed Succeeding with OKRs in Agile, if you would like to know more, or if you would like to just see how a writer’s mind works check out Succeeding with OKRs in Agile Extra.

How I write books – A book about books

In the last 15 years I’ve written and published 3 books with publishers, published 5 books myself, plus edited one conference proceedings and pushed out three “mini books” (one with 3 editions) which I never publicised.

In addition I’ve contributed forwards and chapters to at least six books and had two books translated.

Then there are countless magazine and journal articles but they stretch back further, closer to 25 years – and this blog from 2005.

Not bad for a kid who was thrown out of school after asking a teacher how to spell “at” – age of eight, a diagnosed dyslexic who had to learn to read three times – I can’t read my own handwriting its so bad.

As a result I’ve learned a lot about writing and publishing. In the last few years I’ve spoken to many people who want to know how to write and publish their own book. A couple of years ago Steve Smith suggested I write a book about writing books. I’ve been avoiding that until this month.

Now I’ve started: How I write books, https://leanpub.com/howIwrite – sign-up to be the first to known when the MVP is published. And if there is anything you would like me to write about in the book please let me know.

Its the engineers, stupid – one from the heart

When I engage with company and teams I’m always keen – nee desperate – to get to meet the engineers and teams who are doing the work. If days, maybe even weeks, go by and I’m not doing that I get very frustrated. More importantly I’m not sure what to believe from those I am talking to.

There was once a bank I spent time with. As soon as I got to the office I discovered almost all the engineers were in a far away country and I wasn’t going to get to visit that country. The few engineers in the London office spent a lot of their time hand-holding those in the far away place. When you looked closely, when you spoke to the engineers far away you found things didn’t add up. One delivered a perfect 10 story points every iteration without fail. Another team increased velocity sprint after sprint. One engineer fell off his moped and broke his arm, the work was still delivered on time – it took all my wiles to discover another engineer had worked all weekend to meet the deadline.

Why am I so desperate to meet the engineers? – well there are several reasons, some more rational than others.

First off, the engineers are where the work happens. In lean parlance they are the gemba, source of truth.

Second, these are the people who will need to change or be changed. There is only so much you can change with an organigram – and to be honest, I’m doubtful reorgs really change much. Sometimes I imagine managers moving their workers around like pawns on a chess board while the reality of work is hand-to-hand combat.

Thirdly, and perhaps most importantly for me: I see my role as helping these people. I am, by profession, by temperament and by ancestry an engineer. I am motivated by the desire to help those who do the work have a more fulfilling life. I still remember the frustrations I faced as a coding software engineer.

Thats why it hurts – really hurts – when engineers tell me “agile is rubbish”, that “agile has nothing to offer”, when they tell me that I’m not helping. Its not that I’m precious about agile, “agile” is just the toolset I’ve found helps. I also know that tool kit allows me to go outside the toolkit.

I was hired by a Californian company to give agile training to their Cambridge team. A few minutes in, one of the engineers told me directly “Agile can’t help us here, we can’t go any lower.” The other engineers in the room were of the same opinion. It turned out the managers had been to Scrum training and come back pumped up about high performing teams and faster-better-cheaper. Sustainable pace, autonomy and quality weren’t on the table.

That hurt and it may have been the toughest training gig I’ve ever had but I think I turned it around. I demonstrated the need for quality and explained the managers were missing essential parts of the puzzle. Unfortunately I didn’t get to meet the managers – they were off playing chess.

But I do engage with managers. Often they are the route to the engineers. Unfortunately some engineers see that as a problem in itself: “our problem is tech debt, sprinting won’t help us” so I’m discounted. In my world – the world of Xanpan – sprinting is a rod you put up your back to make yourself better, if you don’t address quality (e.g. tech debt) issues then you won’t succeed at time-boxed iterations.

(BTW I talk about engineers because most of my work is with engineers, and software engineers at that. I’ve worked a little with other professions and I’m sure most of what I say carries across directly but my experience and empathy is greatest with engineers.)

To deal with managers one needs to understand their concerns, one needs to listen and speak in ways they understand. Engineers may struggle with managers and technical issues but managers also struggle with their managers, organizational debt, customers and the market.

The same is true when I wonder over into the world of product ownership – Product Managers and Business Analysts. Engineers have a bad habit of seeing these roles as “Management” but if you spend time with the “demand side” people you find their concerns are almost identical to coding engineers. BAs worry that what they are being asked to do is unreasonable, that it doesn’t make sense, that something else needs to change first and that people don’t appreciate how things really work. The biggest difference between programmers and BAs is simply that, on average, BAs dress more smartly and are more likely to put on a tie.

One can’t understand a system and one can’t get to the truth if one can’t visit the place where work happens. When manufacturing things that place is the production line, in the digital world that place is the mind. Constructing software is an intellectual exercise that happens in the mind and is only manifested via a keyboard in code. To see the truth one has to speak to engineers.

I’ve seen some awful work environments: a room packed with 28 engineers, very few windows, little fresh air, a development manager on a raised platform at one end, the HR manager at the other end, her desk right by the single door in and out with the clock-in-clock-out cards on the wall.

More recently a large project at a matrix managed organization. The complexity made it difficult to know who was actually on the project and what teams existed. Management existed in its own bubble.

I feel pain simply seeing such places. What it can be like to work there I can only imagine. I assume people become dumb to the pain, switch off to the failing and accept the normalisation of deviance. Or, to put it another way: a culture of failure.

Both of these two examples shared one thing in common: massive Gantt charts which claimed to plan the work. In one case I saw someone scheduled to spend a month writing a manual in two years time. While these charts claim rationality they are so disconnected with the gemba as to be fantasies. I feel cognitive dissonance knowing that the managers who put their faith in such mechanisms are both rational and totally mad.

Encountering such places is painful for me. On the one hand I want to help, I want to make the engineers lives better – that is what I do! The challenge can be great. On the other hand it can be mentally and emotionally draining. Because I am passionate about what I do I feel that. If I switched off, if I treated it as a money paying gig then I too become part of the same culture and loose my efficacy.

On the other hand, when things go right I love it – perhaps because I’m an engineer and I see fixing the organization as a way of fixing the code, its called Conway’s Law.


Subscribe to my blog newsletter and download Continuous Digital for free

Réussir avec les OKR en Agile (French OKRs)

I am delighted to say The French translation of Succeeding with OKRs in AgileRéussir avec les OKR en Agile – is now available thanks to the hard work of Nicolas Mereaux and Fabrice Aimetti.

The book is available right now on LeanPub as an e-book. After Easter we’ll start work on getting it a print version available.

Until then a big thanks to Nicolas and Fabrice!

(Please get in touch if you are interested in translating the book to your favourite language.)

No unified theory of agile (Agile mindset cont.)

Continuing my quest of “The Agile Mindset” I’ve been searching for a metaphor to put all the different ideas on agile into order. To cut to the chase: there isn’t one.

As much as I would love to boil “agile” down to one thing, or even a handful of key concepts and I don’t think there will ever be a single unified theory of agile. As I said before with the elephant example, everyone sees something different. Depending on where you are standing, the problems you face today, your own history and area of knowledge, and your own world view you are going to see and emphasise different aspects of “The Agile Mindset.” And you know what? that is a good thing!

First I tried thinking of Agile as the layers of an onion. The outside skin is the word “agile” – there is a valid reason for saying the agile mindset is there in the dictionary definition of the word agile: able to move, think and understand quickly, be nimble and subtle in movements, alert and observant when looking at whats happening and sharp when thinking. But that is only the outside layer, it is very general.

The agile manifesto would be the second layer. While the manifesto is specific to software it doesn’t require too much thought to generalise it to other domains. Actually, it is a bit too easy and there are more attempts to generalise it than there are people who have attempted to generalise it. Plus, as I’ve written before, the manifesto is over 20 years old, those who cling to it sound like Supreme Court Justices trying to read meaning into a document written in a different age.

And what are the next layers, and in what order? Does last responsible moment come above or below cost of delay? Is test driven more important than time-boxing? Are work-in-progress limits a version of time-boxing or an alternative to time-boxing?

And what is at the centre? For me it is learning but I can imagine people who will say it is People – perhaps manifested through Weinberg’s “Its always a people problem” quote – I’ve written about that one too, the People Problem Problem. Personally I think McGregor’s Theory X and Theory Y could be a candidate, which raises the question of agile’s fellow travellers – beyond budgeting, system thinking, Lean, and Mintzberg’s theory of emergent strategy.

I wondered if agile could be thought of as a brick wall, with each idea forming a brick, and then the whole being more than the sum of the parts. But that falls down (sorry for the pun!) on the layering problem. Which ideas are foundations and which decorative?

Similarly, I toyed with The House of Agile with different ideas represented by different rooms but that metaphor quickly runs into problems too.

In a way this makes the search fo One Agile Mindset even more desirable – the search for a grand unified theory of everything if you like. There must be something out there that combines all of this!

Ye the search for the unifying theory also highlights how damn difficult this is. Intellectually it is hard to accept that “the agile mindset” is a bunch of different ideas which different people interpret differently.

But you know what? Accepting that agile is diverse is itself agile – agile is not one idea, it is many, accepting that and valuing those different ideas mean embracing diversity and that itself is agile. Agile is what you want it to be because through those diverse we find alternative ways of viewing and learning. Agile doesn’t stand still, agile is punk, at its best agile is democracy.

Unfortunately that makes it hard to explain.


Subscribe to my blog newsletter and download Continuous Digital for free