When it comes to managing a team and getting jobs done, Agile development helps our software teams to streamline processes and deliver products for clients faster. But you might be surprised to learn how useful the sometimes tricky principles of Agile can be in life outside the world of technology.

I started working as a Recruitment Consultant for Equal Experts in 2016  and just before the pandemic was helping set up our Berlin office. When the pandemic hit – worried that recruitment would take some time to recover – I decided to try a completely different challenge of running my own pub. The Mermaid Inn is a Shepherd Neame tenanted traditional inn, located in a small Kent village called Bishopsbourne. The pub was originally built in the 1860s as a tap house for local estate workers and still remains an integral part of the local community.

Working alongside developers and consultants meant I learned a lot about Agile techniques, by osmosis. I was also lucky in my early Equal Experts days to work closely with some great business analysts who helped me to get a better understanding of how they used Agile practices to improve and manage the work they did with our clients.

When I started running my own pub, it seemed only logical to try to apply some of those Agile techniques in this new environment. Not only has Agile helped me in running the Mermaid Inn, it also enabled me to save enough time that I’ve been able to return to Equal Experts to work part-time as a consultant.

When I first started the job, I did everything from sorting the menu to cleaning the lines. But Agile has helped me to hire and build a team that I know I can leave to get on with things, and they’ll do a great job. So, what Agile principles have I found most useful in running my own hospitality business?

Agile Principle 1: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done

The hospitality industry is renowned for being hierarchical, and you’ll often find bar staff, shift managers, deputy managers, bar managers and so on. When I arrived at the pub, there were supervisors for each team, not to mention the assistant manager and manager.

My first big decision was to remove the hierarchy. We do always have a manager on-site, but the remaining staff work equally, with everyone encouraged to take responsibility for meeting customer expectations. This is based on the Agile principle that we should build projects around motivated individuals, give them the support they need, and trust them to get the job done.

Having a flat structure makes a far bigger difference than you realise. After about a year, we hired an assistant manager and the role really went to her head, and it changed the whole atmosphere. Even the customers commented and could sense that something wasn’t right.

Agile Principle 2: The best architectures, requirements, and designs emerge from self-organising teams.

One of the most important lessons I’ve learned from working at Equal Experts is that your team functions best when people are doing the things they want to do.

In the early days of running the pub, I organised a whiteboard session and wrote down all the jobs and tasks on it. Then I invited all the team members to choose the things they were best at. This allowed me to assign jobs people felt were suited to their individual strengths and nobody felt they were having to do things they aren’t good at. If someone isn’t great at dealing with the technical side of the tills, it’s no problem, because that will be someone else’s strength.

Agile Principle 3: Business people and developers must work together daily throughout the project.

I was introduced to Trello while working at Equal Experts, and I am obsessed with it to the point that I honestly can’t imagine how I’d organise my work without it.

I use Trello daily with my manager, and we’ll add tasks and track them, so we can ensure that each person knows what tasks need to be done, what has been assigned and when they are completed. Even if we’re working different shifts, we can communicate daily, and that’s important in a hospitality business. It’s helpful to know that we won’t overlook important tasks like staff shift changes, customer bookings and deposits and regular visits from the brewery, deliveries and maintenance tasks.

Trello also means we have very clear communication around priorities, activity, roles and responsibilities without creating lots of paperwork. Wherever possible, we don’t have paperwork in the running of the business, we save that for the EHO (Environmental Health Office).

Agile Principle 4: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

The great thing about working in hospitality is that getting feedback from customers is pretty easy. My customers will soon complain if the beer doesn’t taste right, or a meal takes too long to arrive. We encourage all of our staff to be receptive to, and act quickly on feedback.

We also have regular staff meetings every quarter or every month during busier periods like summer or Christmas. It’s a chance to share feedback with the whole team and invite staff members to make suggestions on improving the customer experience. I think it’s really important that everyone has a voice, and there is no issue with someone raising an area where improvements could be made.

Working with Equal Experts has been instrumental in how I approach the pub business. My understanding of Agile makes complete sense in a non-IT setting and it’s helped me to build a team where people work independently, and they’re not overloaded with documents and processes. As well as giving my punters the best product possible, it’s also freed up enough time for me to have two careers.

Maintaining project velocity while leveraging a remote-first working model can be a difficult challenge. All too often, firms imply that “this tool” will be the panacea, when in fact, it is not a tool issue at all. When done right, distance-based development is a careful orchestration of talent.

