A Scrum Book – The Spirit of the Game by Jeff Sutherland, James O. Coplien, and The Scrum Patterns Group

3 Big Ideas

  • Scrum Guide defines the rules of Scrum but gives no indication of “how” to implement. Patterns provide a guide “how” to implement scrum and possible sequences of implementation. Patterns can be adopted piecemeal and the language guides which patterns should be considered first.
  • There are two “pattern languages” to consider when implementing scrum

Planning an adoption with Scrum Patterns | Agilix

Ref: https://agilix.nl/blog-en/planning-an-adoption-with-scrum-patterns/?lang=en

  • When adopting scrum, focus on the “high order” system before a lower level pattern. For example, focus on establishing a stable team before you focus on other things
    • “Think globally, act locally.”


Patterns are a roadmap to introduce Scrum into organizations, one pattern at a time.

There are almost countless ways to sequence patterns, each sequence giving rise to a Scrum organization with a slightly different character.

1 Takeaway

  • Use this pattern language to describe and visualise possible adoption pathways for organisations

If you have more time… Image result for clock icon


  • While The Scrum Guide describes the basic rules of Scrum, the patterns amplify the guide by showing teams how to solve problems in a specific context.
  • What is a pattern? One simple definition is that a pattern is a repeatably applicable solution to a problem that arises in a specific context.
  • Working in small steps reduces risk and helps teams move forward with confidence in “process improvement.”
  • A carefully chosen sequence of such patterns can resolve product development issues and, importantly, help the organization understand Scrum more in depth.
  • Patterns explore the forces at play in the complex contexts of organizational development and workflow.
  • Patterns help with sequencing:
    • Build a Cross Functional Team BEFORE an Autonomous Team
  • Sometimes you will need to apply several patterns—maybe over several months—to solve a complex problem in the organization.
  • Patterns are a roadmap to introduce Scrum into organizations, one pattern at a time.

The Scrum Core as Patterns

  • Think of Scrum as a game we play. As with most games, it can be a wonderful form of engagement if its players appreciate both the discipline and freedom that help them create value.
  • Spirit of the game = Scrum requires a spirit of interaction between people, and that spirit can be difficult to define. This spirit is part of the culture of the organization and may be indiscernible for the people within the culture. Though it may be difficult to define, the spirit is easy to recognize when it is broken.
  • People often equate “doing Scrum” with the use of a Scrum Board. There is much more to Scrum than any set of tools can capture.
    • Kicking a soccer ball around in the park can look a lot like playing soccer, but it is not soccer.

  • Core Scrum in Pattern

Systems Maps - General (10)

  • Description:
    • 3 “systems” which should be focused on in order
      • Assemble the team
      • Define the Product
      • Agree norms (ways of working)
      • Establish the Sprint
  • Jeff Sutherland suggested scrum adoption sequence (10 steps)
    1. Start with ​¶15 Stable Teams​.
    2. Decide how you are going to size your releases every ​¶46 Sprint​.
    3. Establish a velocity (see Notes on Velocity) and bring it into statistical control: use ​¶66 Yesterday’s Weather​.
    4. Focus on Done (see ​¶82 Definition of Done​) instead of foundering in rework. It takes teamwork to do that.
    5. Use ​¶25 Swarming: One-Piece Continuous Flow​.
    6. Know how to deal with interruptions during the Sprint.
    7. Align the organization to deal with emergencies using the disciplined replanning of ​¶32 Emergency Procedure​.
    8.  Get into a rhythm of improving your process every Sprint with ​¶92 Scrumming the Scrum​. Par
    9. Drive forward with the ​¶91 Happiness Metric​.
    10. Revisit how you are sizing your Sprints. Give yourself room to improve.

Product Organization Pattern Language

  • The Product Organization is one major Whole to which you must attend when introducing Scrum
  • Organizational values are the bedrock of the processes, structure, and atmosphere of the workplace
  • Good values are intrinsic and come from within.

Development Team

  • To build a product of the ​¶93 Greatest Value​ requires that producers work in a way that allows the team to recognize such value when they achieve it, and to support decisions that carry the team in that direction.
  • Scrum is optimised for:
    • Effective communication and feedback are at the heart of effective complex system development
    • The organization structure should be optimized for the most crucial paths of communication (Conways Law)
    • Heart of Agile:
      • Communication
      • Regular feedback
      • Self-organization
  • Focus on Value – our focus and concern are on the end user, market, and customers rather than on the tools and technologies we use to do our work.
  • Small Teams – Organize the workforce into Small Teams of more or less five people, partitioned according to the most important concerns for the creation of value by the enterprise. Supplement this structure with a small number of cross-cutting structures for secondary but important concerns
  • Scrum discourages local optimisation:
    • A Development Team structure where each team owns one part of the product, or just a product subassembly.

