Dealing with unexpected work

Problem Statement

One of my large corporate clients has teams who’re all struggling to cope with what they see as large amounts of unplanned work. There’s a great degree of commonality in the conversations that I have with the teams. Most of them are using Scrum at the team level.

Opening Gambit

The first thing to do (IMHO) is to build a model of the different types of unexpected work that is hitting the team. I usually use “predictability” and “plannability” as my two classifying dimensions. That leads to three types of unexpected work (the fourth category is planned work):

  • Unpredictable and Unplannable. This is stuff that you simply don’t realise is out there. It hits you out of the blue
  • Predictable but Unplannable. You know there are predictable patterns of work, but you don’t know the specifics. For example you know you get about 100 tickets a week from your support queues.
  • Plannable but Unpredictable. You can plan the work, but you don’t realise you have to. For example your priorities might shift towards things further down your backlog.
  • Plannable and Predictable. The ideal case.

Understanding what the categories of the unexpected work can trigger more strategic thinking. For example, you might have a blind spot in your priorities (Note: In this client’s case, they’re using OKRs to articulate intent). You might also determine that you are able to turn down some of these requests (or reroute them to a more appropriate team).

But What About Today’s Symptoms?

The next thing to do, is find out whether it can wait until the next sprint. This allows the team to maintain the momentum in their current sprint while prioritising the new work.

Depending on the stakeholder making the request, your relationship, the amount of power held by you/them, your shoe size, their attitude to hats (*), there may be a right way and a wrong way to approach this. I’ve usually found “young” organisations (from an agile maturity perspective) require more visible signs of authority such as messages like “the Scrum process we’re following has a mechanism for accepting late changes, and they go to the top of the product backlog ready for the next sprint”. In order for the team to maintain a good flow of work, they may also need to schedule in a backlog refinement session to get that new work request ready for a sprint.

What if the work can’t wait?

There will be situations when the work can’t wait even a single sprint and needs to be tackled now. To have a controlled acceptance of the work into the team’s current sprint, it’s worth exploring a few aspects of the work.

  • Does the new work align to the current sprint goal?
  • How big is the new work (for example T-shirt sizing)?
  • Is the work a direct replacement for something already planned?

If the new work aligns with the sprint goal, then the substitution of already planned work can be relatively straightforward. If the new work doesn’t align, or worse, is in direct conflict with the sprint goal, then it’s worth exploring the team’s strategic priorities to detect potential blind spots. If they’ve been able to size the new work, they should be in a position to swap a similar amount of work in the sprint.

What if the team’s not in a position to deliver less than forecasted?

The team might be in some situations where sprint forecasts are used by other teams as part of their planning, and delivering less than forecasted amounts would be problematic. While it’s not a great situation to be in (and is potentially a sign that the overall level of agile maturity is low-ish), it is something that teams sometimes have to contend with.

In this scenario, the easiest strategy is to plan with a buffer. A bit like the old MoSCoW prioritisation technique for timeboxes. The DSDM guidance (the origin of the terms Timebox and MoSCoW prioritisation) typically recommends no more than 60% of a timebox is Must Have requirements (for the scope of the timebox). This means that while the team will deliver as much as it can, consumers of the timebox should only really expect 60% of the total timebox plan with certainty, the remainder being variable.

Buffers work well when they’re in the form of a percentage of remaining time. This means the available buffer drops as the sprint executes. The danger of a fixed time buffer is it’s easy to misunderstand how much change/disruption the team can tolerate towards the latter part of the sprint.

What if the buffer amount needed changes drastically from sprint to sprint?

If the Scrum team is unable to apply any of the previous bits of advice, then there’s a good chance that there is too much uncertainty in the team’s context for Scrum to be an effective team process, as Scrum relies on being able to predict a sprint length into the future. The team may get better results from adopting Kanban as a team process, and tuning their WIP limits to keep enough slack in the system to respond to their changing demands.

Agile Coaching – Building my mental model of a team


