Allan Software Strategy

New book: Managing with OKRs and KPIs

Agile / /

Big announcement: my first book in over 3 years – Little Book of OKRs and KPIs: Managing with gaols, numbers and purpose is now on sale.

This quiet blog

This blog has been quieter than usual for the last few months. There are multiple reasons why, and as it was summer I’m not too worried.

My current client takes a lot of time, I had to finish my EuroPLoP paper and, I’ve been working on this new Little Book.

This book started as a short guide to OKRs, KPIs and how to use them together – expanding on my paper last year. It has expanded because I wanted to include warnings about over reliance on metrics and discuss the importance of having meaning beyond numbers.

Conflict in management

The way I see it there is a central conflict in management between the rational way of management and the more emotional, heartfelt, way of. Although I discusses the rational way of managing with OKRs and KPIs I highlight problems with numbers and the need for greater meaning.

The power and the flaw of both OKRs and KPIs is the same: the numbers. Managing with numbers can be very powerful but managing only with numbers is dangerous. So this book also looks the pitfalls from the numerical, rational, approach and gives some advice on how to avoid them.

This book is more developed and closer to finished than usual when I release a LeanPub book. That is because over the last few years I’ve started and abandoned a several books. So I have hesitated to announce this one until it was more fully formed than usual.

It also means this book borrowed some content from one of my abandoned books on company form and the need to nested goals. However, this goes further, perhaps controversially I argue that while OKR style targets are good for near term goal setting the biggest, most purposeful goals, should not be quantified.

Anyway, read the book and let me know what you think. As before this is a LeanPub endeavour which means you can buy and read the book now, before it is finished. It is still a work in progress so you can influence the upcoming content.

Problem Solution

My other recent project was finishing my annual EuroPLoP paper. This year’s paper is Reframing the Problem-Solution pairing – one pattern & a discussion. For the third year in a row what started as a small little pattern expanded once I got to thinking hard about the subject.

One version of Problem-Solution will be appearing in the Springer Nature proceedings in a few months. I normally make a similar version more publicly available. I expect to do the same again but am thinking of how to best present this work.

As they say, watch this space.

New book: Managing with OKRs and KPIs Read More »

Where did the IT hope go?

Uncategorized / /

I bumped into an old friend recently, in all our catching up he shared that he had left the IT industry, computing wasn’t fulfilling any more. He’s not the first person I know who’s pivoted away from IT. In part that is inevitable, there are always some people who change professions during their career and IT tends towards a younger age profile so people do change.

Yet, something has changed. It might be me (getting old and cynical) but I’ve now spoken to enough people to know I’m not the only one who feel the “IT industry” has lost its fun and fulfilment. It has become doom laden.

When I started it was all so hopeful: it was amazing to see these dinky little machines do something, anything! It was amazing to see other people use my software. It was liberating: I could make a machine so that, I could make someones work, their life, better, in some way.

I know “machines replacing people” has been a constant theme of technology but I honestly find it hard to remember a project I worked on which was aiming to remove people. Most of them were about helping businesses grow, do more, create products to sell, improve the world in some way: electricity, mobile phones, fire systems, financial information, and more.

In the process it was liberating. This continued in the agile epoch: it was about liberating the people who did the work to do a better job; to have a voice in how work was done and share control; it was allowing engineers to do quality work, and everyone to be proud of doing work which made a difference.

At some point this changed. IT became Digital which is now becoming AI. AI strikes fear in a way Digital and IT never did.

Largely because the AI marketing machine constantly tells us AI means job losses. IT and Digital created jobs. So too did many other technology changes in history, but the AI merchants have worked out that the quickest way to demonstrate ROI of their products is to promise job cuts. So rather than talk about what AI can do they emphasize cost cuts.

Then there is AI slop which undermines information itself.

Making it worse AI is an awful thing to scale up in the middle of a climate crisis.

But most of all it is the AI leaders: many of them are clearly neurodiverse and deserve cheering. But they present as Bond Villains, intent on world-domination, rather than a physical disability they have some other quirk which marks them out. Heck, some of them even speak with an accent!

These people, as the police say, “have form” -they are the same people who brought us social media.

It is hard to tell if their politics drives their work and money making, or their political associations are merely an accommodation to make more money.