Involve the Managers

  • Dilemma – the extent of management control, or whether there should be management at all.
  • Managers help in these cases:
    • Managers have the station and power to restructure the organization while Product Owners do not.
    • Contractual responsibility for a relationship with an external vendor that supplies multiple product developments
    • Strategic issues related to the lifetime or very existence of a team or product.
    • Product Owners are unlikely to have an adequately objective view to defund their own product when business sense dictates that they should.
    • Sometimes a product or even an enterprise must go through discontinuous changes to survive.
    • Deal with impediments that may be too weighty for the ​¶19 ScrumMaster​ or Product Owner
    • Intervene to resolve conflicts between Product Owners of different products.
    • Escalation step for impediments
    • Help access to corporate resources,
    •  ¶114 Firewall – run interference against stakeholders who would interfere with the team.
    • Personnel development and administration.
    • Raise the risk appetite for action where scope is broader than a single product.
      • For example, remove product direction decisions from a sales and marketing to the Product Owner.
  • Product Owner, and not a manager, heads each product, with a very thin and narrow veneer of management at the next level up.
  • Managers must respect:
    • the Product Owner’s authority over product content and release
    • the Development Team’s self-direction as to the how, the who, and sometimes the when of feature development.
    • the scrum master raises the issue when these boundaries are not respected
  • The strongest foundation of management power is the reluctance to use it, and using it sparingly.
  • Celebrate Failure
    • “acknowledge failures with positive comments. Congratulate everyone on their efforts and remind them of the strengths and wisdom they gained from the experience. Put in perspective, a failure can do as much to motivate a team as a win”

Product Owner Team

  • Create a Product Owner Team, led by the Chief Product Owner, whose members together carry out product ownership.
  • Chief Product Owner (CPO) has final authority over the ordering of the Product Backlog.
  • The CPO plus the other people that support the CPO is what we call the Product Owner Team.
    • Do not label Product Owner Team members as ’Product Owners’— they do not own anything.
  • The CPO clearly communicates the strategy and the Product Backlog Items. The CPO works with the Product Owner Team members to select and order backlog items for the teams.
  • The Product Owner Team members can help the CPO work with the Development Teams to break the backlog into small Product Backlog Items for execution.

Manage Development Team Distractions

  • Create an Oyatsu Jinja (Snack Shrine) near the team area, with some candies, snacks, and drinks (coffee or tea).
  • Avoid Tragedy of the Commons:
    • multiple individuals, acting independently and rationally consulting their own self-interest, will ultimately deplete a shared limited resource (the dev team) even when it is clear that it is not in anyone’s long-term interest for this to happen.

  • Legacy management can cause confusion about the locus of control over product content and direction.
    • The locus of control should be the scrum team

Value Stream Pattern Language

Value Stream

  • Value Stream:
    • The development process and the path from conception to market are as important to product success as the product idea itself.
    • The process to deliver ongoing and evolving streams of product increments to stakeholders
    • The organizational structures and processes that provide cradle-to-cradle support for the product.
  • Any given product can support multiple Value Streams, so a given Scrum Team may manage several Value Streams. Any given Scrum Team usually creates value for several stakeholders, and this implies that there are often several Value Streams at play.
  • Rhythm and time-boxing are two sides of the same coin. Sprints might start every two weeks; that means that a Sprint’s duration is no longer than two weeks.
  • Scrum does not presume that one size fits all, and it is up to each team to find its place within the recommended range (or sometimes, outside that range) that works best.
  • Good kaizen (see Kaizen and Kaikaku) often has roots in sustaining a good rhythm.
  • The Product Owner orders PBIs in a way that generates the largest long-term ROI.
  • Roadmap, it too can guide the Product Backlog contents. A good initial Product Backlog is a list of ​¶71 Sprint Goal​s that takes the product in the direction of the Vision, where each Sprint Goal becomes the core of the corresponding Regular Product Increment.
  • Historically, Jeff Sutherland split Toyota’s Chief Engineer into the Product Owner and ​¶19 ScrumMaster​ roles, reflecting business and development concerns respectively.

Product Backlog Increments

  • A PBI can describe anything that has potential value to a stakeholder.
  • No PBI within the top two or three Sprints should take more than 10 percent of the total PBI effort for that Sprint, and keeping them below 5 percent of the total effort is even better.
  • In most cases, the number of ​¶60 Estimation Points​ completed in the last Sprint is a reliable predictor of how many Estimation Points of work the team will complete in the next Sprint.
  • Break down Product Backlog Items into work items and assemble them into a plan called a ​¶72 Sprint Backlog​. Each work item is a Sprint Backlog Item (SBI). No Sprint Backlog Item typically should be any larger than a single Development Team member can complete in a single work day.

Product Definition

  • It is crucial to optimize the design for economies of scope.
  • Use Value Areas  – Example at energy company:
    • I-Join, I-Pay, and We-Support.
    • Value Areas address an area of customer value and requires specific detailed knowledge.
    • Each Value Area consists of four to six Development Teams
  • Broad vs Narrow
    • Too broad, the product lacks focus and direction, and users may have difficulty identifying with it.
    • Narrow –  Great products grow from small products that work.
  • Uniformly marketing all of a large product’s features to a single market is likely to confuse the consumer.
    • What you sell/market to the customer might be different to how you internally organise.
  • There may be legal forces for splitting a “application” into multiple “applications”, Microsoft to unbundle Internet Explorer from Windows®. We become limited in our ability to tailor existing products to add market differentiation.

