User Stories by Example: certifcate added to the free courses

Allan Kelly from Allan Kelly

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

The post User Stories by Example: certifcate added to the free courses appeared first on Allan Kelly.

Agile OKRs extra – yet another book

Allan Kelly from Allan Kelly

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.

The post Agile OKRs extra – yet another book appeared first on Allan Kelly.

How I write books – A book about books

Allan Kelly from Allan Kelly

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.

The post How I write books – A book about books appeared first on Allan Kelly.

Its the engineers, stupid – one from the heart

Allan Kelly from Allan Kelly

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

The post Its the engineers, stupid – one from the heart appeared first on Allan Kelly.

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

Allan Kelly from Allan Kelly

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.)

The post Réussir avec les OKR en Agile (French OKRs) appeared first on Allan Kelly.

No unified theory of agile (Agile mindset cont.)

Allan Kelly from Allan Kelly

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

The post No unified theory of agile (Agile mindset cont.) appeared first on Allan Kelly.

User Stories by Example tutorials now Free

Allan Kelly from Allan Kelly

My User Stories by Example tutorial series is now free.

There are five tutorials which include video lectures, worked examples with on real user stories and exercises covering user stories basics, acceptance criteria, story splitting, story refactoring and more.

The series is based on my Little Book of Requirements and User Stories – the audio files for the book are there too but you will have to pay for them. If you are an Audible subscriber you can get the book there as part of you subscription. Print book, eBook and audio book are all available at Amazon.


Subscribe and download Continuous Digital for free

The post User Stories by Example tutorials now Free appeared first on Allan Kelly.

The Agile Elephant and the agile mindset

Allan Kelly from Allan Kelly

African Elephant

Confession: I’ve been avoiding the words “agile mindset” for some time because I don’t know what it is. And, completely by coincidence, I’ve recently had a couple of encounters that have caused me to think again. So let me explain…

I repeatedly find myself wrestling with the question “What is agile?” The question came up recently in a new form when I was invited to give a talk on “The Agile Mindset.” I appealed for help on LinkedIn. I got some great answers and the diversity of answers confirmed what I though: it is hard to describe “the agile mindset” in a short or generally agreed form.

The first problem is that to explain “the Agile mindset” one first has to agree what agile is, and is not. I have my own view but I know there is a diversity of opinion so I find it useful to describe “Agile” with the story of the blind men examining an elephant: one feels the leg and says “This is a mighty tree”, another feels the tusk and says “It is a strong sword”, another the trunk and says “It is a strong snake” and so on. Each interprets the part they encounter as the whole yet the whole, to one who has never seen an elephant, can be hard to comprehend.

Illustration from the Natural History Museum, London

The same is true for agile.

The literalist looks in the dictionary and says “Agile is about being fast, reactive and responding to the outside”, the engineer looks at agile and says “It is about doing quality work so we may deliver more”, the Scum aficionado says “It is about high performing teams and alignment”, the Lean thinker says “It is about reducing work in progress and simplifying workflows” and the management consultant says “It is about delivering more with less.”

All are right, none is wrong. And while that is a problem in describing what agile is it is also a strength. Agile is multi-faceted and offers “something for everyone.” While different people emphasis different things it also means the whole is more than the sum of the parts. If you can harness high performing teams, with engineering quality, low WIP and reactive processes then you can deliver the fabled faster, better, cheaper.

But that also makes it hard.

It also goes some way to explaining why “Agile Coaches” never agree: each has their own interpretation of how to put those pieces together to make the whole – to change metaphor, everyone approaches the jigsaw differently.

And again that is right because every jigsaw, every application of agile, exists in a unique context and must be faced on its own terms – to quote Tolstoy: “All happy families are the same, all unhappy families are unhappy in their own unique way.” (And long time readers might notice I just contradicted myself.)

And one important reason why the jigsaw is always different is: in completing the last jigsaw, and since completing it, you, and everyone else as learned, the bodies may be the same but the people – and their minds – are different.

Ultimately, I still claim “Agile” is learning, specifically organizational learning: the thesis I laid out in my first book over 10 years ago Changing Software Development.

Hence I say: The only thing you can do wrong in agile is work the same as you did three months ago. To be agile one should always be learning and changing as a result of that learning.

