Business

One big idea over many small ideas

Management, Product, Strategy / /

I so often wish I’d written “23 Improvements to make your agile life better”, or “30 ways to improve your business”, or maybe just “12 ways to become a better product manager.” Such books sell. Mine… umm, they are more, shall I say, philosophical.

While my books sell they don’t sell in the numbers “point solution” books do. My one book which comes close, “Little Book of User Stories” (“16 ways to make your User Stories great” ?) is the book I least respect. (OK, I’m not happy with “Art of Agile Product Ownership” either but that is for different reasons.) If I’d styled “Business Patterns for Software Developers” as “35 Business Strategies for Product Companies” it would have sold better but there was a bigger point I was trying to make.

And that is the thing, and its not just books, its all over. Understandably people want short snappy solutions, yet that approach quickly runs out of road. Bigger, more thoughtful, changes maybe more trouble but they also bring more benefit and last.

In our fast changing, chaotic, always on media, constant stream of WhatsApps, Instant Messages, e-mails and notifications we need to respond in the large not the small. For me that means “philosophy”. Well, I say philosophy, others would say principles. I avoid principle because I think principles need to be explicitly and enumerated. I’m probably wrong there, I hold myself to too high a standard.

Some might call it strategy but I find the word strategy is over used, too often equated with a plan. My strategy is to have philosophy, principles and embrace reflection – like writing this blog. Reflecting is a sense making exercise which allows strategy and principles to emerge and then refined.

When being inundated with notification and updates, when people are constantly looking for decisions and one is constantly challenged to interpret new information having an overarching philosophy, strategy, set of principles, provides a filter which simplifies and guide action. For example…

I long ago came to my own conclusions about the current occupant of the White House. That means that I don’t need to follow each soap-opera instalment. Yes it may shock me, disgust me, it might make the world more difficult but why waste my time on every twist and turn? They are all part of a bigger pattern, no more thinking required.

Of course one can’t afford to switch off completely. One needs to periodically step back and think.

So, second example, my current team/product. Unsurprisingly, I have set OKRs for this quarter. I had a big think. I consulted. I involved others. I shared. I refined. For the last two months these have guided all my decision making – specifically when it comes to sprint planning and the historic backlog. Now its time to think about the next quarter.

The paradox is: in a world were information flows are constant, where change lurks around every corner and disruptions the norm – what some call VUCA or TUNA – then those bigger decisions and your philosophy is more important. The churn of events and news means there is less less time available to think but that thinking is essential.

If I was to call out some of my philosophy as principle they might be:

  • Thinking ahead is essential, but the more detailed a plan the more likely it will fall. Therefore don’t invest too much in detailed planning.
  • Have consistency in direction: have a broader goal and make all the small decisions fit with the bigger goal as you go along.
  • “Nothing succeeds like success” : savour small wins, sometimes you need success before you can change direction but success is the enemy of change, failure is a great motivator.
  • Beware false goals: whether they be plans, processes, success criteria, or whatever. All too often the proxy becomes the goal rather than the real thing (I sometimes think that might be the unifying message in all my work.)
  • Sometimes the devil is in the detail: once you have your direction and philosophy you need to work the detail.
  • “It is always a people problem” but people act the way they do because of the system they are in and their past experiences. Sometimes you can lead people in different direction but if the system doesn’t agree the system will win.
  • The receiver decides the message you are sending: don’t assume people heard what you thought you were saying. Don’t be scared to over communicate but also know when to stop and listen. Only by listening can you find out what message was received.

I might continue but this is starting to sound like a personal manifesto – many of these have been talked about in earlier post. What I really want to say is: think, make sense of the world you are in and use those ideas in your decision making. Seek out good, reliable sources of information, ones which make you think, value such over the constant stream of trivia and hype.

One big idea over many small ideas Read More »

My regrets and why I’m rethinking Product Managers

Agile, Management, Product / /
Young business owner woman prepare parcel box and standing check online orders for deliver to customer on tablet, laptop Shopping Online concept.

Regrets? I’ve had a few, particularly when it comes to books. Take Business Patterns for Software Developers, perhaps the book I’m proudest off, certainly the book which was hardest and longest to write.