Pattern Tips

  • Patterns characteristics:
    • Must be built upon multiple known examples
      • rule of thumb – must be three independently discovered prior examples
    • Has a moral grounding, it is is morally profound
    • Solves a problem.
    • Describes the how
    • Describes why it is essential
    • Takes into account context
  • Pattern Ratings:
    • ** = you will need this solution to resolve the forces to move forward in Scrum.
    • * =  the pattern is the core of a good solution; however, we cannot argue that it is the only way.
    • 0 =  works as a solution and that it is the best solution much of the time—though other good solutions exist as well.
  • Each node of the graph is a pattern, and the lines between patterns depict ordering dependencies between them. The graph therefore shows, for each pattern, the patterns above it, which you should already have considered before applying any given pattern—and the ones below it, which are candidates for next steps once you have put the current one in place.
  • There are almost countless ways to sequence patterns, each sequence giving rise to a Scrum organization with a slightly different character.
  • A pattern language is the set of rules for combining the patterns in meaningful orders; as a “language” it has a grammar that can generate all sequences that are meaningful “sentences.”
  • It is useful to think of the patterns as building the spaces, or the identities, for groups of people who gather occasionally or periodically to exchange ideas, build things, solve problems, and to grow together.

Other stuff

  • In the land of the blind, the one-eyed man is king. Anyone in the organization can assert their authority by claiming they can see what others don’t.
  • Toyota Quote:
    • “build people, not just cars”
    • The soil is tended and prepared, the seeds are watered, and when the seeds grow, the soil is maintained, weeded, and watered again until finally the fruit is ready
  • Make all non-trivial issues visible with an Impediment List; raise them up to the right people in the organization for resolution.
  • we define value as something of worth to some person or set of people whom we wish to serve.

Behaviour-By-Example – How to behave during coronavirus

The Coronavirus has been a great demonstration of how difficult drive behaviour change. Yesterday the UK Government mandated stricter policies to restrict movement after many people across the country continued to socially mingle.

In order for behaviour to happen the following needs to occur:

Behaviour happens when motivation & ability & prompt converge at the same moment (B=MAP)

BJ Fogg – Tiny Habits

To date the government has relied on the motivation to “protect the NHS” for behaviour change.

We see so far that this motivational plea has not been sufficient.

Motivation is the weakest of these three variables.

Our motivation comes in waves and is not reliable. We can see as soon as the sunny weather arrived at the weekend how quickly people were motivated to go outdoors.

Ability and Prompt are more powerful levers for change.

Make the behaviour as easy as possible and provide prompts that trigger the desired behaviour.

So far new behaviours have been made harder to adopt by using new, ambiguous terms such as “social distancing” and “self isolation”. Many people are left wondering what do these really mean?

To help overcome these challenges and more effectively enable behaviour change in organisations, I have used a technique called Specification-By-Example.

Typically used by software development teams, to describe how their systems should work but it’s a great technique for any behaviour change.

Examples are described through a simple language:

  • Given = The context
  • When = The Prompt
  • Then = The action (ability)

You can see this in action through a really simple example below:

  • Given i’m 70 or over
  • When I need Milk
  • Then I will ask a relative to purchase on my behalf
  • And leave the milk on door step

The benefit of this approach is it provides a concrete example for people to design their behaviour.

Importantly it provides a foundation to have a good conversation.

My hope is this post will equip you to have better conversations with parents, children and friends around the desired behaviours. Clearing up ambiguity and discussing real examples.

As coaches, facilitators and leaders you can use this technique in any efforts where behaviour change is desired in your organisation.

The key lessons to takeaway are:

  1. Don’t rely on motivation
  2. Use concrete examples
  3. Make it simple

I’d love to hear your examples in the comments below and on LinkedIn. Here are some more of mine:

Scenarios: Milk

  • Given i’m exhibiting no symptoms
  • And i’m under 70
  • And I do not live with anyone in either of those categories
  • When i need milk
  • Then I will visit my nearest supermarket
  • And maintain a distance of 2 meters
  • And get over 1 weeks of essential produce
  • And wash my hands immediately after returning home
  • Given i’m walking to the supermarket
  • And someone is walking towards me on a narrow pavement
  • Then i will cross the road to keep a 2 meter distance
  • Given I have a persistent cough
  • When I need milk
  • Then I will not leave the house
  • And I will ask a relative/friend/neighbour to bring me milk with other essentials
  • And leave it on door step

Scenarios: Exercise

  • Given I have not exercised
  • When I exercise
  • Then I will only do a walk, run, or cycle
  • And limit my activity to less than 30 minutes
  • And keep a distance of 2 meters
  • Given I have exercised today
  • When I feel restless and i need of exercise
  • Then I will not leave the house
  • And do an exercise activity indoors
  • Given I have not exercised
  • When my friend calls to invite me for a round of golf
  • Then I will say no
  • And suggest we play Mario golf on Nintendo switch


60 Second Summary: How to Lead in Product Management – Roman Pichler

