Agile

Winners and looses when AIs program

Agile / / / ,

I feel guilty, the rest of the world has gone AI mad and I’ve said nothing about it. I’ve been hiding. Part of me feels sad and threatened, is AI going to wipe out the world I knew?

So here is my take. Since I come from a programming background, and since this is where a lot of the AI opportunities are supposed to be I’m going to talk about this. To those of you from elsewhere, let me ask: can you apply my logic to your world?

We’ve been here before, once upon a time code generators were gong to replace programmers, another time it was “programming in pictures”, another time it was 4GLs. Is this time different?

The term “AI” has been applied over the last 20 years to many systems which are little more than rules engines. These may not require programming but they do require configuration. Configuration which can be complicated – more than selecting Preferences/Edit/… and click. Instructing computer how to work, whatever the metaphor, is called programming. Anyone who says “With this tool I replace the programmers” just become a programmers themselves.

Many of those code generators, and programming by clicking systems replace one set of problems with another set.

A thought experiment

So, a thought experiment: lets suppose AI can write code as good as a human. Your programmers are replaced. What happens then?

First: do you trust what the AI writes? Or do you still need testers?

There have always been companies out there who forego testers and testing, undoubtedly many will. But in general you will want to test what the AI creates. Just because an AI says 2+2=5 does not make it right. There are already documented cases of AI exhibiting biases in things like identifying criminals.

In fact you probably need more testers for two reasons: programmers used to do some testing, while AI will not make silly syntax errors it will still make logic errors. Additionally if AIs writes more code faster than before there is simply more work in need of testing.

Second: how do you actually know what you want? – many programmers and testers spend most of their time actually understanding what customers want. Think: when you use travel planning software you may reject the first suggestion because it uses buses not trains, the second because there is too much walking, the third because you prefer connecting at one station over the other.

If the programmers are gone then testers might take on that work as part of testing (trial and error cycles). Or you might turn to Business Analysts and Product Managers. There are the specialists who understand what is wanted.

BAs and Product Managers have another role to play: post evaluation. Now it is cheaper to produce solutions there will be more solutions and someone needs to see whether they actually solve the problem you set out to solve.

In fact, there is more work to do in choosing the problems to solve in the first place. After all, building and deploying a new system is only part of the problem. What about training people to use it? What about changing the processes around it?

In fact, if we are introducing more technology and solutions faster than we are going to need more change managers analysts and consultants to advise on workflow improvements. One day your entire company may be machines working seamlessly together but until then you need to accommodate the people. Which means someone, be they BA or consultant, needs to look again at the workflow.

And if we know anything from the agile and digital movement of the last 20 years it is that changing our approach to work takes time. The technology is the easy bit. It takes years, decades even, for processes to change.

While there are still humans in the system there will still be interfaces which will need designing. Interface, UXD or experience design, is not an entirely logical processes. You need to look at how people respond. With more systems you have more interfaces and more need of interface designers.

And because adding features to your product is now so cheap you suddenly have an explosion of extra features which makes the interface more complicated and may even detract from your product value – remember how the iPod won out over other, more feature rich, competitors? So now you need you analysts and designers to limit the features you add and ensure those you do are usable.

So far we have removed programmers but increased the number of Testers, BAs, Product Manager and Designers.

In one form or another all these people will be telling the AI what to do, as I said this is call programming. So many of those new hires will be doing some form of programming. The programming paradigm has changed, perhaps its more high level, but it is still there.

If AI follows the pattern of past technology change (and why shouldn’t it?) then:

The full benefits of technology are not realised until the rest of the system, particularly processes, change to take advantage of the technology. This can take decades.

Programming isn’t going away

New technology is often billed as replacing previous technology and/or workers. It might do that in time but it also expands the market. Electricity did not eliminate candles, more candles are produced today than ever before but we don’t use them for lighting (so much.)

I don’t see AI programming bots replacing programmers in many detailed roles, perhaps ever. The ins and out of something like Modbus, and at the other extreme enterprise architecture, will make that hard. But there are domains were AI will dominate.

Finally, as we adopt new technology and processes we give rise to new innovations, we find new markets we can address and new ways of addressing existing problems. That generates work and new roles.