While I’m very proud of the book I regret the name. I remember several conversations with my editor about what to call the book. Even back then I knew it wasn’t the right title. Now it is easy to see: it should have been titled: Strategy Patterns for Software Products.

Or consider Continuous Digital, this masterpiece sets out my philosophy more than any other book – which might be why it didn’t sell! This book was ahead of its time; not infrequently I’m gripped by an idea and think “I must write about this…” Sometimes it is only as I start to write the words I think “Haven’t I written this before…” and there it is in Continuous Digital.

Continuous Digital is packed full of ideas, whether it is Time-Value Profiles, the value of nothing, deadlines over dates, diseconomies of scale, software as an asset, and purpose – all ideas which could be books themselves (and I really want to write a book all about purpose.)

Or consider the my advice on teams: Amoeba teams, minimally viable teams, Conway’s law, value seeking teams, team life cycle and more. If you know what you are looking at you can see what went on to become Team Topologies. About the time I was writing “CD” I worked on a project with Matt Skelton and we had long conversations about teams.

But the thing I regret most: Product model.

CD is cut through with discussion of products, I never say “the product model” but that is essential what I’m talking about. Today, when talk of “the product model” is common it is easy to I’m arguing for a product model way of working. I even though that at the time but I never call it “the product model.”

While CD and Project Myopia tried explain why projects were not a good idea and what to do instead they both avoided the topic of Project Managers, and if you focus on products not projects what do you do about Project Managers, who replaces them?

I’ve long considered many project manager role to be junior managers, the first step on the management ladder. Many project managers would be better thought of as work managers. Many project manager roles are now replaced by Delivery Managers. This does come closer to Work Manager role so it is a way of keeping some of the role without the project bit.

It is too simplistic to say Product Managers are the replacement because Product Manage is too different role. Now, 10 years later I’m starting to think that obvious answer might be the right one. But the Product Managers I’m seeing are not the Silicon Valley style “market fit” one. When I was first a Product Manager I probably saw that model as the right model but now I don’t. It is one version of Product Manager. I regret not seeing this sooner.

The Product Manager I’ve been in the last few years carries a lot more strategy than most Silicon Valley PMs. I spend a lot of time thinking about how to product will improve and where I want to take it. (This also differentiate the role from the misnamed Product Owner role which is usually (and wrongly) a lesser Product Manager.)

I promise to write more about the way I’m seeing the Product Manager role these days and why as it becomes more widely used it looses its original, and ultimate, feedback loop: money.

My regrets and why I’m rethinking Product Managers Read More »

Rational irrationality and anarchy in the workplace

Agile, Management / / / , ,

This is not the post I intended to open 2026. In recent weeks several threads have come together to challenge my thinking and I feel compelled to share with my readers. So, a slightly long and philosophical start to the new year!

Garbage can

A while back I read Amethodical systems development (Truex, Baskerville and Travis, 2000), it has stayed with me and has been a major influence on my reasoning about software. The authors argue that every development, contains unique aspects and is not replicable. However, by focusing on “a method” engineering has elevated the processes used to a privileged position and neglected what actually happens. To some degree the emergence of methods based on experience (e.g.XP) in the years after the paper addressed some of this concern but not all. It also means that Scrum, XP, PRINCE2, SSADM, SAFe – or any other brand names method – overlook many important factors. (Hence why I always describe Xanpan as a model of what you can create yourself.)

Rational irrationality

For a few years now I’ve been meaning to write a blog about Rational Irrationality. This is a phenomenon I’ve seen again and again inside corporate environments. In a nutshell this is interplay of rational processes which combine to produce irrational systems. Rational processes and systems are put in place with the best intentions but once you have a few, independently rational, processes in place the interaction of these becomes irrational.

Perhaps the simplest example I remember was a Senior BA who refused to let his analysts look at user requests until the Technical Architects had proposed a design. He reasoned that his BAs were stretched, many user request never went anywhere so until the Architects had given it their backing he wasn’t going to allocate any BA time. Meanwhile, the Lead Technical Architect, quite rationally, didn’t want his people designing systems which hadn’t been scoped, how could the design something if they didn’t know what it was? Both were acting rationally but the result was irrational.