3 Big Ideas

  1. How Product Leaders can overcome these six common challenges:
    1. Leading a group without managing them
    2. Leading large and heterogenous groups
    3. Limited influence on group member selection
    4. Both contributor and leader
    5. Working both strategically and tactically
    6. Working with agile practices
  2. Product Leaders need to be aware of their leadership style and nuances of product leadership compared to other forms of leadership
  3. Conflict, Conversations and Decision Making are explored as key leadership skills for leaders in Product Management


“People will only follow you for two reasons—because they trust and respect you or because they fear you.”

“Mindfulness helps you make better decisions for the following two reasons: First, it helps you recognise cognitive biases. These include confirmation bias, the tendency to prefer data that confirm preconceived views; negativity bias, focusing on negative experiences; and overconfidence bias, overestimating the reliability of one’s own judgements, control, and chances of success. Recognising these biases reduces the risk of making wrong product decisions—for instance, disregarding valid data because it does not match your view. Second, mindfulness helps you to be more aware of your feelings—for example, how excited, sceptical, or displeased you are. This makes it less likely that your emotions drive a product decision—for example, that being angry with someone prevents you from paying attention to the person’s valid concerns.”

1 Action:

Explore using Non-Violent Communication when resolving conflict

Beyond 60 seconds….

Notes, Quotes, References and Related material

Product Leadership Foundations

Lead at three levels:

  1. vision
  2. strategy
  3. tactics

Leadership Styles (A product leader may flex across these styles)Image result for leadership styles affiliative autocratic

Image result for leadership styles affiliative autocraticImage result for bill campbell create environment


Empower the development team, help the members acquire the relevant knowledge, and allow people to take full ownership of the solution or, if that’s not possible, the product details.

“Manage your product, not the team.”

Managing Stakeholders – Use the Power Grid to see where your stakeholders fall

Instead of interacting with the players on a one-on-one basis, aim to build a stakeholder community whose members work together for an extended period of time and who learn to trust, respect, and support each other.



Buddhist teaching – Right Speech – five guidelines

  1. Speak with the right intention
  2. say only what you believe is true
  3. only speak if it’s beneficial for the people listening
  4. don’t use harsh or harmful words
  5. make sure you speak at the right time and place


Image result for right speech buddhism guidelines

Handling Conflict

Conflict Pitfalls

  1. win-lose—believing that there must be a winner and a loser;
  2. truth assumption—assuming that the other person is wrong;
  3. problem-solving mode—seeing the disagreement as a primarily intellectual issue;
  4. blame game—assigning fault to the other person;
  5. artificial harmony—ignoring conflict.

“To skilfully deal with conflict, we must change our attitude: We should no longer see conflict as something that produces winners and losers but as an opportunity to connect, learn, and generate mutual gains.”

Artificial Harmony causes:

  1. Fear of confrontation
  2. Not a priority to resolve conflict
  3. Work Culture
  4. Lack of Trust

Use Non-Violent CommunicationImage result for nonviolent communication

“Conflict resolution is not about winning, retaliating, or putting the other person in her or his place. It’s about developing a shared perspective on what happened, agreeing on the changes required, and re-establishing trust. This requires a willingness to forgive the other person and yourself (Amro 2018).”

Conflict resolution requires all parties to:

  1. co-operate—move beyond blame
  2. take responsibility for their behaviour and feelings
  3. embrace a contribution mindset (Open mindness)

“You can encourage change in another person, but you cannot make someone else change.”

Decision Making

“Determining who makes decisions in an organization is one of the best ways to understand who has the power—who is in control.”

John A. Buck and Sharon Villines

Common causes of poor decision making by Product Leaders:

  • Lack of empowerment
  • Lack of knowledge 

Use a facilitator to support collaborative decision making as groups may:

  1. Be used to senior leader making all decisions (HIPPO)
  2. Low trust – Groups may not be familiar with debate and disagreement – Facilitator can help bring out divergent perspectives safely

Product Leader should not act as the facilitator

Principles to support participatory decision making:

Full participation: Everyone is willing to contribute, and everybody is heard. Nobody seeks to dominate or hijack the decision-making process. Everybody feels safe to speak her or his mind.
Mutual respect and understanding: People make an effort to attentively listen to each other and appreciate the other person’s perspective, goals, and needs. The individuals intend to talk to one another kindly and to treat each other respectfully. 
Open-mindedness: The group members strive to keep an open mind, understanding that everybody holds a piece of the truth and that everyone’s perspective matters. “Ideas should not be favoured based on who creates them,” as Brown (2009, 73) puts it.

Ground Rules for Facilitators (Hartnett 2010)

  1. Always speak from a place of respect for others and assume good intentions on the part of the group members.
  2. Respect differences of opinion and value the diversity of the group members.
  3. Listen with an open mind; be receptive and refrain from making premature judgements.
  4. Speak honestly and openly.
  5. Always stick to observable facts.
  6. Refrain from judging and labelling people; separate individual and opinion.
  7. Ask questions when you sense misunderstanding or disagreement.
  8. Speak up if you have not been participating.
  9. Make room for others if you have spoken often.
  10. Do not interrupt others, but allow a brief moment of silence to let the previous speaker’s words sink in before the next person speaks.
  11. Stay present; do not engage in side conversations or answer messages on your electronic devices.

