Allan Kelly's Blog, page 8

Pull, don’t push: Why you should let your teams set their own OKRs

There is a divide in the way OKRs are practiced. A big divide, a divide between the way some of the original authors describe OKRs and the way successful agile teams implement them. If you haven’t spotted it yet it might explain some of your problems, if you have spotted it you might be feeling guilty. …

Read the whole story on Medium, Pull don’t push

Posting on Medium is an experimenting – let me know what you think – comment here or there.

Why Medium? – Well, three reasons really. Thier marketing tells me it is a good way to reach new readers. Second, I know many readers of this blog don’t do OKRs and I still have more to say on OKRs so I though another platform might be appropriate. And thid, this blog is attracting a lot of spam comments at the moment – all cryptocurrencies – and I’m fed up about it.

The post Pull, don’t push: Why you should let your teams set their own OKRs first appeared on Allan Kelly.

The post Pull, don’t push: Why you should let your teams set their own OKRs appeared first on Allan Kelly.

Nuke the bug list when you nuke the backlog

“Nuke the backlog” originally a quick comment in a podcast about OKRs it summed up what I had come to believe. “Honey, I shrunk the backlog” presentation expands on that idea and outlines why I think teams should replace backlogs with just-in-time story generators – powered by OKRs or some other goal setting technique.

So I shouldn’t have been surprised when this question arrived in my mailbox:

“Throw away the backlog, is that for old bug tickets too? How does that work?”

The short answer is “Yes, throw away the bug list too.”

What do you mean, “Bug” ?

Basically the things we call bugs can be divide in two. Some are actual defects – things the system should never have done and quite possibly are detrimental to the running of the system. Everything else might be considered an enhancement. Logical right? Only where do you draw the line?

If I hit return 50 times and the system crashes the machine that is clearly a bug, the machine should not crash. But then again, how likely is someone to press return 50 times? Let me suggest not very often. And if they do, what are the chances of them doing it again? After all, there is a very easy work around. So while this might be a bug it might also be considered an enhancement request.

Ultimately, where you draw the line between bug and enhancement is subjective. This becomes really clear when you can count known bugs in single digits, 5 instead of 500. Until then calling a “change request” a bug is little more than an attempt to exert leverage and prioritise work. Calling it a bug might also have some other beneficial effect: apportioning blame might further another argument and moving a change from CapEx to OpEx column might help balance the books.

Consider all bugs from a priority point of view instead. While many different scales are used there are basically 3 categories: #1 must be done and done soon, #2 really should be done but not right now, and #3 should done but can be put off indefinitely.

Categories #1 and #3 are easy: the first are just done, the third are ignored forever but we kid ourselves that one day we’ll do them (right after we fix climate change, famine, war and pestilence.) Still, it is relatively easy to close all #3 reports over 12 months old. And next month close those over 10 months old. And so on. By all means keep a list of them somewhere but don’t pretend they will be fixed.

The only real debate are around category #2. We keep these on file in the hope that the Bug Fixing Fairy will fix them one day. In the absence of the fairy any work will require time and people to fix. That means they need to fight against all the other #2s and all the new shiny stuff. It is the same people who fix bugs as make shiny new things. It is a choice. A choice made probably by someone with the title Product Owner or Product Manager.

Which means if that fix isn’t more valuable than everything else then it won’t be done. This is the same argument I use when I say “Nuke the backlog.” If the fix isn’t valuable enough to justify being done, then it waits in a queue. The longer it waits the less important it is, leave any #2 bug there long enough and it will transform into #3.

What do I do?

The whole “is it a bug or is it a change request?” discuss is an utter waste of time. Whatever you call it work is needed, it s work to do, that work costs, that work creates benefits – the cost and the benefits are independent on what you call it. Benefit should the overriding criteria.

So

1) Fix the bugs you think need fixing

2) Don’t pretend you will fix the others, throw the bug list away

Of course, throwing away the records does not fix the “bugs”, they still exist – the same way cockroaches seem to survive everything. But we are recognising that, like cockroaches, the cost of action is not justified. This is simple honesty, a list of 100 items that we pretend will be done one day is dishonest. If that honesty creates a debate then good.

I have more advice – and more subtle advice in my “Bug management strategies” which outlines six strategies for addressing bugs and can be found in my lesser known “Xanpan appendix: Management and Team“.

The post Nuke the bug list when you nuke the backlog first appeared on Allan Kelly.

The post Nuke the bug list when you nuke the backlog appeared first on Allan Kelly.

Announcing the Succeeding with OKRs in Agile 2nd edition

The rumours are true, I’ve been working on a second edition of Succeeding with OKRs in Agile.

Now I’m ready to share, the content is stable, some polishing to do (mainly copy edit).

You can buy it now on LeanPub with free updates as they are ready.

In addition there is an OKR bundle available with give you the second edition and the first edition plus the unfinished Succeeding with OKRs in Agile Extra addition which contains additional chapters, journal articles, blog posts and Q&As. Buying the bundle will get you free updates to both the second edition and Extra as they progress.

No time scale for finishing Extra but I hope to have the second edition done by the end of the summer.

The post Announcing the Succeeding with OKRs in Agile 2nd edition first appeared on Allan Kelly.

The post Announcing the Succeeding with OKRs in Agile 2nd edition appeared first on Allan Kelly.