The two times were irrational rationality seems to peak are around project inception and kick-off, then when moving to live production environments, however they everywhere. Perhaps the problem is not with irrational processes and corporations but with me – and maybe you. The problem could be less these systems but our engineering brains which expect there to be a rational, systematic, logical, way through this problem.

Just because my brain can see these systems interlocking, connecting, blocking and deadlocking doesn’t mean others do. Perhaps it is because I’m an engineer, or perhaps because I’m dyslexic and visualise, I can see these things like machines and gears in my brain, the same way I used to imagine code working.

Garbage Can Model

I revisited these ideas a few months ago when I discovered The Garbage Can Model – I must think Mark Smalley and his book AI and the Being Between Us.

The garbage can model goes a long way to explaining rational irrationality and how it comes about: despite what an organization says, and despite artefacts like org charts, the organization is anarchy. Attempts to control it as a rational thing don’t work.

Now I think back to my experience, organized anarchy is probably a better mental model than rational entity in many places. The interplay of all those rational processes creates irrationality and disconnects people. The more people try to join up work the harder it gets, too many connections, Declare independence and you are seen as disruptive and “not team players”, the corporate anti-bodies come out.

The garbage can holds a collection of problems. These may get resolved, delayed or subsumed into something else. These problems are complicated by fluid engagement from stakeholders (they only sometimes join meetings), unclear technology and problematic preferences.

There are solutions too, although not necessarily solutions to the problems in the garbage can. These solutions are products, perhaps backed by vendors but not necessarily so. These solutions are looking for problems they can be applied to. Once in a while decision opportunities arise – IME typically when money needs allocating or a deadline hits. Still, delaying a decision means problems remain.

What ideals are lying around?

The economist Milton Friedman once said: “Only a crisis—actual or perceived—produces real change. When that crisis occurs, the actions that are taken depend on the ideas that are lying around. That, I believe, is our basic function: to develop alternatives to existing policies, to keep them alive and available until the politically impossible becomes politically inevitable.”

Friedman is arguing for the creation of products (policy alternatives) which then wait until a decision point. Friedman is telling us how to work in the garbage can, whether economics, systems development, or geo-politics.

From a amethodoical view engineers are trying to create rational solutions and processes while others are biding their time until their product/solution can have its day.

Fake it

Of course, when we look back and try to explain it – or when someone says “Can you do the same for me?” – we rationalise it. We don’t admit it was a garbage can or lacked method, that some stakeholders never turned up or decisions were delayed until they became irrelevant. We explain it as if it was meant to be, or as Dave Parnas put it “A rational design process: How and why to fake it.”

After all, who would admit their process was amethodical and wasn’t the result of apply career enhancing frameworks? Or that their decision making was little more than a garbage can that only produced decisions when crisis hit?

Now, when someone believes their organisation is rational, maybe they think it follows SAFe, or maybe they the hierarchy works, they treat it like such. But their mental model does not reflect the reality. Consequently the system doesn’t respond as they expect, even if it isn’t anarchy it looks like it.

So what good is this?

I would like to think that I will stop looking for engineering solutions. That I will accept more of the rational irrationality in corporations. That I will practicing patience.

I think it is more likely that simply knowing my engineering brain is wrong to expect a well oiled machine I will be more tolerant. At the very least, I will tell myself to tolerate more. Still, I will endeavour to make my bit of the world a little better, and a little more rationale. Perhaps knowing the world is irrational will help me be rationale.

Signup for the my latest posts by e-mail and download a free book

Rational irrationality and anarchy in the workplace Read More »

Agile: not Dead, but evolving

Agile, Agile Process, Management / /

Sorry. I’ve deliberately avoiding the click-bait “Agile is Dead” topic, until now.

For the last few years I’ve delivered a lecture on Agile to Oxford University students and this year the tutor specifically asked me to say something about the state of agile. When I looked over last years slides I see I was already talking about this. I’ll write more about this soon, if you can’t wait checkout “Xanpan 2021” from Frug’Agile en Arménie.

So, is Agile Dead?