Remote working is not new to many organizations, but remote-first or 100% remote is a new world for many given recent events. All of a sudden, we are faced with managing across multiple timezones and multiple business/personal schedules as our home and work lives merge.

In the fast-paced agile manner in which most of our teams and clients work, we have had the luxury of being able to reduce structure and planning. Now, in the extremely distanced context that we find ourselves in, we need to adapt without sacrificing too much speed or productivity.

Here are a few simple and practical tips some of our teams have learned over the years.

1 Pull Requests

In the context of a software development team, a pull request is the process of notifying others that your work is ready to be merged into a project or solution. It can act as an approval process where others review and comment on your work before accepting it.

Where an approver and a submitter work in different time zones, there is huge potential for context-switching that disrupts the flow of work. For example, if a developer submits a pull request early in their day but then has to wait several hours for it to be reviewed, the developer is forced to pick up the next story before having completed the current story. Then, when the first pull request is reviewed, the developer has to stop work on the current story and return to the previous one. This creates context-switching or multitasking, which is known to reduce productivity, especially during complex tasks such as software development. It also can lead to “work-in-progress” problems when a single developer has multiple “in-play” tasks at any one time, which is ideal from neither a productivity nor a flow point of view.

Tips

We have found that the following help to maintain velocity:

• We prefer to delegate authority to allow engineering teams in the same time zone (or on the same schedule) to request and approve pull requests rather than having a centralized client team handle all approvals. This might initially feel risky to our clients, given that knowledge of their systems needs to be learned, and trust often needs to be earned or developed over time. In this scenario with our New York-based client, we moved slowly towards the goal of having our engineering team in Portugal approve all pull requests. We allowed time for everyone to get comfortable with the approach, starting with low-risk requests only and maintaining exceptions for the most complex tasks where the client still owned approval.
• In addition, we have also employed “Pull Request schedules” to ensure that all pull requests are reviewed daily at a regular time. For example, with our New York-based client, we agreed to a timeslot that was in the morning in New York and in the afternoon for our Portugal-based team. Having a regular mutual schedule helps improve the flow of work, allowing team members to get into a rhythm or cadence, which helps to increase flow and reduce inefficiencies, such as context switching. It also helps to act as a reminder, avoiding situations where a pull request is missed or other work is unintentionally prioritized.
• It is often possible and preferable to remove the need for pull requests entirely. Once a team has formed a good working knowledge of the domain or product, with a predictable velocity and a high-trust culture, approvals become unnecessary.

2 Think Ahead

Applicable to any delivery is the risk of reduced productivity due to lost time, such as waiting for access or information. In a collocated, physical world this is still a common issue, but the cost in a remote-first world is even higher as multiple unaligned schedules or timezones exacerbate delays.

As a standard, we find it helps to publish everyone’s timezone or schedule and find mutual working hours if possible so that everyone has a chance to collaborate with one another. The key is to prioritize work that requires collaboration during mutual working hours, leaving other work to other times of the day.

This form of prioritization is the responsibility of all team members and is something we mandate as part of our process and culture.

To help it become part of the mindset with our New York client, we use a team charter to showcase that navigating multiple timezones and schedules is the responsibility of all team members. For example, as a developer, it is crucial to be aware of where you are in your current task and think of what you might need to complete it. With the knowledge of any future impediments or dependencies, our developers make requests for information or input in advance and arrange their schedules so they are available to collaborate during mutual working hours.

Although this sounds very logical, it is very easy for team members to focus on their current tasks and to miss opportunities to collaborate during mutual working hours, especially when such opportunities are very limited in duration (which is often the case with more distant timezones).

3 Technical Alignment

To help replace some of the communication opportunities that happen naturally when we collocate, we create a daily team routine that includes technical alignment meetings during the start of each relevant timezone or schedule.

The meeting is a combination of a typical agile standup and a parking lot style meeting. It provides the opportunity to address important technical topics or problems without interfering with daily standups or the immediate flow of work. It creates a space where engineers and testers can share technical insights and make technical decisions together. This crucial sharing of knowledge and ideas can be easily lost when there are only structured or time-sensitive meetings arranged. With our New York-based client and Portugal-based engineering team, it really helped to increase productivity through more collaborative and better decision-making, which resulted in fewer mistakes and less rework and technical debt.