I should explain that some more in another post, and I’ll have more to say about the agile mindset soon.


Subscribe to my blog newsletter and download Continuous Digital for free

The post The Agile Elephant and the agile mindset appeared first on Allan Kelly.

The difficulties of cascading OKRs

Allan Kelly from Allan Kelly

I almost despair when I hear people advocate cascading OKRs: the idea that someone, some team, some central planning department, can set OKRs which then flow down the organization with each “lower” group implementing some small part of some “higher” ask. What could be more waterfall like?

I admit, when I started working with OKRs I kind-of-expected to be shown the OKRs of the “above” before my team wrote theirs. But when I thought about it, and the more I thought about it, the more I realised if you did do it that way then it is decided unAgile. How can a team be really autonomous, self-organising and self-managing if they have goals handed down to them?

There was a point when I was wracked with self-doubt: am I interpretting OKRs differently to the rest of the world? How do I reconcile agile and cascading OKRs? What am I missing? – but, when you look around, I am not the only one. In fact, if you read, watch and listen to OKR commentators the majority agree with me: the teams delivering OKRs need the latitude to set their own OKRs.

Reconciling OKRs with agile is far from the biggest problem. In fact there are, at least, two bigger problems, one concerns team motivation. Can a team ever be motivated to do something they have no say in? Perhaps some can, I can’t and I know others who don’t. At the very least team members need to be asked.

Motivation becomes especially problematic if you want OKRs to be stretching. If you set someone a stretching goal and ask them to hit it without involving them then don’t be surprised if they shrug their shoulders.

Still, we haven’t got to the biggest problem.

The biggest problem with OKRs is not the metaphysical issues of motivation and whether one is truly agile or not. The biggest difficulty is simply: cascading OKRs are not practical.

First think about the timetable.

If every team is waiting for the team above them to issue OKRs before they set their own then you have a delay built into the system. And the more levels of hierarchy you have the greater the delay is going to be.

For example, suppose you have an executive team, and middle management team and several delivery teams. Then each cycle the exec team need to set some OKRs, once they have set their the middle management can set theirs, and then the delivery teams can set theirs. At each cascade point there needs to be communication, and each point creates the possibility of misunderstanding and mistakes.

Setting OKRs isn’t instantaneous, I think you need about a week to have a think, reflect overnight, iterate once or twice but, if you are well practices, and don’t hit any delays, you might do it in two days. Either way it is going to take at least a week, and possibly three, to get all three layers set. And if anyone runs late then it has a knock on effect.

I’ve heard it said that the Key Results of higher levels become the objectives of the next layer down. The key results of this layer the become the objectives of the one below them. But that assume that the OKRs themselves are a series of “items to do” and that each objective is made up of several pieces which are themselves things to do.

Sure, it sometimes happens that way. I may even have been guilty of interpreting them that way sometimes. But these days I see Key Results not as small pieces of work which, lego style, build into a bigger objective but as Acceptance Criteria: the parameters which the outcome needs to satisfy.

Now to some degree acceptance criteria can be translated into work items to do, and vice versa, but not always. Consider this:

Objective: Improve overnight batch processing to save 10% of work processing costs
Key result #1: Shorten batch processing time by 1 hour so staff do not need to wait for run to complete in the morning
Key result #2: Reduce false positive alerts by 100 per day so that staff waste less time

Now these key results could be packaged as individual work to do but perhaps they are the same piece or work. Perhaps a database upgrade could address both issues in one go. Which path you take is a design decision.

Seeing key results as acceptance criteria changes them from work to do into bounding conditions.

In Succeeding with OKRs in Agile I advise against having domino key results: don’t set key results so that failing to hit one makes others impossible to hit. So, for example, if the DB upgrade had been added to that previous example as key result #1 then the team would have been committed to doing it. And if the upgrade had failed then the other key results would have been lost. Leaving it out gives the team the decision on how to proceed: the people doing the work decide the best way of meeting the objective.

That advice is given within teams but it also applies between teams. If, the Middle Management team require three lesser teams to deliver work to build their own objective then, if any one team fail the middle management team will not only miss one key result but will therefore miss their objective.

Done like this the OKRs become fragile and a dependency nightmare. That will have two effects, first more time will be needed when setting OKRs to identify and mitigate the dependencies, then more time will be needed to manage the dependencies. Progress will only occur at the speed of the slowest.