Clearly not. (Albeit agile mania probably is.)

Agile is all around us. Teams work in sprints, hold daily “stand up” meetings, tools like Jira continue to sell, requirements documents are full of user stories, business journals regularly talk about “agile” and “agility” without any reference to software.

That doesn’t mean the result is perfect. The “agile” which prevails today falls short of what I and others in the community dreamed. As I’ve said before, Agile won the war but lost the peace.

Right now, agile isn’t getting attention because AI is. AI is soaking up all the discretionally time and budget so agile is squeezed out. Ironically, to get the most from AI you need the learning processes embedded in Agile to find better ways. Right now we don’t now the best way to use AI. We are in a vast experimental phase and we need more of the learning and feedback in agile.

Back to the question, is Agile Dead?

The common agile that prevails is a watered down, corporately acceptable version that is still a lot better that went before.

But then, most people don’t remember before agile. The Big Up Front practices which gave massive requirements and functional specifications; the defined process and ISO-9000 process audits, the guilt of “not doing it properly” and the inability of those doing the work to influence how it was done.

While many of those problems have resurfaced under other names in the agile world things are still a lot better. If we had stayed with that approach there would be no automatic updates to the apps on your phone, no digital business, nor much of the other technology that surrounds us. Maybe Apple and Google would be OK but legacy banks, airlines, telecos and Governments would be even worse than they are now and a million start-ups would never have started.

In truth, many of the “waterfall” processes were never followed. I worked on exactly one project that did it by the book, Railtrack Aplan. Officially it was a success, it went live. But what went live was a shadow of what was supposed to be delivered.

Everywhere else did something that (kind of) worked and then felt guilty for not doing “properly”. When I was at Reuters they tried to force us to work by the book, they destroyed much of their own capability in the process.

What has agile ever given us?

Agile showed there was another way and added democracy by opening the debate on “how we work”. The Internet help agile spread and opened up the debate in a way that had never been possible before.

If nothing else Agile gave us a better reference model, a better way of describing our work.

Actually, it gave us several reference models, Scrum, XP, DSDM, etc. Always, and everywhere, people adapt, when processes work they use them, when defined process don’t work they work around them. For a while agile licensed that working around, experiments were everywhere.

Agile was not so much new in itself as a new combination of ideas which were lying around.

The engineering practices in XP descend from the 1970s quality movement based on the work by Phil Crosby and W.Edwards Deming.

The self-organizing teams in Scrum drew on the sociotechnical systems. First recognised in the 1940s and 1950s by the Eric Trisk – then at P&G and Topeka and the genesis of Senge’s organizational learning.

The inspect and adapt philosophy in Tom Gilb’s Evo and then Scrum comes from Stafford Beer and management cybernetics.

Lean thinking draws on many of these ideas directly but lean also begat its own software process in Kanban.

As for the Frankenstein’s monster that is SAFe… you can decide for yourself whether SAFe is agile but it is definitely not lightweight. Because of its size alone it is hard to adapt SAFe and involve the workers.

The return of Agile?

Can we expect Agile to return to its previous permanence? Will the day come when everyone wants to hire a Scrum master? No.

That has passed. Organisations have ticked the Agile box – if only because they have moved on to AI. The days of big agile transformations are largely over because companies have declared success.

Put it another way: Management fads don’t return.

Imperfect agile is here, hopefully enough of it has been adopted that companies will continue to improve.

More importantly, those ideas underlying agile – quality, sociotechnical, cybernetics, learning – are still valid and will continue to have influence. Some companies will embrace them and get a lot from them, some will continue to reject and most will dip-in-and-out. These ideas will return, albeit in a different package and with a different name.

But none of that means agile is dead. Agile mania might be over but agile is continuing to evolve out of sight. Agile wasn’t the first coming of these ideas and it won’t be the last. Next post I’ll talk more about how I see it evolving.

Signup for the my latest posts by e-mail and download a free book

Thanks to Fritz Geller-Grimm for the parrot picture under CC license

Agile: not Dead, but evolving Read More »

What I’ve been getting wrong about PDCA

Agile, Agile Process, Continuous, Management / /