This post follows on from Agile Coaching – Building my mental model of a person and also comes into play when I work with teams.

This is a basic model, but it’s been good enough so far

The one element worth expanding on is “Hierarchy”. The reason I find this valuable is simply because of how I engage with teams as an Agile Coach. I’ve never once been directly approached by a team requesting my services as a coach as their initial contact. It’s always been a request from their boss (or boss’ boss) or there’s some form of Agile Transformation in progress and the teams get access to coaches. This engagement often has an element of “something being done to the team”, albeit sometimes only a trivial amount. If I understand how they perceive authority, if necessary I can temporarily align myself with an element of authority they recognise, just so that they’ll listen to me, at least initially. It’s not a long term relationship builder, but it is a foot in the door.


These are all of the constraints that the team has to operate under. This section of the model helps me build empathy with the team, and also helps me narrow down all the possible ways I could help them into the subset that’s the most relevant to them (otherwise I’ll waste their time). The “History” element is particularly valuable as that helps me get underneath statements like “It’ll never work – we tried that before”.


There are two sets of purposes at play when working with corporate teams, typically because the reason the team exists in the first place is outside the control of any of the team members. This duality isn’t usually present in teams that have ultimate control over their destinies.

  • Why does the organisation want the team in place?
  • Why do team members think the team exists?

The “Inner Purpose” element is my representation of the internal monologue in the minds of the team members, combined with how well they form sub groups within the team. By understanding the differences in these two sets, I’m more able to connect with the team as a set of individuals, and also help them evolve towards a team that is as aligned as possible with their externally stated purpose.

I’ve noticed that the more divergent these two models, the more I find “us and them” language and behaviour patterns. I’ve also noticed that in some teams, the “organisation” part can include the team leader.


In addition to the expected benefits of understanding the current state behaviours in the team, I get an additional benefit – it can help me blend into the team, camouflage if you like.

When I first engage with a team, there’s that initial period where no one’s quite sure where this relationship is going. As I’m typically brought in by someone outside the team, I need to stick around long enough for me to be able to help them. The initial period is handled by the “Hierarchy” element described earlier, but there’s a limited window before that perception becomes damaging. If I’m able to integrate sufficiently into the team dynamic, any new ideas or suggestions I offer will feel to them like it’s (partially) coming from inside the team. It belongs to them a little more than if I was thought of as an outsider. That’s the dynamic that I need in order to sustainably help them. Coaching is a relationship after all.

Exploring “Design Thinking” using the notion of a Frame of Reference


This is a short piece aimed at the curious. Someone who’s been exposed to Design Thinking workshops and would like to know a little bit more about just why it works. While it’s helpful to have experienced a design thinking workshop, the lack of exposure can be compensated for by a little imagination.

The Lens

The tool used in this post is the notion of a Frame of Reference. A frame of reference is a complex schema of unquestioned beliefs, values and so on that we use when inferring meaning. If any part of that frame is changed then the meaning that is inferred may change.

A person’s frame of reference is always subject to change. Any new insight, belief or value adopted by a person has the potential to change their frame of reference. While it is far more likely that changes to an individual’s frame of reference are minor, there is always the potential for a fundamental shift in perspective (for example, anyone who’s ever said “I found out about X and it turned my world upside down”).

Some useful links about the Frame Of Reference
Tversky, A. and Kahneman, D. (1981). The framing of decisions and psychology of choice. Science, 211, 453-458.

Problem Solving – Solo vs Teamwork

Using the extremely simplistic model that a person is T-shaped from a skills and expertise perspective (awareness of a broad range of topics and in depth expertise of a specialist area), when a person tries to solve a problem on their own, they’re typically thinking at the limits of their expertise. A bit like the red ellipse in this sketch…

Any new insights they come up with are also likely to also be in the red ellipse, meaning the associated changes to their frame of reference will also be minor at best.

Contrast this to how a collaborating team operates. With the same models, each person in the team is thinking at the limits of their knowledge, but the main difference is that they’re also sharing their insights across the team. This usually means that the changes to an individual’s frame of reference can be significantly greater, as it can be influenced by new insights that they simply would not be able to derive by themselves.