Second, these problems will encourage people to play it safe and not set stretching and ambitious OKRs. Predictability and safety will be prioritised.

Now if we take the alternative approach and each team sets its OKRs independently then the time lag is removed, teams set OKRs in parallel and if someone is late it doesn’t matter. Dependencies may still exist but they have not been baked into the OKRs so teams can put effort into removing dependencies (reducing coupling and increasing cohesion) rather than putting that energy into managing the dependencies.

So, while we might argue about whether OKRs should, or should not, cascade down; and while we might argue about the psychological effects of being given an OKR by another, simply remember: cascading OKRs mean setting OKRs is going to be more complicated and take longer.

Photo by Alexander Hipp on Unsplash


Subscribe to my blog newsletter and download Continuous Digital for free

The post The difficulties of cascading OKRs appeared first on Allan Kelly.

Class war in the modern workplace

Allan Kelly from Allan Kelly

Writing about “The knowledge worker” in The Age of Discontinuity (1968) Peter Drucker offers this insight: the knowledge worker sees themselves as a skilled professional, or “white collar” to use an old term. To this end programmers, marketeers and conference producers see themselves as akin to doctors and lawyers.

But, Drucker says, these professionals are still employees and are seen by their employers as “workers” more akin to the “blue collar” factory employees of years gone by. I’ve long found it ironic that many contractors like to see themselves as entrepreneurs and small businesses while their clients may well see them more as casual day-labourers who can be hired and disposed of with little thought.

Quote from Peter Drucker book
Age of Discontinuity “The

Look at it like this: once upon a time the majority of employees would be working on the factory floor, their hands would get dirty. The work of the manger was to optimise both the work they were doing and the way the work was done, employees were probably not encouraged to think too much.

Today is the age of mass knowledge work – at least in developed western countries. The majority of employees type at keyboards and spend all day talking to others about ideas. Their hands stay clean.

Look at the qualifications people hold: in the past blue-collar workers might have a skill, many were “unskilled” or “semi skilled. Workers “trade” might be learned via an apprenticeship which involved observing and doing the work. Today we live in the age of mass knowledge work, the bulk of the workforce are not factory workers or dock labourers but educated analysts, programmers, accountants and such.

Modern blue-collar workers are overwhelmingly degree educated and do expect to have a say in their work – both what is done and how it is done.

When I visit clients I sometimes see – or rather hear – this explicitly when managerial types talk about “the factory floor” or “engine room” when they mean the offices where IT staff work. You see it too when teams are treated as “feature factories” and measured on how many “user stories” or “story points” they complete and how fast the burn-down chart burns down.

There is a mismatch in the way workers view themselves and the way the managers view the workers. This mismatch in views becomes a misunderstanding and can escalate into conflict.

Workers advocate replacing management with “self managing teams” and managers look to replace programmers with with automatic programming, “programming through pictures” or lately “lo code” solutions. Rather than resolving the conflict it becomes an existential fight. Sometimes it can even look like a modern class struggle between workers and employers.

There are no silver bullets to this conflict. Both sides needs to respect one another and we need to find a new understanding of roles.

One of my favourite takes on this dilemma comes from Tim O’Reilly. In an essay entitled “Managing the Bots That Are Managing the Business” (2016) he suggests that the true workers of today are the machines: it is the factory robots that assemble cars, take our online orders and increasingly do all the “heavy lifting”. The managers of these machines are the people who instruct the machine what to do and how to do it. Most obviously programmers but also the many who work use digital technology to instruct a machine, e.g. a marketeer who schedules tweets, or customer service agent who scripts the chat-bot.

Either way you look at it the fact is that modern blue collar workers need more of the skills and knowledge traditionally reserved for managers: they need to understand the profit and loss, plus they need to understand business goals and strategy and appreciate the consequences of their actions. And it means the white-collar managers of the managers need to respect the knowledge workers as peers rather than hired help, they need to be explain business goals, strategy and be open about the business.

It sometimes feels as if the “class war” of the early twentieth century is still with us. Only now it is not blue collar workers fighting white collar but white collar workers fighting between themselves.


Subscribe to my blog newsletter and download Continuous Digital for free

The post Class war in the modern workplace appeared first on Allan Kelly.