Participatory Decision Rules:

Image result for participatory decision making rules

Avoid Committees – They drive weak compromises

Image result for camel designed by committee

Tips for successful negotiation (Fisher and William 2012):

  1. People: Separate the people from the problem.
  2. Interests: Instead of arguing over positions, look for shared interests and needs.
  3. Options: Invent multiple options, looking for mutual gains, before deciding what to do. Avoid the mistake of prematurely excluding options and opting for one solution.
  4. Criteria: Use objective criteria or a fair standard to determine the outcome.

Stages of Influence (Voss 2016):

  1. Active listening: Make an effort to empathically listen to the other person while suspending judgement.
  2. Empathy: Understand the individual’s perspective, needs, and interest, thereby accepting that emotions play a major role in how we behave as human beings.
  3. Rapport: Build rapport and establish trust.
  4. Influence: Help the other person let go of her or his position, understand your needs, and look for a solution that addresses the individual’s needs at least partially.
  5. Behavioural change: Agree on an acceptable solution that can be implemented (if possible).

Techniques for negotiation: (Voss 2016):

Image result for voss negotiation techniques mirror


Mindfulness helps you make better decisions for the following two reasons: First, it helps you recognise cognitive biases. These include confirmation bias, the tendency to prefer data that confirm preconceived views; negativity bias, focusing on negative experiences; and overconfidence bias, overestimating the reliability of one’s own judgements, control, and chances of success. Recognising these biases reduces the risk of making wrong product decisions—for instance, disregarding valid data because it does not match your view. Second, mindfulness helps you to be more aware of your feelings—for example, how excited, sceptical, or displeased you are. This makes it less likely that your emotions drive a product decision—for example, that being angry with someone prevents you from paying attention to the person’s valid concerns.

Hold Personal Retrospectives

  1. What did I get done this week?
  2. Which challenges and difficulties did I encounter?
  3. What did I learn? How am I feeling right now?
  4. How did my moods and energy levels develop during the week?
  5. What changes do I want to make next week?

There is more to life than work.

60 Second Summary: The Unicorn Project – Gene Kim

3 Big Ideas:

  1. Five Ideals: Locality and Simplicity; Focus, Flow and Joy; Improvement of Daily Work; Psychological Safety; and Customer Focus.
  2. Create a “Rebel Alliance” – A group of passionate change agents with a clear purpose. This emphasises John Kotter Change Management approach – Build a guiding Coalition
  3. Don’t put your best developers in feature development. Put them on developer productivity such as environments, build tools, test automation. This is what great tech companies do.


Better Value, Sooner, Safer, Happier


Microsoft, still has a culture that if a developer ever has a choice between working on a feature or developer productivity, they should always choose developer productivity.

1 Follow Up:

Focus on building a stronger “Rebel Alliance” to create organisational change

The Unicorn Project: A Novel about Digital Disruption, Redshirts, and Overthrowing the Ancient Powerful Order

If you have more time…..

Big Ideas Expanded

Dependencies and Approvals significantly impact flow

Don’t outcast project management group. Take them on the journey with you. The project manager in this story was one of the biggest advocates

In the book there is a strong connection to the State of DevOps survey Most of the drivers described in the survey are highlighted in the book

Employees are often unaware of why existing policies, rules and procedures yet they continue to be blindly followed. This is often the case when safety is low and people are fearful of change.

Factors that reinforce status quo:

  1. Fear
  2. Lack of clarity around goals
  3. High WIP/Busyness
  4. Leaders are difficult to get hold of
  5. Focus on delivery not improvement
  6. Lack of autonomy
  7. Low transparency
  8. Senior Management hold all the crucial information – It is not local to the teams

Most organisations and implicitly designed to maintain the status quo and existing power balances

Focus on finding where the constraint is (TOC) As you improve the system the constraint will move from DEV > QA> OPS > Product > Business – The ideal scenario for most tech companies is where tech no longer becomes the bottleneck. Find the bottlenecks.

A good ratio of UX developers is 1:6 regular developers. UX is a specialist skill. Most companies have 1:70 ratio

Change Management ethos in the book:

  1. Build coalition (Rebel Alliance)
  2. Find Quick Wins
  3. Celebrate Success
  4. Deliver value/Solve real problems
  5. Partnership across boundaries
  6. Brave Leadership – Leaders are willing to lose their jobs for the right thing
  7. Social aspect of teams are amplified – Get to know you colleagues. A lot of the best ideas happened around informal gatherings in bars and hangouts
  8. Tendency to hire people – If this does not resolve the bottleneck it often makes things worse

Prime Directive (Norm Kerth)

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Functional Programming principles emphasised throughout:

  1. Immutability
  2. Disciplined state
  3. Pure functions and no side effects/disciplined states
  4. First class functions and high order functions
  5. Type systems
  6. Referential transparency

Organisations should expect failure and put in adaptive processes to respond quickly to those failures and LEARN!