You think differently when you’re in a team

Your Focus Areas Change

A significant part of a good design thinking workshop is a focus on the customer. It’s imperative to build a strong empathic relationship with your customer. Capturing those insights as personas or empathy maps is common. Using the same visual language of T-shaped skills and expertise, the insights that the team derives can be represented as follows

You think about different things when you focus on your customer

If done well, the red T will contain the values, priorities, pain points, motivations etc of the customer. By integrating these insights into the frame of reference of the team members, the ideas that they produce would, almost automatically, have a much better alignment with real customer value and customer priorities.

You Have More Time

Design Thinking workshops have a natural double diamond pattern, with alternating phases of divergent and convergent thought processes.

However, as a participant going through this structure (especially someone who “already knows what needs to be done, they just want to get on with it”) this can feel extremely slow and frustrating.

This “slowness” does have benefits. The main one is that it gives the insights floating around the team much more time to work its way into an individual’s frame of reference and change how they think. In other words, it prevents participants from leaping to conclusions. While there’s nothing inherently wrong about “heading straight to the answer”, the solutions you develop using this type of strategy are not innovative, as by definition you’ve come up with them before. By maximising the opportunities to change your frame of reference, you increase the likelihood that your solutions are much more innovative.

Converting a broadcast into a conversation

This post came about accidentally because of a discussion I’ve been having with a colleague about the Elevator Pitch and how we’ve been trying to use it as part of a vision statement. I say “trying to use it” as my team’s primary service is that of organisational change via agile transformations, and the product isn’t as tangible as real-life products like bicycles, cars etc.

The context we were discussing, was early on in an engagement, soon after when a client “buys an agile transformation from my employer” (and I’ll park my many issues with that statement – see things like this to give you a sense of how long I’ve been carrying that baggage). One of the first tasks is to broaden the awareness of what’s going to happen to the client’s employees and some lightweight communication & broadcasting is a typical medium for starting this awareness drive. As the elevator pitch is a natural fit for lightweight, accessible communication, it’s a fairly obvious choice as one of the tools to be used.

What’s the problem?

One of the common mistakes that I’ve seen with teams producing elevator pitches, is they spend most of their efforts trying to craft the perfect words to get across the sheer breadth and scope of what it is they’re trying to achieve. The work itself is rewarding, as successive iterations of the elevator pitch can heighten the emotional connection between the team and their product. Teams often hope that the energy and enthusiasm that they display while giving the elevator pitch is infectious enough for their audience to engage. To my mind, that approach is inefficient and can be ineffective. I also feel that strategy does not respect the perspective of the listener – there’s a good chance that your listener is not a “willing participant” (i.e. they’re already overworked and there you are trying to pitch something to them – even the apocryphal story of the lift journey has the CTO “trapped” in the lift with you).

Get to the conversation bit already!

A real conversation between two people only really happens when both people are listening. When working with elevator pitches, it’s not certain whether or not your target will actually be interested in listening. While that’s out of your hands, the amount of energy and effort they have to expend to begin listening to you is partially under your control. By lowering the barrier to entry, you have a chance at making it much easier for your target to engage with you. It’s what makes snake oil salesmen so effective – they understand what their victim want to hear, and know how to give that message in a way that’s captivating specifically to them

By making sure your content and your expressions use the language and semantics of the person you’re trying to reach, you drastically reduce the cognitive load that person has in order to understand what you’re saying. Otherwise they’d have to translate what they’re hearing into what they can understand. Which can be hard work, and if they’re not already invested in you, it’s quite easy for them to avoid the effort and delegate the task to one of their direct reports. Which essentially defeats the point of having an elevator pitch in the first place. By putting in the additional effort to make it easy for your target to consume your message, you also demonstrate a degree of respect of your target’s time.