I’ve been teaching planning lately and once again it seems to me that the PDCA cycle – aka Shewhart or Deming cycle – is pretty much the core of all planning. Or rather, it is the basis for all mutli-pass planning – when iteration is allowed. (One-pass planning, big-up-front-design “BUFD”, is fine for trivial situations but alway has problems in complex situations.)

So, again I’m reminded of why I don’t like PDCA. Two reasons.

Adjust over Act

When the fourth step is labeled “Act” it fails to speak to me. “Act?” I ask, “Didn’t we just DO?” Easily fixed, label step-4 “Adjust” – many people do. Now it says, “Plan a bit, do a bit, check the results, now adjust the plan or the way you are working.” That makes more sense to me.

4 unequal steps

Secondly, the typical presentation – like my diagram above – makes it look like the four steps are equal and that is not the case. Just in terms of the time they take the fourth is almost always the shortest. Which of the other steps dominate is going to depend both on the planning culture where you are and the amount of work that needs doing.

Many places will put a lot of time and effort into planning. While this can entirely justified if you are building something that lives depend on, planning suffers from diminishing returns. It is often far better to plan a little, run around the circle and plan some more. Planning is learning but so is doing, you can learn more by a few minutes of doing than hours of planning.

Other places will skip planning altogether and launch into doing. While over-planning is problematic jumping straight in is also a problem. Either way, in terms of the PDCA cycle, planning is not an equal element.

Now when planning is skipped or rush the doing phase is going to expand. In fact, on a really big endeavour which needs a lot of planning the doing phase can also be very large. Of course, its entirely possible that your planning is so excellent that you see an quick way to deliver. But again, doing is not an equal quarter.

Test-fix-test-fix-test doom loop

The same does for the check (or test) phase. It can be long or short. If your planning was good, and your doing was quality then you can hope that the check phase is really small. It does happen. But too often there is little quality in planning so you actually end-up with a short-circuit as the checks fail and more doing is needed to fix things. (This is the test-fix-test cycle that can destroy any schedule.)

I wouldn’t expect Plan, Do and Check to be equal sizes, depending on your organisation, culture and the nature of the thing you are doing I would expect one to dominate.

But I don’t see that in Adjust. Adjust is the forgotten child. Indeed, in many projects, especially at the end, everything just goes hell for leather do-check-do-check-…. Adjust, and even planning, goes out the window.

Using PDCA successfully

Even in the best places Adjust is always going to be the shortest of the four. The irony is that it is probably the most important. It is the step where reflection and improvement happen.

The truth is I’ve always struggled to apply the PDCA cycle formally. But when I look back at almost every single engagement the actual work can be mapped to the PDCA. It is fundamental, whether building product, running sprints, setting and executing OKRs or almost any other non-trivial work. Its just that the steps are not equally time consuming or equally respected.

And the secret to making it work well? Simple, go around fast. A little planning, a little doing, quick check, small adjustments and go again. Learn in the planning, learn in the doing, learn all the way round and put that learning into action.

What I’ve been getting wrong about PDCA Read More »

Patterns for building a learning organization

Management / /

The question is: “What do companies who learn actually do to learn?“

Yes, we all know about retrospectives but there is a lot more too it than that. This was the question Tsvetelina Plummer and I set out to answer in what became our paper to EuroPLoP this year: “Learning to learn: patterns for building the learning organisation”

While we know this isn’t a complete answer – there is more work to do – I’m immensely proud of the patterns here. We put a lot of effort in before the conference, first by ourselves and then with MaryLynn Manns as our shepherd. And in the last few weeks a lot more effort to incorporate the workshop comments and get the paper ready for the proceedings.

So here is the paper, we’d love to know what you think.

Even better, if you have example of what you and your company do, a case study, an activity, anything really, then please please please get in touch and tell us about it.

The official version will appear in a few months in the conference proceedings by Springer Nature but only the formatting changes really (and this version is better.)

Patterns for building a learning organization Read More »

4 quick fixes to bring order out of choas

Agile Process, Management / /

I have been working with a coach recently to think about what I do. Odd as it might sound I have real trouble articulating what I do. This is particularly true when I’m employed to work on team performance and processes. In my mind I turn up, I talk to people and they then makes things better. Can I take the credit for that?