Only 1/3 of strategic ideas have positive results

< 5% of A/B Tests give a positive result

Increase the rate of learning to increase rate of success

Geoffrey Moore Three Horizons

A lot of companies only focus on Horizon 1. In the book the breakthrough came from increasing focus on horizon 3.

Horizon 3 work requires rapid learning, experimentation. Perfect for adaptive ways of working

Introduce an innovation process to gather ideas from your company.

Horizon 1 and horizon 3 require different kinds of leaders!! Could expand more

Horizon one is the core business, stable, predictable, and bureaucratic. Horizon two are smaller businesses that generate new customers, new capabilities and new markets. Horizons three businesses are the highly innovative organisations that explore brand new, disruptive and risky ideas.

Geoffrey Moore Four Zones

Your internal development tools should be seen as products and managed like products

Developers are the customer

Use discovery techniques to understand what the customer(developers) want

Focus on GROWTH not cost cutting. Growth is more sustainable and promotes better, long term thinking.

Don’t manage dependencies, eliminate them!!

Geoffrey Moore – Core v Context


Reduce focus on context – Increase focus on Core businessExample:

Outsource “context” otherwise it will cause distraction and lack of focus. Many companies incorrectly outsource their core business, often leading to very bad results – for example, outsource IT even though IT now is a core part of almost every business

Engage your employees within the change journey – Ask: What is the biggest blocker to Adaptability? Fund solutions to these problems

CAUTION: When your shake the system it will push back, sometimes with big consequences – In the book a key change agent looses their jobs as senior management to not welcome the disruption to the status quo.

Three Types of culture explore in the book:

The changes discussed in the book allow you to move from a power orientated culture to a performance related one

Case Study to highlight importance of optimisation goal:


What is a Product? Oh no! Not another Product definition

Image result for product owner

Product Backlog, Product Owner, Product Management, Minimum Viable Product. These are just a few examples of how product is referenced across agile literature.

Despite it’s frequency, one of the most common questions I’m asked: What is a Product?

This is a critical question, especially for organisations who look to become product centric, organising their teams and delivery around their core products. These organisations may establish Product Owners so it’s sensible to think, what product will these people own.

There are many definitions such as this and this. In fact, I’ve used both definitions and I even have my own definition.

However, I’ve learned that these definitions don’t really help.

It may help individuals but organisations need shared understanding to become a product centric organisation.

Reframing the question: How do we define product?

Shared understanding does not come through a definition you found on the internet, writing it down on confluence or debating your perspective.

The question requires dialogue, not debate.

In dialogue participants open themselves up to the possibility there may be a different perspective they have not considered. They listen actively and question to help the group to learn collectively. The result is a shared mental model co-created by the group.

Debate Dialogue
assumes there is a right answer – and I have it. assumes that many people have pieces of the answer and that together, they can craft a solution.
is combative – participants attempt to prove the other side wrong is collaborative – participants work together toward common understanding
I defend my own views against those of others  I admit that others’ thinking can improve my own
entails listening to find flaws and make counter arguments entails listening to understand and find meaning and agreement.
I defend my assumptions as truth I reveal my assumptions for reevaluation

From The Magic of Dialogue by Daniel Yankelovich

For leaders attempting to become an agile, product centric organisation, the first step is dialogue.

Bring your key leaders together, with a skilled facilitator, to create your shared answer: What is a Product?

How to measure coaching conditions – The “Agile” Shipping Forecast

The Shipping Forecast is a BBC Radio broadcast of weather reports and forecasts for the seas around the coasts of the British Isles. In October 1859, the steam clipper Royal Charter was wrecked in a strong storm off Anglesey; 450 people lost their lives. Due to this loss, Vice-Admiral Robert FitzRoy introduced a warning service for shipping in February 1861, using telegraph communications.

Wouldn’t it be great to have a similar shipping forecast for agile coaches? A way to assess the conditions we are going to face to enable better coaching decisions. Are the seas going to be rough or smooth? Will the ship sink or swim?

The Shipping Forecast assesses 4 conditions; wind direction, strength, precipitation and visibility.

What would be the conditions of a “agile” Shipping Forecast?

I have identified 5 conditions:

Item Description Why
Shared Why There is a problem statement all involved agree with and are passionate about. With no clear problem definition, people are unlikely change. It is likely people will ask “why are we doing this”
Capacity Change takes time and emotional energy. All those involved need to the time and space to change. This often means reducing work in progress. Adding change activities on top of an already overburdened group is not sustainable. Whilst motivation may be high early on, often efforts will end in the long run.
Management Commitment There is commitment from Management within the organisation.   As high up the hierarchy as possible. This commitment translates into direct action with demonstrable leadership. Not cheerleading from the sidelines. Lack of management buy is citied by many as a primary reason for change failure. Demonstrable leadership by management will inspire change within the organisation.
Safety Phycological safety has been identified as a primary factor in the performance of teams. It is a critical factor in enabling change. Do people feel safe to voice their concerns and opinions? Or is there an atmosphere of fear? Without the right levels of Phycological safety there may be low levels of engagement in the change. There is also a risk of imposed change rather than integrated change.
Stakeholder Support Is there support from the wider community for this change. This could be sponsors, influencers of the work you are doing but not direct contributors Without support from the people around the change, they may put many roadblocks in the way. You may not need direct action from them but you’ll at least need their support.