Learn More…

These are just a few of our tips to help improve productivity when working remotely, but for more ideas, check out our remote working playbook

If you want to learn more of the techniques we use to build high-performing remote-first teams watch this webinar.

Traditional businesses use KPIs that compare year-on-year performance, and “SMART” objectives that commit people to an inflexible 12 month journey. Reaction times are slow, and feedback loops bring insight far too late. It may seem counter-intuitive, but success with long term goals can only be achieved using short term objectives.

An alternative to KPIs

“Tradition becomes our security, and when the mind is secure it is in decay.” – Jiddu Krishnamurti

Organisations emerging from the industrial revolution were traditionally organised into hierarchies, made efficient through the separation of concerns, and measured using well recognised KPIs (key performance indicators – such as cost and time). This approach proved very effective for stable business sectors that had reached a high level of maturity and was recognised as the standard way of running a business.

The internet, however, has created significant market disruption, and the rate of change across many businesses is still rapid and promises to remain so for the foreseeable future. To respond to this ever-changing environment, a new way of setting targets and prioritising work has emerged that removes the need to micromanage every task and function. Made popular by Google, this technique is generally referred to as OKRs (Objectives and Key Results) and, unlike the more static KPI approach, it adopts a rapid review cycle and a focus on group responsibility. 

This is why we chose OKRs as our method of choice for linking strategic goals to delivery activities. At Equal Experts, we are experienced at bringing about change and OKRs are about delivering that change, not about maintaining the status quo.

Essentially, the OKR approach aims to achieve three outcomes:

1. Align task execution directly to company strategy
   When the tasks being performed by a team or individual are far removed from the strategy that gave rise to those tasks, the reason is lost. All too often, teams successfully complete these tasks but somehow manage to completely miss the strategic point. By linking tasks directly to core company goals, OKRs help to ensure that the “doers” understand the purpose and value of their efforts.
2. Create transparency
   Where teams and departments operate in isolation from one another, and when their work is hidden from the rest of the organisation, duplication of effort proliferates and waste is high. The OKR approach endeavours to create transparency so that unintended duplication can be avoided.
3. Encourage collaboration
   There is little incentive to collaborate when overall goals are divided and cascaded down to teams, and then divided further to individuals. By creating objectives at the team level, rather than measuring the success of each individual, collaboration can be encouraged rather than discouraged.

Goals: Setting the strategic direction

“The best way to predict your future is to create it.” – Abraham Lincoln

The starting point for our stripped down version of the OKR approach is to establish the core goals for the organisation. These goals typically manifest as a handful of statements that embody the overall purpose and intent of the organisation; they are high level, direction setting, and likely to create an element of conflict when taken as a set.

For example, a company might have as two of its goals, ‘be profitable’ and ‘be ethical’. There are many ways to be unprofitably ethical and many ways to be unethically profitable. Taken together, however, the number of options available to the company is reduced. Thus, through a small number of well-defined goals, a company can create a clear strategic direction.

Constraints may, at first glance, seem to limit innovation and progress; in practice, they help to focus attention on the changes that best align with the strategic direction of the company, thus facilitating faster and more effective decision making.

Goals are long-lasting (at least a year, and generally longer), and they form the first layer in the OKR hierarchy; there is only one more layer.

Objectives: A call to action

“Nothing will work unless you do.” -Maya Angelou

The real driving force behind the OKR approach are the objectives themselves. Objectives are the things you are going to achieve; they are time-based (typically to be concluded within one or two quarters), qualitative in nature and aspirational. 

An objective should clearly state an outcome, rather than an action or deliverable. “Build an application” is not an objective, but “Ensure our customers are engaging more regularly with our service” might be. This may seem like a small distinction, but it has a big effect; by focusing on outcomes you empower teams to use their skill and judgement to deliver success, rather than just complete tasks.

Each objective must link back to one of your goals, whilst conflicting with none of the others. If an objective seems to link to more than one goal, it is likely that you have combined more than one outcome into a single objective. This is not advisable as there will be a conflict of focus when attempting to deliver the objective.

Objectives form the second and final layer in the OKR hierarchy. Objectives should not have sub-objectives, nor should they be cascaded to sub-teams to create further related objectives. It should, therefore, be clear that objectives need to be assigned to multidisciplinary, empowered teams and not distributed to individuals. Anyone who is needed to make the objective successful should consider themselves part of that team.