AI will undermine offshore & WFH programers first

A postscript, continuing from AI might effect the world of software engineering and programming. I’m supposing the power of AI real and it can replace the people we now call programmers. What next?

Spoiler alert: This post if going to upset a lot of people, who like working from home or work as offshore.

Where will the first job losses come? – let me suggest the Indian IT industry has the most to loose from AI.

In past technology cycles the first jobs to go are usually the low end jobs. The jobs which are more easily replaced are the jobs which require less skill and knowledge. Initially new technology is far from perfect so it is applied narrowly to the simpler bits of work. For example, the co-pilot feature now appearing in programmers tools which can write part, but not all, of the function.

These are often the low wage jobs (that is not always true, sometimes low wage jobs survive because the cost means they aren’t worth replacing.) So, assuming AI programming starts at the low end and works its way up market who has the most to fear? The low wage coders, who are the low wage coders? – overwhelmingly the offshore, and often outsourced, jobs.

So, expect to see India’s tech sector hit before the USA and Europe, more generally, anyone who competes on price.

For similar reasons expect to see Stackoverflow and engineers who cut-and-paste code to be hit early.

Next, recall from my last post I said that Business Analysts and others who are tasked with understanding what is needed will benefit even as programming jobs are hit (assuming AI is true). That extends to programmers, again, many programmers actually spend a lot of their time working with customers, users – and even BAs – to understand what is needed. Such programmers, like BAs, will be safer than those who code-to-order.

Such roles are less transactional in nature. The problem, the solution, and even the role itself is vaguely defined. Understanding what is needed often requires understanding to turn a vague request into something much more specific. It requires empathy, it requires background information, it requires trust and a willingness to explore together.

Let me suggest that those things are still better done in person. Doing them online is possible but in general a much greater degree of communication and understanding is needed. Nuance can be important. For that reason I believe they are better done face-to-face, in the same location, time zone and even culture. Even if some work can be done remotely having a bond which comes from physical interaction can help.

Human’s will still have a role to play in working through vagueness. That is best done face-to-face so there is a premium for working in the office. If it isn’t vague then an AI can do it.

Again, offshore programmers will loose out here. Onsite engineers will be valued more. But also, engineers who work from home will loose out, especially those who work from home every day.

It is true, you can code from anywhere: the office, a coffee shop, your house. But acquiring deep understanding, empathy and trust requires you to be there. Right now is the worst time to stay at home.

The post AI will undermine offshore & WFH programers first first appeared on Allan Kelly.

The post AI will undermine offshore & WFH programers first appeared first on Allan Kelly.

Winners and looses when AIs program

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.

The post Winners and looses when AIs program first appeared on Allan Kelly.

The post Winners and looses when AIs program appeared first on Allan Kelly.

What do you mean by “initiatives and OKRs”?

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?”

OKR workshops starting June, 12th

Book now, code Blog20 gets 20% off

tickets are limited, Very Early Bird ends May 29th

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.

The post What do you mean by “initiatives and OKRs”? first appeared on Allan Kelly.

The post What do you mean by “initiatives and OKRs”? appeared first on Allan Kelly.

June OKR workshops on sale now

Online OKR workshops are back next month. Three workshops starting on June 12 and running each Monday (PM for Europe & Africa, AM for North America).

You can sign-up for each workshop on its own or take them as a package by buying workshop 2. They have been designed to fit together but I know people are at different points on their journey.

Workshop 1: Foundation: OKRs with agile, 2 hours

Workshop 2: Working with OKRs in agile, June 19, 3 hours

Workshop 3: OKR Adoption, rollout & clinic, June 26, 2 hours

Blog readers can get a 20% discount with the code Blog20, remember: if you want to attend all 3, just buy workshop 2.

Ticket numbers are limited and there are a few very early bird discount tickets which reduce the price even further. On past experience very early bird tickets go fast and the workshops are likely to sell out.

In addition to the online time attendees receive the presentation slides, recording of the workshop and a certificate. As an extra bonus workshop 2 comes with the audio version of Succeeding with OKRs in Agile (normal price £16).

With each iteration I’m experimenting with the workshops, hopefully getting a better each time – and getting long each time too!

I’m working on the assumption that several shorter workshops are better than one longer workshop because a) learning works better in short chunks, especially online; b) while finding time for 3 slots might be a problem it is probably still easier than finding time for a whole day out. I’d love to hear from you if you have a different view, I’m open to ideas.

If you have any questions, please get in touch.

The post June OKR workshops on sale now first appeared on Allan Kelly.

The post June OKR workshops on sale now appeared first on Allan Kelly.

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.

The post Why does agile need OKRs? first appeared on Allan Kelly.

The post Why does agile need OKRs? appeared first on Allan Kelly.

OKRs as a strategy debugger (& sandwich maker)

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.

The post OKRs as a strategy debugger (& sandwich maker) first appeared on Allan Kelly.

The post OKRs as a strategy debugger (& sandwich maker) appeared first on Allan Kelly.

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

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.

The post Connecting the dots – workflow, agile, OKRs, dyslexia and chaos! first appeared on Allan Kelly.

The post Connecting the dots – workflow, agile, OKRs, dyslexia and chaos! appeared first on Allan Kelly.