How could I assess these 5 conditions?

I identified the key questions for each conditions and built a simple survey.

Item Measure How
Shared Why What is the purpose for this change? Ask everyone involved to write down in 100 words or less

Translate into agreement scale

Capacity My team are too busy to improve 5 – Strongly Agree

4 – Agree

3 – Neutral

2 – Disagree

1 – Strongly Disagree

Management Commitment What is the level of commitment from your direct management? 5 – Committed

4 – Supportive

3 – Undecided

2-  Unaware

1- Opposed

Safety How comfortable are you in raising issues amongst the group? 5 – No Problem, I’ll talk about anything

4 – I’ll talk about almost anything; a few things might be hard

3 – I’ll talk about some things, but others will be hard to say

2 – I’m not going to say much, I’ll let others bring up issues

1 – I’ll smile, claim everything is great and agree with managers

Stakeholder Support Our stakeholders are supportive of change 5 – Strongly Agree

4 – Agree

3 – Neutral

2 – Disagree

1 – Strongly Disagree

Each of the results are added up to give a score out of a possible 25.

  • >20: Good (Smooth Seas)
  • >10 <20: Caution (High winds)
  • < 9: Stop (Storms)

How are the results used?

At the start of a coaching engagement.

It helps identify the current conditions within the group/team. The results will help the coach create the engagement actions. For example, if the conditions suggest there is no “Shared Why” it may be a good starting point to run a vision setting session for all involved.

During a coaching engagement.

Conditions change over time so the barometer is used to regularly review. The shared why we created from that vision session a few weeks back, do we still have agreement? The barometer helps give a trend over time which provides further insights.

You can try out the “Agile” Shipping Forecast here: https://www.surveymonkey.co.uk/r/6LWHJSV

Please do share any feedback and I would live to hear more about what conditions would make your shipping forecast?

“They don’t have the agile mindset” – Naïve Realism in Agile Transformations


Have you noticed anyone driving slower than you is an idiot? And anyone going faster than you is a manic?

This is known as the false consensus effect which is the assumption that most people in a situation would behave in the same way as you would.

I was made aware of this bias on the “You are not so smart” podcast where Lee Ross shares details on this and naive realism.

“They don’t have the agile mindset”

Working in agile transformations this is a common phrase uttered by many, including myself. The podcast from Lee Ross lead me to some serious introspection.

When confronted with people who disagree, I can often fall into the trap of assuming there must be a rational explanation. When I’m working with someone who hasn’t yet adopted an agile mindset I think it’s a gap in their mindset that needs to be addressed through coaching, training and other interventions.

What I don’t often think is that I have the wrong mindset.

Naïve realism is the conviction that we see the world in an objective and mediated way. Because of this belief, we think others will share our view. And we think the problem is how to make others see the world the same as us.

I often call upon my experience within agile teams and organisations as a way to influence and convince others of the agile way of being. I often see myself as being enlightened and helping others also have the same enlightenment. This prevents real transformational change from happening. It prevents open dialogue and prevents my mental model to be challenged.

Questions to reflect upon:

  • How do i stay with the not knowing?
  • How do i remain open to the possibility that it is my mindset that is wrong?
  • How do i show positive regard unconditionally no matter the position of the other person?








How to lead a Transformational Retrospective

Do your retrospectives look like this?

Team members walk into the room reluctantly. The Scrum Master throws out the Post-It notes onto the table and asks the team to write down some thoughts. You only have 3 minutes. You stick the Post-It’s on the wall and you dot vote. The top topics get discussed and you leave with some actions, which you never complete. 

This is a simplification but i’ve found it is often a representation of reality. Most retrospectives fail to achieve any serious and lasting change.

Why is this?

I believe a fundamental problem is that often team retrospectives are transactional rather than transformational.

We are all familiar with the agile manifesto value of individuals and interactions over processes and tools but so often we miss the mark in retrospectives. We focus on the tools and process rather than exploring the beliefs, assumptions and fears that are holding the individuals and team back.

I believe we need to value:

Transformational Retrospectives over Transactional Retrospectives

I’ve previously blogged about my experiences as a coach and the difference between transactional and transformational coaching. The same applies to retrospectives which can be defined as follows:

Transactional retrospectives are focused on actions. They are focused on achieving a certain set of steps to move towards some outcome. They are surface level.

Transformational retrospectives are focused on the whole, the individuals, the team, the system.They go below the surface. It helps a team create an awareness of the factors contributing to the achievement of their challenge or goal. Often these contributing factors stem from the teams limiting beliefs, assumptions and values formed from past experiences.


Here are some questions to consider:

  • When was the last time you explored the teams limiting beliefs, assumptions and fears in a retrospective?
  • When was the last time your retrospective led to a transformational shift in team performance?

How do you lead a transformational retrospective?

If you are a scrum master, agile coach or team member you are probably wondering how to lead a transformational retrospective.