One of the reoccurring comments I get from clients is that I bring order from chaos. While I’m immensely proud of that it is a hard sell when trying to articulate the value companies can get from hiring me. That is because it implies you already have chaos, and who wants to admit that?

Whether chaos or not I’ve been running over my past engagements and a few things stand out. These are things that I have repeatedly done with teams, things which have made work better (and therefore more productive, efficient and fulfilling.)

Most of these suggestions are quick fixes: you can introduce them pretty quickly and see results. But they do not detract from long term improvement. Even if you have time these are a good place to start.

Triage processes

These come in various shapes and sizes. Typically this means appointing one or two people to quickly review work requests and decide if they need immediate action, can wait a little while or be pushed back.

In one case this mean that all urgent support requests or bug fixes were added to the teams work board in a special column. A few minutes before the daily “stand-up” the Product Owner and Team Lead would review these and decide if it was immediate action, push-back or hold for the next regular planning meeting.

(In the most urgent cases work might begin as soon as the request was made but that decision was reviewed just before the stand-up the next day.)

In another case I convened a weekly meeting to review all the urgent work requests which had some in in the last week (mostly things people called bugs.) Collectively we would agree the prioritisation (1, 2, … 5) and then, for just the priority 1s list them in priority order. Unless the customer service manager and myself (as Development Manager) agreed something new became more important during the week we stuck to this order.

There are plenty of other examples I can give but you get the idea. These triage processes work wonders at controlling task switching, confused priorities, decibel management and other sins. Consequently they boost productivity, work order and satisfaction.

Sacrifice one

Hand-in-hand with triage I often sacrifice one team member to urgent but unplanned work: bug reports, customer service requests, and so on. Even on a team of 3 or 4 having one person designated at the urgent work or fixer can payback both in addressing issues and allowing others to work uninterrupted. This designated person isn’t assigned to any other work, or at least nothing time critical.

There are a few engineer who relish this role and love nothing more than a stream of “small fixes.” Most engineers would rather work on bigger items and stick with them for a few days. So unless you are blessed with one of these people rotate the role between team members.

Routines

I’ve no claim to originality here, this is 101 in the agile processes playbook. Still it is effective. Choose the routines and ceremonies that make sense for your team: daily stand-up, regular planning/replenishment (I prefer weekly, most teams do it fortnightly, just please avoid 3-week sprints), retrospectives (not necessarily every iteration, perhaps monthly, at least quarterly) and regular releases. I’d love to work with a high performing team who do many releases a day but the only time I’ve seen teams doing such is with bug fixes. Again, weekly, fortnightly, monthly, these can all bring more structure than you have now.

And of course, if you are using OKRs create a cadence and put the dates in your calendar.

Create focus

Taken together those three suggestions: triage, sacrifice and routines all aim to create more team focus. Focus is one of the most powerful tools you can use. These three changes start to create focus.

Beyond them there is so much more that can be done to create focus: backlog structuring and prioritisation, OKRs, testing approaches, various graphs and measurements, …

Statistical forecasting

Even if a team is making effort estimates – in time, story points, tea bags or whatever – start collecting data. Actually, since most teams these days are using electronic tracking systems you probably have an archive of data which you can mine today.

Go and analyse the data.

How many “stories” do you do a week?

What is the cycle time for a story? What is the average? The longest? The shortest?

What is the average time a story spends in the backlog?

How many things are in flight at the same time?

What is the bug count? And what direction is it going in?

What is the team “velocity” ? More importantly, what is the backlog growth rate?

There are many more question you can ask your data. Not infrequently you find that the data you have is not good enough to answer these questions but that itself is information.

When you start to answer these questions you can start to forecast based on data not guesswork.

And by the way: I’m more than happy to help you analyse your data, just get in touch and we can work something out.

Quality

So far all my suggestions can be done relatively quickly. The next one is a longer burn: improve quality.

When you quality is low a defect – a bug – can raise a hand at any time and create chaos: disrupt a release, distract and engineer, panic a customer, etc. etc, Defects can be high profile, very disruptive and difficult to close. Defects can destroy any schedule or plan no matter how carefully constructed.