Key Results: Measuring success

“In many spheres of human endeavor, from science to business to education to economic policy, good decisions depend on good measurement.” – Ben Bernanke

If the intent is to deliver successful outcomes, then there needs to be a way of measuring that success. All too often, progress is measured in terms of tasks completed or widgets delivered; this is not the purpose of key results. Each objective should have at least one key result by which its success is measured.

A well defined key result is numerical in nature, defines a specific target (either relative to a current baseline or absolute), and measures an outcome rather than the tasks undertaken to achieve that outcome. Additionally, care should be taken to select key results for which you can “move the needle” within the timescale of the objective. If you’re not going to see any movement in the measurement over the next quarter or two, then it is not going to be an effective way of guiding your actions and refining your approach.

Examples of key results might include “50% of new users return within 2 weeks” or “Churn rate < 2% this quarter”. An example of a poorly defined key result might be “20% more prospects contacted” as it measures the level of activity and not its success.

Establishing a cadence

“Nothing is ever so good that it can’t stand a little revision, and nothing is ever so impossible and broken down that a try at fixing it is out of the question.” – Rebecca Solnit

Establishing, monitoring and renewing OKRs is an iterative process, and once you have defined and assigned your objectives you need to establish a cadence for reviewing them. A typical cadence is as follows:

1. Plan quarterly
   Review all your current objectives, remove those that are no longer relevant or that have been completed, and create new ones for the next quarter. Some of these new objectives are likely to evolve out of previous objectives allowing you to take your success to the next level, or change tack in response to unexpected results.
2. Amend monthly
   The whole point of OKRs is to continuously improve based on your findings. It is therefore worth revisiting your objectives on a monthly basis to see if any are flawed and need to be adjusted to improve your chances of success. 
3. Report weekly
   Measuring your key results on a weekly basis and reporting on progress improves transparency across teams, and also allows you to test-and-learn as you progress. It is easier to know which actions produced which results if you measure at a granular level, rather than only on completion of the objective.

It is then up to the assigned teams how they deliver, and the tasks they perform to achieve that delivery, but as objectives are short lived, explorative and iterative in nature, agile techniques are usually well suited to their delivery. This is because OKRs are about change and improvement – for existing processes where change is not needed or prioritised, existing techniques should still be used to measure their success and efficiency.

The art of introspection

“You will only fail to learn if you do not learn from failing.” – Stella Adler

OKRs are simple in nature, but any change, no matter how small, is always hard to embed in a lasting way. This is because old habits are hard to break, and so it is essential that during the early stages of introduction, you revisit the rules for objectives and key results in this document and make sure you are applying them consistently. Otherwise, it is highly likely that you will drift back towards an existing KPI based approach. Three of the common mistakes made are:

1. Cascading objectives so that teams can create “subordinate” objectives of their own.
2. Measuring tasks completed rather than outcomes achieved.
3. Giving every objective to everyone, rather than assigning them to responsible and empowered teams.

Don’t expect to get this right the first time; no-one does. But don’t forget to learn and improve either; that’s the point of iteration. We have a tried and tested approach to putting OKRs into practice, so if you’re interested in doing this either experimentally, or at scale, drop us a line at strategicadvisory@equalexperts.com  and we’ll see what we can do to help

In Part 3, we will introduce our Roadmap Radar tool, which allows you to visualise your entire portfolio of work in a way that creates clarity, agility and collaboration.

 

Part 1 – An agile strategy for an unpredictable world 
Part 2 – Shaping the vision – (you’re here!)
Part 3 – The Roadmap Radar – When is a plan not a plan?
Part 4 – The Bet Canvas – Nothing ventured, nothing gained

To evolve is to survive, and to plan is to succeed, but all too often, plans are static whilst the world is ever changing. In this four part series, we propose a tried and tested approach that introduces quarterly agility into your organisation without losing sight of your long term goals.

Iceberg! Right ahead!

“No plan survives contact with the enemy.” – Helmuth von Moltke the Elder

Here at the Equal Experts Strategic Advisory Practice, we recognise that stability is an illusion, and steady state is a temporary luxury. Any attempts to create and stick to long term plans are inevitably doomed as they fail to adapt to the world around them, or take account of the discoveries made once the journey has begun. 