A useful effect of this degree of tailoring of your content, is that aspects that may be unimportant to you would gain prominence in your message if it’s important to your target. Most organisations have very fragmented views on what is important, and a single unifying elevator pitch can be very hard to create, and may not have the impact you desire. By tailoring, you significantly increase the chances of making meaningful connection with your audience, one person at a time.

Use Personas

A good way to start this tailoring, is for you and your teams to create personas representing the people you wish to connect with, and then create tailored elevator pitches for each of these persona. Empathy maps are especially helpful in this regard.

It’s possible (if the personas are different enough) that different personas may prefer different communication channels or media. Some might prefer an informal conceptual discussion over a coffee, while others might like to see more tangible aspects as part of a guided demo. By creating models of your potential audience, you greatly increase the relevance of your content to them.

A meeting with a nervous CIO


I very recently had an interview for a broad coaching role and I wasn’t happy with the answer I gave to one of the role playing scenarios. This post is me getting the jumbled up thoughts under control and structured in a more coherent form, so hopefully if the scenario happens again, I’ll be much clearer.

The Question

Discussion with the CIO of an organisation. They’re trying to transform their organisation (7000 people). Essentially, their strategy distils down into a conceptually three stages of “train everyone” – “change the way of working” – “see how it goes and evolve”. The exam question was “I’m nervous, am I missing something?”.

My refined Answer

Firstly I’ll define your organisation with a boundary containing two fundamentally different processes:

  1. Organisational processes. These processes collectively define how your organisation behaves. Transformational change only occurs when these processes evolve. The key ones are
    1. interaction processes (communication)
    2. visioning processes (purpose)
    3. motivating processes (alignment)
    4. learning processes.
  2. Operational processes. These processes collectively define what your organisation does and simplistically, all other processes belong here. Continuous and incremental improvements happen when these processes evolve.

Agile and Training

Next lets look at “agile”. There are two main parts that I want to cover. The mechanical elements such as practices, techniques – the “how to do agile”; and the behavioural elements such as mindset, principles, values – the “how to be agile”.

Training can provide awareness and skill. Skill in the mechanical elements, and awareness of the behavioural aspects. Learning and improving skills can be done in a training context. However, changing established behavioural patterns is an internal struggle and takes time and requires support.

This means that your training-based transformation strategy can potentially deliver incremental improvements (Scott Ambler, from Disciplined Agile Delivery has been running a long standing agile survey that has helped him determine that adopting the mechanical aspect of agile methods can realistically yield a 6-10% improvement in overall effectiveness these days). However, this strategy is unlikely to deliver transformational improvements.

From training to coaching

In order to make a lasting effect on the organisational processes, additional leadership coaching should be employed. As a leader, you have to set the example that you wish your organisation to follow, as your behaviour patterns will be emulated through your direct reports into your organisation. Like it or not, you are one of the coaches that influences your organisation’s leadership community.

The Servant-Leadership model has a natural fit with an agile culture and elements can be incorporated by your leaders into their leadership styles. The greater the adoption, the easier it is for their part of the organisation to evolve into a more agile culture.

Evolving your management

Any changes to your organisation’s leadership models will almost certainly require changes to your management methods and measurements.

Note: This might turn into another post.

Things I read to help me articulate this


Agile Coaching – Building my mental model of a person


I’ve been thinking about how to remain effective as an Agile Coach while not being co-located with the entity (person / team / project / programme) that wants to be coached.

While a long term viable solution might be for me to rebuild my approach from the ground up as a “remote native” thing, I reckon my MVP is to patch up my existing process (see “The anatomy of my typical coaching engagement“) so that it is still fed with as rich a dataset as possible.

Mental model of a Person

Mindmap of the categories of information I use to build a mental model of a person
This is the mental model I generally try to build of each person I work with as an Agile Coach.
  1. What they do
    • things like their role, career history, future plans, what’s their speciality in the team etc.
  2. How they think
    • things like how they build their mental models, how they make decisions, how they prioritise etc. I also look to understand how they see themselves.
  3. Main character traits
    • things like whether they’re an extrovert, are they motivated by fame/recognition/peer acceptance, how they respond to stress and challenges etc.