The solution is simple: improve initial quality.

To do this install test-first working, code reviews, frequent customer review, shorten feedback cycles, etc. The catch is these can take a little time before they pay back.

Two I haven’t mentioned

Now there are two things I haven’t mentioned so far and will have some readers wondering why I haven’t: reduce work-in-progress and introduce outcome oriented working.

Reducing WIP can have wonderful effects but explicitly reducing WIP requires authority or credibility – and usually the credibility is required to persuade someone with authority. Introducing triage, sacrifice and routines will have the effect of reducing WIP but without the overhead of persuading people that “doing less produces more”.

So I only target WIP directly once I have picked some other low-hanging fruit. Plus, having the data to back up my case will really help. Attempts to reduce WIP usually start with a screening of Stockless Production.

Similarly, outcome driven working requires a certain credibility and trust to pull off. So often people are just drowning in work which OBVIOUSLY NEEDS DOING. Even if the engineers aren’t then there are plenty of other people saying “Just F…ing do it!” So asking people to take a step back and think about the desired outcome can be hard. Better build up some credibility first.

That is my list, what would you suggest I add to it?

And if you would like to discuss these ideas further please let me know.

4 quick fixes to bring order out of choas Read More »

Are Product Owners set up to fail?

Agile, Management, Scrum / /
Product Owner choosing postits

I’ve long seen two big problems with Product Owners.

First, Product Owners don’t talk to customers as often as they should.

Second, the Product Owner role is frequently set up to be little more than a Backlog Administrator.

Now these two problems aren’t completely unrelated. If you are simply a Backlog Administrator what is the point of talking to customers?

For a while now I’ve taken a broad interpretation of the Product Owner role. Yes, it was introduced by Scrum, and Scrum defines a very powerful Product Owner (which I agree with). But, the Product Owner role has become a general term for “the one who should decides what needs doing next.” Simultaneously the role has become undermined and very few Product Owners seem to have the power to decide much more than the next couple of items.

The Product Owner role seems to make Product Managers and Business Analysts nervous. It shouldn’t, both Product Managers and Business Analysts are types of Product Owner. After all, while the Scrum definition calls for a powerful PO it says little about how the Product Owner knows what they need to know to make decisions. In my book – and yes, I cover this in Art of Agile Product Ownership – that knowledge usually comes from being a Product Manager or Business Analyst.

Recently I’ve been taking talking to my subscriber base and the issue of Product Owner comes up again and again. While nobody thinks Product Owners should be Backlog Administrators most Product Owners in the wild are just that, Backlog Administrators.

In some cases people think it is because of their situation. “In the public sector Product Owners are not honoured…”, “In Germany, Product Owners are not valued”, “In the outsourced development market the contract ties the PO’s hands.”

Actually, its everywhere. Product Ownership are failing everywhere.

In many cases I’ve seen Product Owners who are “battlefield promotions”. A coder is picked to be Product Owner on the grounds that Scrum demands a product owner and they are “The best coder” (or perhaps the worst), “they understand the system”, “its a technology project” or some other weak criteria. Real power continues to be vested elsewhere.

In other cases the Product Owner comes from “the business side” and has little understanding of the technology, how technology teams work or what is expected of them. Consequently the technology group run circles round the Product Owner.

There is a reoccurring tendency for Product Owners to become the Product Dogsbody and pick up the things that nobody else wants to do. Other times the Product Owner is seen as the team leader by those outside the team, however they hold little real sway inside the team (because they are a Dogsbody, Backlog Administrator, coder who is acting up or new to technology).

But the thing is: we can’t blame the Product Owner for any of this. They have been set up to fail by people who don’t understand or respect the Product Owner role, real power is withheld from the PO. Possibly because giving the PO power can seem like reducing ones own power.

As a result the role as an operational necessity (because Scrum or SAFe say there should be one) rather than the Strategic Role which is should be.

Perhaps one mistake I’m making here is: using the term Product Owner. Perhaps it is too connected with Scrum, and in the same way that Scrum has been devalued maybe Product Owner has too.

So, how do we fix this?