This doesn’t mean you can’t have long term goals; quite the opposite, but to assume you can decide today all the actions necessary to get there is folly. It is no more realistic than standing in Liverpool, pointing a ship at New York, setting its course, and hoping it will arrive at its destination unharmed with no intervention from the captain. Decisions have to be made, events adapted to, and courses changed.

Instead, you might think of strategy as being a sailing boat in high winds, crewed by a group of people with different but complementary skills, who have the autonomy to make adjustments quickly, in coordination with others, according to the conditions.

After all, sometimes there are icebergs.

Seasons come, seasons go

“In the depth of winter, I finally learned that within me there lay an invincible summer.” – Albert Camus

Of course, we acknowledge that businesses need a plan, but the duration of such plans is shorter than you might think. Consider those 2020 vision documents produced by most organisations, some as long ago as 2015. We have seen very few of those plans that made it past the first year without becoming irrelevant, and not surprisingly, none included the impacts of a global pandemic followed by a recession.

In our experience, the most effective cadence for planning is quarterly. It fits well with company funding cycles, and is short enough to allow course corrections within the financial year. It also fits well with a more fundamental cycle that affects human motivation in a way that few people recognise. There are, of course, the recognised impacts of season – the January blues, flu season, holiday seasons and so on – but there is something more fundamental. 

We humans work in seasons, measuring the end of one and the start of another. Traditionally, we had to align tasks to these seasons to ensure our crops were properly planted, tended and harvested, and our hunting behaviours adapted to the migratory patterns of animals.  Even now, in our sanitised world, we see the seasons as natural start and end points, and yet at work our projects often continue on unbroken throughout the year. As the weeks turn into months, and the end seems far away, it can be hard for us to remain motivated, and productivity starts to fall. People lose focus.

We have found that moving to a quarterly cadence, where outcomes are achieved and teams move on to the next challenge every three months, can avoid this slump. A clear break every three months give teams a fresh boost and renewed focus. This doesn’t mean you have to abandon what you’re doing; just create a clear “cake and candles” moment to celebrate success. Then you can reset direction and go again based on what you’ve learned and what has changed in your business landscape.

Switching to a quarterly cadence means you are discovering all the time and are giving yourself the space to continuously adapt your plans. That’s why we follow an approach we call Continuous Evolution.

Ninety days to done

“Learning is not attained by chance, it must be sought for with ardor and attended to with diligence.” – Abigail Adams

Breaking out of a tightly planned and predictable way of working can be very challenging. Our Continuous Evolution framework helps guide an organisation through the unknown, no matter what factors are driving the need to change, or the kind of transformation required. The aim is to build an agile and iterative strategy, in pursuit of the surest and quickest path to business value. Making well-planned interventions and measuring their impact is the key to creating the right mindset and high performance culture capable of rapidly delivering sustainable change.

Working in 90 day cycles, this three stage framework exists to: 

1. Shape – Establish the goals & objectives of the organisation, as well as the best ways to measure progress towards them (Objectives & Key Results)
2. Plan – Visualise how time-bound activities are aligned to the strategic priorities of the organisation, indicating clusters and gaps (Roadmap Radar)
3. Execute – Gather, prioritise and place ‘bets’ that are designed to realise business value through experimentation, maximising returns whilst minimising the exposure to risk (Bet Canvas)

At the end of each 90 day cycle, leadership should reflect on the progress achieved, and lessons learned.  That allows the organisation to revise to their OKRs and Roadmap Radar as required, before deciding (a) which bets to evolve or stop; and (b) which new bets should be placed during the next cycle.

Stage 1: Shaping the vision

“The only limit to our realization of tomorrow will be our doubts of today.” – Franklin D. Roosevelt

There’s a lot more to strategy than simply feeling your way through experimentation, and we have discussed this in previous blog posts. However, there’s also a lot more to strategy than thinking and talking – effective strategy arises from situational awareness and insight, and these can best be discovered through hands-on experience.

Not great fans of reinventing the wheel, we use OKRs (objective and key results) as the first step in the Continuous Delivery framework. However, we did strip that particular wheel back to its basics so that it could be easier for organisations to adopt and adapt it to their own needs. We find that OKRs provide a flexible, collaborative method that ensures activities are aligned to the strategy, across the organisation, whilst optimising the time spent on this activity.

The advantages of the OKR method are:

• Strategic priorities are discussed and agreed by leadership, including the establishment of long-term goals 
• It provides assurance that the various aims of the organisation do not conflict with or contradict one another
• It ensures the goals and objectives of the organisation are clearly understood at all levels, through regular communication 