The technology heroes of yesterday we so different: Steve Wozniak taught school computer classes after leaving Apple; Hermann Hauser never sold up and moved to California, he continued to champion British and European tech; Tim Berners-Lee who kept the web public, I could go on. There were always IT baddies (like Bill Gates, boo boo hiss hiss, until he complicated things giving his money away) but not on the scale of … well I won’t mention them.

Maybe I have rose-tinted spectacles: there has always been nasty military applications, and even the early web was used for porn, gambling came along not long after. I always avoided those things so maybe I only saw the positive.

But my point is: the technology industry used to be one of hope, about letting people do more and giving them more power. Today that narrative has been inverted. Social media, crypto-crime and data centres are polluting our environment and the elite people building the new tech seem to care little for the other eight billion.

Not all “IT” is doom and gloom. I continue to think people make a difference and while AI might be getting all the attention it is just the tip of the iceberg. Most of the IT industry continues with the same old problems.

Ironically, for a organization to get the most from AI it needs IT infrastructure that works. Commodity AI will never confer competitive advantage because it is, well, a commodity, everyone else has it too. Getting competitive advantage having AI systems nobody else has (i.e. you build them), using them with data nobody else has (i.e. fix your data plumbing so AI can learn about your business) or using it in a way nobody else does (i.e. you processes and practices have changed).

AI doesn’t invalidate everything that went before. If your organization struggled to get the most out of IT you will continue to struggle in the age of AI. More than ever there is a need to paint a hopeful picture of the future.

(Opening image Creative Commons from Soupmeister via WikiMedia.)

Where did the IT hope go? Read More »

Patterns for Highly Autonomous Teams & Team Energy Theory

Agile / / / , , , ,

A treat for those who like a longer read, two new papers. Both of these come from this summer’s EuroPLoP 2024 conference. As with all my other patterns papers these are on my website.

Patterns for Highly Autonous Teams

The first, Patterns for Highly Autonomous Team is a joint work with Tsvetelina Plummer and gives three patterns for, well, highly autonomous teams:

  • Autonomy over Money
  • Everyone a Manager
  • Simple Financial Reports

In addition to the patterns the paper contains a long pre-amble on the nature, naming and history of autonomous team – which also explains why the terms “self-organizing team” and “self-managing team” may not be the best.

Perhaps controversially the pre-amble also described why management and leadership are in not different things but, in fact, inseparable.

The patterns themselves seek to recast existing ideas in the pattern form supplemented by our own observations and additional examples. The origins of the paper was a desire to writer and research Autonomy over Money. When we went looking for new case studies we got two surprises. First, there were fewer examples to find than we expected – although they certainly do exist. Second, most of the examples we found were outside of technology and software development in particular.

So, read the paper and let me know what you think.

Team Energy Thoery

Second up is a write up of a focus group discussion of little theory which I’ve had for some time. To explain, let me quote from the paper:

“Team Energy Theory proposes using the metaphor of energy to describe team work. Specifically, TET explores how the rules of energy can be used to describe team work.

This paper describes a workshop which explored the theory. The workshop decided the theory was useful and provides some insight. It was agreed the model could be usefully applied with other groups to discuss what made for an effective team and how less effective teams came to be.

Several parallels were explored, e.g. natural tendency to minimise energy expenditure, and several more were identified for further exploration, e.g. the different forms of energy and conversation of energy between these forms.”

Again get in touch if you have any questions or would like to continue the discussion.

Both these papers best thought of as late drafts. They will officially be published as part of the ACM Digital Library proceeding of EuroPLoP 2024 in the coming weeks. However, I prefer these versions because the font and layout make them much more readable. (It is beyond me how anyone can read the ACM format.)

Patterns for Highly Autonomous Teams & Team Energy Theory Read More »

Help – a survey about product leaders

Agile / /

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

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

Help – a survey about product leaders Read More »

Fixing agile failure: collaboration over micro-management

Agile, Management / / / , ,

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.

Fixing agile failure: collaboration over micro-management Read More »

Comments, off, sorry

Agile / /

I’ve always enjoyed the comments people leave on this blog – even when people disagree.

Unfortunately, for the last few months the vast majority of comments I am receiving are spam – people trying to add links to their own websites and such. The same comments are made again and again, sometimes a dozen in a day.