As a leader, it is your responsibility to help create the conditions for transformational change. These special moments often arise from emotional and uncomfortable situations. If the right conditions do not exist team members might find it difficult to express their emotions and embrace discomfort.

Creating psychological safety starts with you.

How open are you to embrace the emotion and discomfort?

  • Are you able to ask the powerful and difficult questions that never get asked?
  • Are you open to be vulnerable?
  • Are you willing to show who you really are?

The famous google Project Aristotle highlighted the importance of psychological safety. Within the project was an excellent story of leading by example when Matt Sakaguchi shared his secret battle with cancer with his team:

“….to Sakaguchi, it made sense that psychological safety and emotional conversations were related. The behaviors that create psychological safety — conversational turn-taking and empathy — are part of the same unwritten rules we often turn to, as individuals, when we need to establish a bond. And those human bonds matter as much at work as anywhere else. In fact, they sometimes matter more.”

The next time you lead a retrospective try to remember:

Transformational Retrospectives over Transactional Retrospectives


The 5 psychological barriers to agile transformation

I recently listened to an excellent “You are not so smart” podcast where Per Espen Stoknes talked about the psychological barriers to climate change action.

The messages within the podcast are very similar to the barriers i’ve faced helping individuals and teams be more agile


I’ve taken Per Espen Stoknes 5D’s model and applied it to my context:

  1. Distance –  “Agile is just for software development teams” Many see agile as a distant approach which doesn’t apply to them. This is particularly amplified when teams such as operations, HR and Legal are physically distant from development. Another example is that teams often feel an agile future is too far into the future. If as coaches we say that agile will be a “long journey” temporal discounting kicks in and teams think we’ll just wait for the trend to pass.
  2. Doom“70% of fortune 1000 companies have vanished in the last 10 years”. This is a common quote used to stir up urgency for change. Whilst this statement is factually true, we are psychologically wired to ignore these messages, known as Normalcy bias. Messages such as “The end is nigh” are sent straight to the trash bin in our brains.
  3. Dissonance – If what we know conflicts with what we do then cognitive dissonance kicks in. A great example is when managers know that teams work best when they are self-organised but continue to adopt a command-and-control management style. A manager may explain this away by saying “This team are just not mature enough to be self-organising.”
  4. Denial – Ask most teams and they are quick to say “We are already agile”. Teams often deny that they need to improve. Upon further discussion this is often because the change triggers fear and guilt. Many teams i’ve worked with fear that they will be found out as an underperforming team and thus punished. It’s not surprise that in these cases self-defence mechanisms often trigger.
  5. iDentiy – Agile is a value based approach and requires people to examine their personal values. This triggers a deep identity crisis within many. For example a manager who is asked to give up their management role and become a development team member can trigger a serious identity crisis. It is also important to be aware that people are more likely to to listen to those who share their values. Therefore who delivers the change message can just as important than what is says.

Here are some coaching questions which might help you think of ways to overcome these barriers in your organisation:

  1. How could you create a bridge to connect separate teams so that the feeling of distance is reduced? (Distance)
  2. What would be a more positive way to phrase this? (Doom)
  3. What success stories could i share? (Doom)
  4. What systems can i put in place that allows people to behave in ways aligned to what they know? (Dissonance)
  5. How can i be a mirror to reflect back the dissonance to people within the organisation when it occurs? (Dissonance)
  6. How can i make teams feel safe when they work with me? (Denial)
  7. Who could support me in sharing the message with the organisation? (iDentiy)

The biases mentioned in this blog are listed here:

I strongly recommend listening to the podcast here:




How to supercharge a workshop with Learning Maps

I’m sure we have all been to many workshops and the first thing a facilitator presents is the agenda for the day. If you are lucky this might be on a flip chart or even worse its powerpoint slide 1 of 100. Your initial thoughts, this is going to be a long day.

Introducing Learning Maps

Learning Maps are an interactive and metaphorical way to present your agenda. People learn best through experience so a learning map creates an instant connection to the workshop topics.

Here is a Learning Map I used at a Coaching workshop:

file-1 (1)

This Learning Map consists of the following elements:

  1. A metaphor, in this case an island, which allows learners to connect to the topic in a simple way. The agenda is represented by the different places on the island (Coaching Caves, Lagoon…..)
  2. A mixture of words and images which engage different parts of the learners brain.
  3. Blank space for the learner to record their thoughts before and after the workshop which is good for reflective practice. Also enough blank space for the learner to make the map their own.

My inspiration for Learning Maps comes from Sharon Bowman, author of Training from the Back of the Room. In the book she explains that through Learning Maps learners will:

  • Create visual images of important concepts
  • Engage in a variety of ways to learn: visual/spatial, linguistic, logical/mathematical, and kinaesthetic.
  • Use both hemispheres of their neocortex or thinking brain
  • Lengthen long-term retention of important information
  • Remain involved and engaged throughout the entire direct instruction
  • Leave the training with a visually interesting reminder of what they learned.

So next time you are facilitating a workshop why not try out using a Learning Map. They are a really simple but super powerful tool to help boost your learners experience!