I’m also looking to distil all this into some insights into what they feel is important, what they see is urgent and what they think they must avoid.

Benefit I get from using this model

The core benefit I get from populating this model of my coaching client, is it gives me a far richer relationship with my client, which typically translates into better / more accurate communication. These are some examples.

  1. By learning about the “What They Do” tree, I’m able to work out if I can mentor them, or who would be a good person to mentor them and help them progress from Present to Future Ambitions
  2. If I can combine aspects of “What They Think Is Important”, some of their Character Traits (e.g. Individualism or Collectivism) and that is either something I align with OR can mimic sufficiently to communicate, I can begin to build rapport with them. Rapport is the first step towards trust.
  3. If I understand “How They Make Decisions”, it makes it easier for me to structure a compelling argument, thereby increasing my levels of persuasion.
  4. If I understand how they’re motivated, that can also support my ability to structure a compelling argument.
  5. If I understand how they manage their risks, and what they’re trying to avoid, then not only does it help me structure an argument, I can help them think about relevant risk mitigation strategies.
  6. If I understand “How They Make Decisions”, and can describe it to them in a way that makes implicit processes more explicit, I have a chance to help them learn about new thinking models and they can devise new problem solving strategies.

Building this model


This is the easiest scenario. Much of this model can be built by forming hypotheses informed by the actions and behaviours that I observe. The person is also accessible so that I can discuss my models and predictions and see how close I can get to what they think. The main challenge is the amount of time it can take before some of the deeper elements can be inferred / estimated, if for no other reason that it requires a great deal of trust and honesty between the person and I, and that trust takes time to build.


Conceptually, my starting point was to find techniques for collecting the same raw data that worked with the alternate channels available – voice & video calling and email / written form. As everyone else was in the same boat, they also would need to work out digital equivalents for their normal team ceremonies and so I could piggy back and observe those easily enough.

I quickly hit a problem. While this approach was fine and would yield accurate data for the known unknowns (see this post for some context) such as the “What they do” sub-tree, it is easily corrupted into opinion (e.g. “How they think”) or even a duplicitous facade, portraying a view that they believe is socially acceptable even though it’s not the reality (e.g. “Character traits”).

I’m currently exploring what I can infer reliably from more open “essay writing” styled requests. For example:

  1. Please describe your recollection of the last completed iteration, highlighting the events that you personally saw as significant for your role in the team.
  2. Please describe the events during the iteration that led you to believe for the first time that your iteration goal may be at risk unless you and your team were able to get on the front foot.
  3. Please describe the events that led your team and product owner to collectively agree what stories were going to be brought into the current iteration.

I’m exploring the different perspectives each team member has on the same shared experience. My hypothesis is that it’ll give me a few insights into how various team members think (relative to each other, as it were) and maybe a few nuggets about some of the more prominent personality traits that I need to pay attention to. I’m also hoping that the different language styles would be useful, but it seems a bit too early to tell.

Creativity and thinking

There seem to be a couple of analogies to try and understand two types of thinking (focus time and diffuse time) – the pinball one, with either close pins or separated pins, or the two types of flashlight, either a tight beam or a wide beam. Of those two I prefer the flashlight one. I’m more used to it because of how I ride a bicycle at night – I use two torches. A wide beam mounted on my handlebars and a tight focus beam on my helmet. The wide beam gives me contextual information, and an overall view of the bike trail. The narrow beam floods a small area with light to help me see subtle details that can affect how I tackle the hazard that’s coming up. The beam also moves around as my head moves, so I’m gaining the maximum amount of information possible while maintaining contextual awareness.

When I’m “in the zone”, I’m focused on a rational line of reasoning. Observation leads to conclusion (usually via hypothesis but nobody’s perfect). I can follow a line of reasoning through some pretty large interim steps. Overall, it seems reasonably clear what the focus time thinking can do for you. It’s the algorithmic stuff. Rational problem solving, the kind that ends in “QED”.