I’m not sure. Perhaps we should dump the title Product Owner, maybe everyone should use Product Manager – although that title too is misunderstood. Product Leader could be an option but I’ve also heard complains about that. Product Expert? Product Analyst? Product Person? – would any other name help?

In the past I’ve run a Strategic Product Owner workshop which aims to give POs the skills to operate more strategically. But for this to happen someone at a more senior level has to ask for the workshop and ask POs to be more strategic.

One option, is for Product Owners to meet customers. This will both inform their decision making and give them the legitimacy that comes from customer contact.

A brave PO can simply start thinking and acting more strategically, they can put themselves in the driving seat and start making decisions. While I think this would often work it requires a brave person who is willing to risk their job. (And please, meet some customers before you grab the controls!)

Ultimately the good, knowledgable, powerful, product people are key to achieving agility, failure to give such leaders power puts limits on success.

Subscribe to be the first to hear of new posts

Plus download Continuous Digital for free get occasional discounts and gifts

Are Product Owners set up to fail? Read More »

Agility over agile, more than word play

Agile, Business / / /

Is it just me or is the world moving away from agile and towards agility?

That may sound like a silly question. I’m prepared to admit it come as much from what I want to happen as to what is happening. Perhaps it is confirmation bias, but it feels like there is a change in the air. It’s a change I’m all for – I was talking about the need for agility over agile over 10 years ago (Objective Agility).

It might seem like a small semantic change to go from “agile” to “agility” but it is a change from “doing agile” to “having agility.” It is a move from “means” to the “end”. From “the way of doing things” to the “outcome.” Rather than emphasis “the way people work” the emphasis is “what is the end result?”

That is a good thing. By definition agile methods, and agile frameworks (Scrum, SAFe, Kanban, even Xanpan) describe how to work. There is an assumption that if one works that way one will achieve agility. In reality there are many different routes to agility. Some look like Scrum, some like Kanban, others don’t. Some people find their own way to agility.

I always introduce agile by asking: “What do you want agile to do for you?” The agile toolkit can be used for many ends.

With agility the answers are pre-defined: agility is both ability to move fast but also the ability change direction and manoeuvre with haste. In order to do that information is needed (learning), and that information needs to be acted on (decision making) – feedback loops again. Maximising agility means pushing that learning and decision making down to the lowest level: giving the people who do the work authority and trusting them. This is where digital tools come in and is why digital transformation demand agility.

Agile Beyond Software

There are two forces driving this change. First off is the expansion of agile beyond software development and into many other fields. As I’ve said before: digital tools spread the agile virus.

As other fields – marketing, law, research, and more – adopt methods which were originally for software engineering some tools need changing. Sure, some tools work just the same – think daily stand-up meetings. Others need rethinking: test first thinking needs a little work when testing is not the norm. And some don’t work at all: Unit testing.

A couple of years ago I saw Scrum forced on people not in software. These people did not always work in teams, they time sliced between different activities and who had to handle a lot of unplanned, urgent, work. The emphasis was on “doing agile” rather than “being agile”. Despite some valiant work it was a mess.

As we apply agile thinking away from software we need to emphasise the outcome rather than the method.

Business Agility demands more

Second, talking about agility, and in particular business agility, puts the emphasis on the whole – the wider context. That is to say: you can have the most agile team ever but the wider organization can stunt agility. The wider organization also needs to hear customers and adjust efforts: budgets, portfolio, governance and other teams also need to work agile so the whole enterprise can have agility.

Summary

Yes: agility over agile might be semantics but it is an opportunity to change the emphasis:

  1. Prioritise outcomes over methods
  2. Seeking agility outside of technologists means embracing more variation in how teams work
  3. It is not enough for teams to be agile, the wider enterprise needs to challenge how it works

Finally, agility is not binary. One might work agile or might not work agile, but agility is measured on a scale. How much agility does your company have? – it might be zero, it might be 10, it can always go higher.

Agility over agile, more than word play Read More »

Software has diseconomies of scale – not economies of scale

Agile, Management / / / , ,

“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 Milk
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:

Collage of milk prices
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.

Software has diseconomies of scale – not economies of scale Read More »