This transparent and non-hierarchical approach to strategy helps deliver change, by creating a shared understanding of the organisation’s long-term goals, before aligning a set of measurable objectives. Progress towards each objective (and therefore goal) is measured by Key Results, with outcomes reported to the whole business in a regular cadence. 

Stage 2: The Roadmap Radar

“Mann Tracht, Un Gott Lacht” – Anonymous

Literally translated, “Man plans, and God laughs”. It’s an old Yiddish adage and it carries a lot of hard learnt wisdom in its brevity. It sums up the fragility of detailed plans in the face of uncertainty, unpredictability and the unknown. But any venture involving more than a handful of people needs some form of plan if it is to avoid descending into chaos and conflict, and that’s why we’ve created a unique tool that carefully balances the need for direction with the importance of agility and empowerment. 

The Equal Experts Roadmap Radar provides an intuitive view of the goals and objectives of the organisation, with initiatives plotted on the radar to indicate clusters and gaps in effort. It’s simplicity allows everything to be shown on a single picture, and the ease with which it can be changed encourages flexibility to changing circumstances.

The advantages of the Roadmap Radar are:

• It creates a portfolio of prioritised bets, to help the organisation decide where to go next, with confidence
• It aligns effort directly to the organisation’s strategic goals, providing teams with a greater sense of purpose and meaning
• Once misaligned activities are placed into the backlog, multi-disciplinary teams can be more effectively formed by bringing together the right, motivated people.

Once the goals and objectives of the organisation have been affirmed through the OKR process, efforts can be plotted as ‘bets’ against each objective, laid out to indicate a timeline for delivery (in this quarter, in the next quarter, etc).  By visualising the balance of effort, any prioritisation decisions are radically simplified. 

Although the Roadmap Radar shows four quarters, the only certainty is in the first of these. Everything beyond that is conjecture; sound conjecture based hopefully on best available knowledge, but conjecture nonetheless. Each sector represents an objective that can be pursued by a team, independently of the others. This reduces cross-team dependencies, allowing greater empowerment and increasing motivation.

Stage 3: The Bet Canvas

“You will have to experiment and try things out for yourself and you will not be sure of what you are doing. That’s all right, you are feeling your way into the thing.” – Emily Carr

The way we approach the “doing” part of the Continuous Evolution cycle is through the use of highly structured “bets”. These outline how experiments will be designed, how success will be measured, and the challenges and risks that will be faced. Bets are delivery focused, and are guided by continuous feedback loops.

The benefit of the “bet” approach:

• A bet is a specific idea whose value is tested methodically through experimentation, optimising the return of business value whilst minimising exposure to risk
• Each Bet Canvas includes a time-bound experiment, with a plan for how evidence of the impact will be gathered and analysed 
• The progress of each bet can be reported regularly (at least weekly) and allows the riskiest assumptions or least well understood things to be tested quickly

The purpose of each bet is to (dis)prove a hypothesis through experimentation, which in turn links to an objective, which aligns to a strategic goal.  The language of ‘bets’ is intentional – how much time, effort and resource – that could be spent elsewhere – are you willing to commit to the exploration of this idea?  Some ideas require more investment to prove than others, and some are better understood and therefore require less validation. As a result, not all bets are equal.

The Bet Canvas ensures that each bet has a clear and rigorous structure, and can be displayed for all teams to see and add suggestions, comments, and questions.  It also guarantees a consistency of approach, whilst also highlighting unknowns, which allows for easy and regular reporting of progress.

Rinse and Repeat

“Yesterday I was clever, so I wanted to change the world. Today I am wise, so I am changing myself.” – Rumi

As bets conclude value is generated and lessons are learnt. With that increased knowledge and released value, the organisation can enter the next discovery cycle better informed and focused. How many times should an organisation repeat this process until it reaches steady state, and when does business as usual resume? The answer is, when the world stops changing, you can stop discovering, and until then, discovery IS the steady state.

In Part 2 we will discuss the OKR approach in more detail and give you a taste of how we facilitate OKR sessions to get the most out of them.

 

Part 1 – An agile strategy for an unpredictable world – (you’re here!)
Part 2 – Shaping the vision
Part 3 – The Roadmap Radar – When is a plan not a plan?
Part 4 – The Bet Canvas – Nothing ventured, nothing gained