So I am sad to think the joys of youth spent writing ‘Writeln(“Hello world.”)’ are coming to an end, and my children will probably never experience the joy of feeling a machine perform their wishes (LDA#0, JSR OSWord, anyone?) those days are already gone.

Rationally I know AI is not something to fear (at least in the jobs context) but emotions are not always rational.

Winners and looses when AIs program Read More »

What do you mean by “initiatives and OKRs”?

Agile / / /

A few weeks ago I had a conversation with a potential client about OKRs. They started talking about “initiatives.” In fact, they talked about “initiatives” as a standard part of OKRs, one of those moments when self-doubt set in. I started wondering “What do they mean?” And more worryingly, “How do I not know about initiatives?”

When I did some digging it turns out that one, or possibly more, OKR consultancies talk about “initiatives” as a third level of OKR. For these consultants there is a hierarchy, Objective at the top, Key results below that and then initiatives as the “things you will do to deliver the key results and therefore the objective.”

Umm, maybe

In one way, I like the thinking. I agree that “what we will do” is not part of the objective and it’s not the key results. (A common mistake with OKRs, one I made myself years back, is seeing them as the to-do list.) So I can see why they label the things to do as another level. At the same time, I see two problems.

First is the hierarchical decomposition. Again, the idea that an initiative builds towards one key result which builds towards one objective. Once you start viewing key results as acceptance criteria which describe the post-objective world, this breaks down – the key results become cross-cutting. If your key result is “Customer receives their order within 48 hours”, for an objective of “Satisfied customers”, there is probably not just one thing to do. That goal may cut across lots of other pieces of work.

Is an initiative big or small?

Second, and perhaps more importantly, the word “initiative” is already widely used and means different things to different people, creating a recipe for confusion.

Specifically, although the #NoProjects community never standardised on the word, it is widely used as an alternative to “project” to describe a stream of work, an endeavour, a mission, a programme, or an ongoing effort. So for many of us, an initiative is not a small piece of work sitting below key results, but rather a big stream of work sitting above objectives.

This also hints at the reason why “initiative” was never agreed on. For many of us “initiative” has overtones of “beginning” – indeed my Apple dictionary uses words like “originate”, “before” and “fresh” when defining “initiative.” (In Dungeons and Dragons players roll “initiative” at the start of a fight to see who goes first).

So what do you think? Am I too sensitive? Have I missed something critical? – let me know in the comments or drop me a mail.

Still, there is most definitely a need to decide what actions are needed to deliver OKRs. When and how to do that will be in future posts, stay tuned. In the meantime, if you use the word initiative make sure you clearly tell people what you mean by the work.

What do you mean by “initiatives and OKRs”? Read More »

Why does agile need OKRs?

Agile / /
Why does agile need OKRs?

The comment I get again and again about my presentations and workshops, OKRs and others, is “passionate.” And it is true, I’ve been passionate about this thing which gets called “agile” for over 15 years. Now I know “agile” has become a dirty word in some circles, all I can say is “That’s not my agile.” My agile is about engaging everyone, about engineers doing quality work, a more orderly and effective work environment. This type of agile creates benefits like meeting deadlines, satisfying customers, a more orderly work environment and ultimately happier workers and an improved return on investment.

When I stand in front of people and talk I’m talking to my former self, the coder I was 20 years ago who struggled with all the same problems engineers struggle with today: unclear requests, too much work, weak management and yes, technology frustration. That’s why I’m passionate.

So why do I get excited about OKRs? And why did I write a book about them? – especially odd when know I was originally an OKR skeptic.

Let me honest: I’m not really passionate about OKRs. I’m passionate about what they can do for agile and how they can help those doing the work. OKRs are more than a very useful tool to add to the agile toolkit. Sure it is a very useful tool but they also address problems in agile.

First off OKRs are big, not small. Agile works best in small – remember diseconomies of scale? – small teams, small stories, small releases, … this is great for effectiveness but it looses track of the big things. The outer Matroska. Well, OKRs give us a mechanism for thinking bigger.

Second, standard agile (e.g. Scrum, XP and even Kanban) has no widely accepted solution to mid-range planning. We used to talk about “release plans” but since the arrival of continuous delivery that doesn’t make sense. People struggle to produce mid-range plans that are accepted by others. OKRs can plug that hole.

These two issues intersect when it comes to backlogs, in particular Scrum Product backlogs. All those small things clog up a backlog and without some planning mechanism merely obscure the truth. Put simply, backlogs don’t scale. Backlogs are useful when we are thinking days in advance and counting product-backlog-items (PBIs) in single digits but they fail when they contain hundreds of PBIs and extend years into the future. Again, OKRs can help here.

Third, OKRs provide a framework for elevating the conversation to more senior leaders and executives. These people lack their own agile context, their time is scarce and they don’t want to be bothered with small things which last a few days. But without their involvement and affirmation teams lack “air cover” from above and struggle to escalate issues upwards.

Not only do OKRs provide a communication interface to the senior team but the same mechanism facilitates communication and co-ordination with other teams. Done right OKRs create an API for the team and can push more authority down to the teams furthering self-organization.

When teams set their own OKRs we create a powerful feedback mechanism, a strategy debugger. (Conversely, cascading OKRs down a hierarchy destroys their power and undoes many benefits of agile working.)

In other words: OKRs allow agile to grow up.

That in a nutshell is why I think why agile needs OKRs, and why I’ll be writing more about OKRs.

Why does agile need OKRs? Read More »

OKRs as a strategy debugger (& sandwich maker)

Agile / / / , ,

Intended strategy goes wrong in one of two ways. First: it is the wrong strategy. It might be badly conceived, it might aiming at the wrong target, it might be based on weak analysis or mis-understanding.

Or it might go wrong because it is poorly executed. Strategy execution begins as soon as strategy is decided on because it needs to be communicated. Bungle the strategy communication and you are unlikely to recover.

Indeed communication issues run all the way through strategy execution because the meaning of any message is decided not by the speaker but by the listener. The executive charged with explaining strategy might think it is clear but each received understands the message in their own context. Even if the executive uses clear language – and lets face it, many don’t – they have no way of knowing what the receiver takes away.

The only way to know if a message is received correctly is with feedback. Similarly, feedback is needed if bad strategy is to be exposed. The executives setting strategy may lack information which those on the ground have and which undermines strategy. Executives think the strategy is great but to everyone else, the emperor has no clothes.

In other words: Linus’ Law applies to business strategy as much as computer software: “given enough eyeballs, all bugs are shallow”. Exposing more people to a strategy allows more brain power anymore information to be applied. But those brains can only have an influence if there is some means of feedback.

This is where OKRs come in. OKRs make strategy visible.

Remember that in my formulation teams set their own OKRs. This is the first test. Leaders set out the organization purpose, missions, visions, grand goals and strategic intent then ask the teams: “how can you help?”

Teams respond by setting OKRs which will advance on those goals. OKRs, written in a standardised format, are feedback from the teams to the upper echelons.

In my model leaders and managers are stakeholders in teams. While teams, which may include managers, are as autonomous as possible they are not free to do what they like. They are part of a system and exist to deliver to stakeholders. As such I expect team OKRs to be reviewed by leadership and those leaders to provide feedback. This is a debugging loop.

1. Leadership sets the strategy and intent, then communicates it out.

2. Team members hear and formulate OKRs to deliver that strategy and intent as they understand it.

3. Leadership reviews OKRs and will expect to find OKRs which, well, support their intent.

This “OKR sandwich” is fits with the Strategy Rethink I’ve talked about before. The sandwich creates two opportunities for misalignment (bugs) to be exposed. First when the team sets the OKRs, they might find the strategic intent does not match their world. That might be a misunderstanding or it might be because team members have information leadership does not.

Second, when leadership reviews OKRs they have the opportunity to find bugs. Discrepancies found at this point might indicate communication has failed, or it might indicate the team have additional information.

To be clear: OKRs which don’t match expected strategy are not the cause of problems but a symptom. Noticing the discrepancy early means corrective action can be taken quickly. Yes the OKR needs, but so too does the cause of the discrepancy.

Even after the OKR setting and review process, during execution, OKRs continue to play a debugging role. It is at this point that the “rubber hits the road” for the first time. Thus it is necessary for executives to keep feedback channels open.

OKRs as a strategy debugger (& sandwich maker) Read More »

Connecting the dots – workflow, agile, OKRs, dyslexia and chaos!

Agile / / / , , ,
Connecting dots

One of my failings, or one of my strengths, is that I have lots of interests. I tend to default to systems thinking, I see wholes, I see connections, I see things tying together, I think holistically. I can’t always explain it, sometimes I dive into detail but generally thats the way my mind works. Perhaps its because I’m dyslexic.

That has its advantages – problems seldom occur in isolation – and I think its one of my assets, I think it gives me the upper hand in resolving things. More than one client has told me I “bring order out of chaos.” I’m proud of that and I think its one of my key selling points. The problem is the clients need to recognise chaos to start with which people don’t like doing.

And while everyone will agree that more “holistic” thinking is needed… holistic also has negative overtones to some people. It is, if I can say this, somewhat “hippieish”. That is to say, it is vague, unfocused, perhaps a little work-shy. In fact, I can get frustrated myself with people who always enlarge a problem and want to engage in analysis after analysis. I just want to get on with it!

Perhaps because I naturally see wholes I don’t feel the need for analysis like other people. I want to move straight to action!

My problem is: holistic doesn’t sell. In fact, what sells is specific, very specific. Every marketing textbook, every marketeer, and even me will tell you: “focus on one specific customer, one specific problem, make your offer match their need precisely.”

For example, my best selling books are Succeeding with OKRs in Agile and, before that, Little Book of User Stories, both very specific. Conversely while I regard Business Patterns and Continuous Digital as my masterpieces they don’t sell in big numbers. Business Patterns addresses almost every aspect of commercial software while Continuous Digital reframes organizations completely.

Or take this blog, it rangers far and wide. The last three entries have looked at workflow, before that there were two posts about OKRs but they were broken up by news about Books to be Written – heck, Books to be Written has been a year long diversion from just about everything else I do.

It is a marketing nightmare, what is the theme? What is the consistency? What problem am I solving? Who should be my customers? – in terms of “marketing Allan” Books to be Written is a disaster!

But you know what, there is a theme in here. In my mind it is all about bringing order and bringing about a better, more focused world.

OKRs and agile because they both help create order and routine.

OKRs fit with the #NoProjects critique because both say “Forget the proxies and focus on the goals.”

Workflow fits in because goals can’t be delivered if you can’t actually get stuff done, and things can go wrong in so many ways.

Patterns fit with all of this because they explain the world, as does Lean thinking.

Feedback, and dialogue sheets, because they allow you to correct when the world doesn’t match your thinking.

Autonomy and devolved authority fit in because there is no one size fits all, if you apply “the standard approach” to any of this you might make it worse.

Writing books fits in because it captures lessons learned and shares them.

Get the picture? – does my mind make a little more sense?

Perhaps the irony is, that it is exactly because I can be so unfocused, that my mind will wonder everywhere, that I see wholes and connections, and I think in systems that I need to bring order to my own world. My world is big, wide ranging and apparently random, but I’ve honed the skills to see through that. Just don’t ask me how to market that!

Which again is so very dyslexic. Most of you were taught at school how to learn, you found the typical learning methods and patterns used in typical schools worked for you. Congratulations!

Being dyslexic those didn’t work for me. Dyslexics need to learn to learn before anything else. We have to do triple-loop learning before we can do single-loop. Because the underlying causes of dyslexia are so wide, and the way dyslexia manifests itself so variable, it is rare to find two dyslexics the same.

I had to think wide from early on. Learning strategies that work for non-dyslexics don’t work for dyslexics. But that does not apply in reverse. Rather, learning that works for dyslexics is often better for non-dyslexics.

I’d like to say that from now on this blog, my output and my marketing will be more focused – so you know what to expect and why to hire me! – but I don’t have words to describe the subject of that focus. Call it the focus without a name.

Connecting the dots – workflow, agile, OKRs, dyslexia and chaos! Read More »

When is work done?

Agile / / / ,

Ever seen a Kanban board with 26 columns, or was is 22? I can’t remember. Half of them were queues anyway. (And here is a video of the full board.) How does a board get so big? Well…

After two blogs on flow and board design (It’s the workflow, stupid; When workflow isn’t column, column, column) I received a question on LinkedIn. It might not at first look like a question about workflow and board design but once you read the answer you will see how it is:

“I am writing our company’s “release process”. It is triggering quite a few confused debates internally. Some people think that the release process starts with the definition of release goals/KPIs, moves onto ideation, prioritisation, all the way to getting feedback after customer deployment. Others think it starts with a “release candidate of the product is available and finishes when the final release is given to customers.  I was wondering your thoughts on the topic. Between the two “extremes”, where would you draw the lines?”

I recognise this issue and in a way both sides are right. Although such questions normally appears in the context of writing a “definition of done” or a “definition of ready” it is really question of “where does work begin?” and “where does work end?” As such it is a workflow question and this a question of “where does our board start tracking work and where does it end?”

To put it another way, the question is: where do you place the boundaries?

Wherever you put the boundaries, someone can say “but you need to look at the bigger picture.” There is always something before the first step and something after the last step. On a Kanban board you can always add a column to the left and one to the right.

If the left most, work intake column, is “To do” then it is probably a sprint backlog and therefore there could be a column left of it marked “Product Backlog.” And since backlogs are driven by company strategy and product goals there could be a column before that. And goals are set reference to things like the market and company purpose and so there might be a column before that. You see, the workflow expands to the left?

Similarly, most teams consider “Done” to be the right most column, the final step in workflow. But really when they say done they mean “Code and test complete” so there should be a release step after that. And just because it is released doesn’t mean customers are using it so we could have “In use”. And then we should evaluate the usage, see if it meets the need and delivers the expected benefits so there is another column. But then, what if it doesn’t meet the need? Or what if it is so good it opens up new ideas? Before you know it you have a circular pattern.

(Maybe you see why some teams talk about Done and Done-Done, and even Done-Done-Done, and who knows …

Now this may start to sound like a philosophical problem – how many user stories can you fit on the head of a needle? – and it sort of is. What is done for your team?

Ultimately you need to put boundaries somewhere so the question is less “where should we start and end our process?” and more “what does the organization expect of the team?” Or you might prefer to think of it as “what do customers expect?”

You might also ask the team “Where does our work begin?” The answer to this question is going to depend both on the skills on your team and what team members think they should be doing. And that in turn will depend on the culture of the organization – are you a tailor or an image consultant?

So draw the line. Set your boundaries, codify them in release procedures and your board design. Then revisit those decisions in a few months time. Once teams are seen to perform well inside their “box” they get more leverage to expand the box and ask questions which expand the box. Which is all another reason why To do, In Progress and Done might not be the right board layout.

When is work done? Read More »

When workflow isn’t column, column, column

Agile / / / ,

What do you make of the board above? Chaotic? Crazy? – and how would you model it online?

I’m not recommending the board above. It has a number of interesting, possibly unique, features we can learn from but I’m not dissecting it today. What I do want to do is point out: work doesn’t always happen in neat little well defined columns.

Summary
⁃ Visualising work is an important step to improving workflow
⁃ But workflow can be complex and most online tools can’t handle complex layouts
⁃ That is fine for big-upfront-change Scrum
⁃ But not for Kanban (and Xanpan) when you “start with where you are” and improve incrementally
⁃ I’m delighted to have found KanbanZone

While you might want work to flow rationally, in neat stages, columns, that is often the endpoint not the starting point. The To do, In Progress and Done “triple column” layout might be the default board layout for teams, and it might be you preferred layout. It might even be a starting point or an end-point. But none of that means it is the right layout for your team now.

The team with this board tried several other designs but they didn’t work for them. Eventually they came up with this, it worked for them and it hung around for a while. I always thought it was over complicated but it worked for them.

As an advisor, be it a coach or mentor, I often need to decide whether a team should undertake lots of change up front. Or, whether it is better to “drip feed” change in. Minimal change to start with but a longer tail of change.

Sometimes ramming change through at the start can be the right thing: when team and leaders are up for change and they want to see rapid results. Jumping straight to a triple column design and embracing Scrum cab be the right thing to do.

But this approach can fall down for several reason. Perhaps the team are not keen on change. Or perhaps there are multiple sources of work – a lot of BAU and random “unplanned but urgent” work. Perhaps when there are multiple products and projects in play, perhaps with multiple product owners. Or perhaps, because you can’t see what the end state risk is high.

The alternative is to model what we have now, change it as little as possible to make the model work and then watch it in action. The board mirrors the workflow. This is why I say “A board is a team’s lightsaber, every team has to build their own.”

Over time the design is tweaked and changing the board design now changes the workflow. The two mirror each other. The board has become a voodoo doll, or perhaps I should say “digital double”. To start with the board visualises the workflow but in time the workflow implements the board. They are the same thing.

I’m describing the Kanban principle: “Start with what you are doing now.” Rightly or wrongly I think of this as “Start with where you are” – I’m told this is very Buddhist!

This contrasts with the Scrum approach, “Scrum exists only in its entirety” says the Scrum Guide which leads to a change model of “Do Scrum, change everything!”

We are back to the Kanban paradox: Kanban is easy to start but to make it work, and to keep improving, after the initial start you need more expert help. Scrum in contrast front loads the change so all the help is needed at the start and later on there is less change and less expert help needed. But Scrum can also mean change stalls.

The Kanban incremental change model isn’t risk free. Without early wins it is harder to build trust. When leaders see a lot of change happening they are more willing to accept the argument that the changes are bedding and there will be more jam tomorrow. Without early wins or big changes they wonder what is happening.

Both approaches can suffer from the “I’m feeling better” problem. Teams see results and loose the energy to change while leaders see results and stop paying for the consultant.

Even before Covid companies and teams wanted to use electronic tracking tools. Back then I always suggested teams start physically and only go electronic with some experience. With remote working in the post lockdown world this is just about impossible.

Now we have a problem: Almost every tool I’ve ever seen works the same, in columns.

If you want to “start with what you are doing now”, if you want to model the current workflow then quite possibly you can’t. Which means you either create an inaccurate model, force workflow changes right at the start (make work fit the model), or maybe create an even more complex and subtle model which is mentally taxing and requires you to think a lot about what you are seeing. A good board speaks without the need to thinking too much.

Put it simply: there is an art to board design and most tools limit your thinking.

If I had written this blog six months ago I would have said “All tools” but I have found one which is different: KanbanZone.

Before Christmas I was struggling to model one clients work with others tools. Then I found KanbanZone that changed. I now have a tools which allows me to model complex board layouts and which teams which love it. Once teams can visualise the work they can reason about it and rethink about their processes.

Now forgive me. This is a KanbanZone partner link. You get a 60-day free trial and I make a little money if you buy it later. But money is not the reason I’m recommending it, I’m recommending it because I think this tool is different to the others I’ve seen.

When workflow isn’t column, column, column Read More »

It’s the workflow, stupid

Agile / / / , ,

Sausages making illustrates workflow brilliantly! – For years I used this picture of sausages makers to describe the way teams work: meat goes in, sausages come out.

If you put pork in you get pork sausages out

If you put chicken in you get chicken sausages out

If you put beef in you get… in the aftermath of the 2013 horse meat scandal I used to joke “You out horse meat in you get beef sausages out.”

What comes out bears a strong relationship to what goes in.

If you put project A meat in in you get project A sausages out

If you put project B meat in in you get project B sausages out

Sure it works best if you have a dedicated team and you only put project A requests in. When A is finished the team switches and focuses exclusively on project B. But you know what it? It still kind of works if you mix as you go along.

When a team works on multiple different projects in parallel it is not so productive – reduced focus costs, switching between things costs too. It will be a damn site harder to make forecasts about what will be done when, answering the “when will it be done” question will be tougher. But it still works, you can still make forecasts just they will be even less reliable.

By extension, if you put business as usual meat in you get business as usual sausages out. If you put DevOps meat in you get DevOps sausages out. If you put company admin in you get company admin sausages out. Get the picture?

While it is great advice to “focus on just the project/product” the vast majority of teams I’ve ever worked with are not in a position to do that. Turning work down is above their pay grade.

Seeing the whole

In Xanpan I called this “Team centric”. The project you are doing is less relevant than the workflow you are operating. Xanpan explicitly discusses how to integrate “urgent but unplanned work” with planned “project” work, I’ve extended the thinking with OKR Zero.

When things go wrong teams become like a saturated sponge. People can’t see the correlation between what goes in and what comes out. Trust is reduced, more reporting and even policing is added. The workflow becomes more complicated, less predictable and more costly.

It is no use looking at the project. Each project is only part of the picture. Neither will looking at the BAU, DevOps or urgent but unplanned work help either. They are only pieces.

You need to look at the whole: the workflow, the sausage machine that makes the sausages.

It is of little use looking at the pork sausage project and asking how many pork sausages will come out next week if the team is also doing BAU and making some chicken sausages on the side.

Nor is it any use talking about the pork sausage project if every time the team turn the handle they have to stop. Check with accounts, check with the security team and check customers – all of whom have their own workflow. Customers who just want the team to “get on and deliver it.” Every time a team needs to interact, get permission, get feedback or anything else with another team, things slow down and grind to a halt. Other teams are most likely struggling with similar things so they all block one another.

Often when this happens, because people have the best intentions, and because they want to be productive, they start doing something else. Pork sausage production stops while they wait feedback on sausage sales. So they start producing chicken sausages. Then just as chicken sausages start coming out the pork feedback comes in and everything must switch back. But now the chicken meat is unwrapped and getting warm. By the time they get back chicken sausages it has gone off.

It’s the workflow, stupid. Let me suggest again: watch Stockless Production.

No one person

Everyone, and every team, is linked together in workflow so it is difficult for one alone to make a difference. Working harder, producing more often makes things worse not better. Individually people are pretty helpless.

Such workflow streams are full of work-in-progress, WIP, they are overloaded. This is really “work hopefully in progress” (WHIP). It is bad when one team is overloaded but when it is excess strategic wip the whole organization struggles. It is difficult to know where to begin fixing thing. You still have to start fixing it at the team level but until multiple teams start fixing there is not much improvement to show.

No one person can fix this. No single technology can change it. Maybe not even a single team. Everyone is connected. Only by looking at the whole can things be fixed.

Unfortunately this is where project warriors come along. They insist that everything is a project – which increases administration. One or two projects get expedited and are forced through but everything else deteriorates.

Saddest there are know solutions: work to completion, reduce workpiece size, operate a pull system not a push, work within capacity, allow for shit to happen (unplanned but urgent work) and don’t overload the team – in fact don’t load them more the 76%.

That is workflow management. The devil is in the detail, there are no big easy solutions – if there were they would have been applied already. Workflow management cuts across projects. Managers have a role to play here but not project managers. Project management is too narrow.

It’s the the workflow, stupid.

So finally, an advert: I’d love to help, call me, e-mail me, LinkedIn, WhatsApp, whatever medium you like, just ask.

It’s the workflow, stupid Read More »

How can we set an OKR if we don’t know the baseline?

Agile / / / , ,

The baseline problem

It came up again today, actually, once you delve into OKR setting:

“When writing OKRs, and specifically the key results, how can we set a target if we don’t know the baseline?

For example, suppose we want to increase the number of site visitors, if we have 1,000 visitors a day then the target would be 5,000 but if we only have 200 a day then the target would be 1,000. But if we don’t know how many we have to start with, how can we set a target?”

I call it the baseline problem. I know it troubles many teams but it shouldn’t. There are actually, two, or possibly three answers.

The easy answer, and one I don’t like, is to sidestep the problem: instead of saying “increase views from 1,000 to 5,000” say “increase views 500%”, or, to take another example, “reduce run time from six hours to one hour” say “reduce runtime to one sixth.”

Replacing initial and final numbers with a multiplier doesn’t solve the whole problem because you need to start by finding out where you are before you change anything. So task 1 becomes: measure status quo, whether that is eyeballs, run-time or whatever.

Another way around this problem is that you could change your OKR after setting. The initial OKR could say “increase views from to .” Again task #1 is to measure and at that point you simply revisit the OKR and fill in the blanks.

Granted some people might take exception to you tweaking an OKR after the start of the cycle but personally I don’t see that as a big issue.

Baselines solve the wrong problem

Now sidestepping the problem like this might keep you moving but it is not very satisfying. That is because: it is solving the wrong problem. The real problem is not that you don’t know the baseline but that you don’t know what the number should be. When you set the target by starting with the baseline you are putting technology first and you are limiting your ambitions.

The question is not “How many visitors do we have now?” and “What target might be achieve?” but “What visitor numbers do we need to have?” Or maybe “What visitor number do we need to make us number #1in our market?” or “What numbers do we need to break even? get investment? impress clients?”

Or take the run-time example, don’t ask “How fast are we?” and “How fast can we be?”. Instead ask “How fast do we need to be?” If you don’t know the answer then ask “Why do we want to be fast?”. Or ask, “What advantage will being twice as fast bring us?”

Rather than start with the target in mind start with the outcome in mind, then ask what you need to achieve that.

If you set the target by reference to the current baseline you are going to limit ambitions and let the current technology drive. Instead think about the outcome and what that outcome looks like, then work back to understand what needs to be done and options for doing it.

Enjoyed this post? Subscribe for updates and download Continuous Digital for free

How can we set an OKR if we don’t know the baseline? Read More »

Books to be Written – yippee!

Agile / / / 1 Comment
Books to be Written

I’m delighted to announce Books to be Written, my book about writing books, my guide to writing, producing, publishing and marketing you own masterpieces – if finished! Is published! Is for sale on Amazon – both print and e-book version.

This is available at a special introductory price of 2.99, thats $2.99, €2.99 or £2.99 – the offer will end next Friday, 24 March so get it now.

Books to be Written – yippee! Read More »

Verified by MonsterInsights