So what does the diffuse time give me? Rest? A diversion? Daydreaming? The bits I can identify seem to be all related to one core concept – patterns. The detection of patterns; the use of these patterns as reference points to remember other themes/concepts/”things”, regardless of how unrelated, as long as they too exhibit these patterns. Sometimes not even based on memory, but the use of imagination to invent a plausible “thing” that could also exhibit these patterns. Basically, these are analogies. These can be useful, as it’s possible to use these patterns to influence focus time thinking to go places that aren’t always obvious. In any case, it seems to be a useful mechanism for keeping potentially useful thoughts churning in my mind, in case serendipity strikes.

This leads me to conclude that being creative(*) requires both, a bit like the analogy of the two beam types on bike lights. The wide beam diffuse thinking to generate a whole bucketful of ideas, and then the narrow beam focused thinking to see what each of these ideas can mean. But if that’s true, where do you start? Which idea needs the narrow beam focus first? Perhaps part of the analogy generation process is some form of weighting factor, that’s a guess as to how likely the idea will generate something useful. I suppose that “magic number” is dependent on past experience, skill, perhaps just blind luck. A bit like deciding which is the immediate obstacle that I need to ride over, while also paying some attention to the next one, and the one after that etc. Occasionally I’ll get it wrong and fall off.

Not too sure how this model of thinking will help me. Perhaps I can describe this stuff to one of my colleagues who seems to be stuck on a hard problem, who knows. The only thing I’m reasonably sure of is this aphorism:

All models are wrong. Some are useful.

Hopefully this model of “how creativity works” will be useful to someone else at some point. With practice, it becomes easier to either focus in or let my mind wander and daydream. Something like this also sounds like fun, though it may be “unpalatable” in some work environments…


(*) I think being creative has to be more than ideas – you’ve got to do something with them.

Constructive Feedback during Group Exercises

What do you do if you’ve got a team doing something and you’ve got a mix of abilities in there, and some people are switching off because they’re bored?

I had that happen to a particularly bad extent in a recent classroom (team based research, ending in a report back and a discussion). There were a couple of people in each of the teams that understood the subject a lot better than the rest of the team and were bored with the rest of the team’s discussion. There were other things happening to them that were completely out of my control, which would have magnified the effects.

My typical approaches of nudging participation from the “bored contingent” weren’t having as much of an effect as usual. Having deep dive conversations as part of the report backs were also only partially successful, as we couldn’t explore a topic in too much “academic detail” as we’d lose part of the room.

Thinking back, perhaps one thing that could have helped was asking this open question, for individual contemplation:

“Do you think your report backs were the best you could have made them? If yes then cool. Great stuff. Learn more and improve. If no then tough, it’s not about you and what you could do, it’s what your team actually does. So how do you help your team be the best team it could be?”

Might also need a more positive line, for example “Teamwork isn’t about individual recognition, it’s about collective glory. You’re measured as a team not a set of individuals. And the whole team needs to be part of the work to feel like they’ve deserved the win.”

I’ll try this the next time it happens and see how it goes. Hopefully it’ll encourage some of them to adopt a more coaching/mentoring style to the work, which should help. Who knows, they might even enjoy the experience.

Obligatory First Post

Hello World

I’ve been making lots of notes in all manner of notebook (hardback spiral notebooks were a special source of joy for that extra-close-to-the-margins writing) about how well or badly my coaching attempts have gone. I used to use them as fuel for conference submissions, but this year I thought I’d try something else.

I can’t promise you a life changing post. Or even a relevant one. When I write one of these entries, I’ve only got two “people” in mind – me and the person / team / project / whatever I’m trying to help. I get to do some thinking to learn what I can from the experience, and hopefully they get a memory aid to help them get better at whatever it is that they’re trying to do. If you’re able to get something useful from any of these posts, that’s a great bonus.

I’m also not entirely sure what this site will end up looking like. So rather than overthink it I figure I might as well start somewhere and see how it goes.