So, with a heavy heart I’ve switched comments off for now. I’m happy to receive your comments, please e-mail me allan AT allankelly.net.

Of course, as I’m experimenting with Medium at the moment most of my content is appearing there and you can comment there. So please follow me over there.

Comments, off, sorry Read More »

Naked Objects and ACCU London January 2010

Agile / / / 1 Comment

I am very excited about the next ACCU London meeting when Dan Haywood will be speaking about Naked Objects. The meeting is open to all and is free, just check the ACCU website for details.

I’m excited about this talk because Naked Objects is one of the few technology based approaches to software development which I think holds real promise for better development. This is because the Naked Objects philosophy is based on a very different approach to most software development. Rather than view the end user as some kind of inconvenience Naked Objects treats them as a problem solver who wishes to solve something.

I read the original Naked Objects book by Richard Pawson and Robert Matthews a few years ago and the idea has been with me ever since (I reviewed the book in an earlier blog entry). Its the difference between treating users as adults and not children to my mind. Rather than the designers defining processes in the software they give users the tools to resolve the issues their customers raise. This approach respects the person using the software. It moves the conversation from business processes to customer service; and it fits far better with piecemeal growth over big-bang change.

Dan has just published a new book on Naked Object, Domain Driven Design Using Naked Objects and I’ve been lucky enough to have a sneak preview. This is the first technical book (i.e. one with lots of code) I’ve read for a while and I enjoyed it. So here is potted review… Dan sets out to explain the Naked Objects framework. Yes, Naked Objects is not just a philosophy it is the framework too. No need to invent the wheel, here it is; and it seems that framework has matured quite nicely.

He is passionate about his subject, I’m almost itching to download this stuff and start coding myself – arhh, if I could only prioritise coding for fun above the other things going on in my life. The writing is very clear and to the point with a little bit of humour. His instructions for getting the environment set up for the example code and case study is clear.

There are plenty of code samples and screen shots to illustrate what is going on which is nice but… On the downside the book is nearly 400 pages long which means it yo are unlikely to carry it around much. I read a PDF version so I didn’t suffer too much.

I sometimes seem to be the only person I know who has not read Eric Evan’s Domain Driven Design book. Initially I thought I might be at a disadvantage reading Dans book but he explained just enough to get me through. Indeed, I’m now intrigued and plan to get a copy of the DDD book.

Sometime ago I asked Steve Freeman “Whats all the fuss over domain driven design? What is it?” to which Steve said: “Its about doing objects correctly, the way we should have been doing them all along.”

Everything I’ve learned about domain driven design since then fits with Steve’s description. It seems to me that domain driven design and naked objects were made for one another so I’m glad to see Dan’s book.

Naked Objects and ACCU London January 2010 Read More »

Another month, another book -The Living Company

Agile / / / 1 Comment

Sitting on planes is boring, one of few advantages is that gives you a chance to read, and so it is that idea to read yet another book. This time the book is “The Living Company” by Arie de Geus – 1997, Nicholas Bealey Publishing.

This is a very good book, as one might expect from the title its thesis is that companies resemble living organisms. As a living thing the primary objective of the company is not to make profit but to survive. Profit therefore is not an end in itself but merely a means to an end, for without profit there firm cannot survive.

Arie de Geus is the author of a well-known Harvard business review article entitled “Planning As Learning” – if you have not read this it is well worth the $6.

As one might expect this book expands on this theme, the important point about planning is not produce a schedule that allow individuals to consider possible scenarios so that their thinking goes beyond a mere projection of the past.

Continuing on from this he argues that everyone affected by a decision should be involved in the making of the decision. On the face of this might appear to slow down decision-making process that is not the case. Because making a decision is only half the story, what is the key is made in the acting upon by involving more people in the decision-making process we ensure that action happens sooner.

It was only as I came towards the end of this book of the obvious occur to me. As regular readers of this blog will know I write Patterns, the originator of patterns, Christopher Alexander, calls on us to create patterns that live, in the same way Arie de Geus callers are those to create companies that live. To my mind there are obvious parallels here and further validate the use of patent theory when considering the business domain. Hopefully I’ll explore these parallels further in future patterns that are.

Another month, another book -The Living Company Read More »