Leave a comment

Digital Transformation – How do I do it?

The latest buzzword in the industry is digital transformation. This replaces agile transformation, which was in vogue around 10 years ago. So what do I mean by this and how can I achieve it?

To transform is not simply to replace and tweak software. Companies are running digital projects such as rewriting an out of date technology platform and now labelling it digital transformation. In these cases the new system is typically better looking and easier to use but includes very little real change. True digital transformation is creating new business models using digital technologies. So what are the building blocks of this transformation?

  1. Understanding your product or service from a customer’s perspective
  2. A willingness for a business to change its processes, people and structure
  3. A technology stack that easily supports incremental change
  4. Seeking rapid feedback loops

1. Understanding your product or service from a customer’s perspective

In order to truly transform your business you must know what is working well and what is failing from a customer’s perspective. Otherwise you run the risk of making things worse and building pointless product features. To do this user research can be translated into tools such as the customer journey maps and the value proposition canvas. Once we have this insight we are now ready to build the right thing. History is littered with companies that didn’t transform, consider Kodak who made kept making film and ignored the digital camera.

Let’s use a loan application at a bank as an example of how user research can help. Feedback highlights that you have a big issue with customers dropping out when they are being asked to fill in all their personal details. Your user research highlights they are annoyed as they are already being a member of the bank and you have these details already. Without this customer feedback it doesn’t matter how good we make the application process, it is fundamentally floored. Simply looking at metrics on the website showing high drop out rates and A/B testing different versions won’t fix it.

2. A willingness for a business to change its processes, people and structure

It is pointless to attempt to improve a product or service if the underlying organisational structure is not in place to cope with it. Imagine attempting to combine a registration process for loans and insurance but each department insisting on keeping it’s own customer management process separate. You are fighting a system here and things will not end well. It is necessary to have a senior stakeholder with the ability to implement business change here. Any proposed features / projects can be assessed against business change impact so that you understand how easy it will be to build them. Assign business change experts to your project to ensure that the project succeeds.

3. A technology stack that easily supports incremental change

New business models can be especially difficult to implement if the technology stack you are on is monolithic and hard to change. If it is one large stack with intertwined functionality this can hamper your speed of change. As you change something it has a ripple effect through many end to end scenarios in your system, the impact of which cannot easily be assessed without extensive testing. Consider moving towards micro services with their own deployable pipelines. De-coupling these services will allow you to release change faster. Get your software under automated tests to improve the speed and reliability of your software releases.

4. Seeking Rapid feedback loops

Digital transformation can be a risky proposition as we’re moving to a new business model and potentially investing significant time and expense. We need to know quickly how successful we’re going to be. Here are some enablers:

  • Seek feedback at the ideas stage, using UX or wireframes with real customers
  • Build the smallest possible software product to deliver your new idea quickly (MVP)
  • Decrease your time to market by improving deficiencies in your build pipeline
Leave a comment

Are you a failing Scrum Master?

I have number of concerns with the typical view of what an effective Scrum Master looks like. This post is designed to evaluate how successful a Scrum Master is when there is more than one Scrum team, other types of teams and management involved in a project.

Take a look at a number of articles around the web and you’ll find questions like these (a small subset) associated with being a successful Scrum Master:

  • Am I tracking and dealing with impediments?
  • Is my product backlog being managed?
  • Is my team clear on the sprint goal?
  • Do my team feel accountable to each other?
  • Does the team get on well?
  • Is a suitable amount of inter team communication happening?

There is nothing wrong with these types of questions however I believe they aren’t sufficient when assessing performance within a multi-team set up. I’ll start with a simplified section describing a typical Scrum Master who is working well with their own Scrum team. From there we’ll consider additional factors to see how well the Scrum Master is working within a larger project context, and generate some new questions to help judge their successfulness. I’ve put all of these new questions together at the end of the post in case you wish to copy them.

The Scrum Master working well for their team

Most Scrum Masters are good facilitators, they help the Scrum team tune their processes, resolve conflict and encourage co-operation. They can help their team externally by raising their impediments and attending external meetings to discuss their teams progress and concerns. Scrum teams, like any other type of team, typically go through a cycle of forming, storming, norming and performing (Bruce Tuckman 1965). They do this at a reasonably fast pace because they’re all working together on a common goal each sprint and have a lot of face to face communication to achieve it (assuming they are co-located). The Scrum Master can help ensure this transition is as smooth as possible by being a mediator when conflict arises and looking out for unconstructive arguments happening between team members.

There are other parts to the Scrum Master role I could delve into, however there is little disagreement about what makes a good Scrum Master when representing their own team. Let’s look at how the Scrum Master can cause a multi-team project to fail despite being effective at a team level…

The Scrum Master at the project level

In this section I’m going to focus on how a Scrum Master can be judged for effectiveness across a multi-team project. If you are a Scrum Master consider using the questions here for self reflection, or run a session with others on your project to help you all improve.

Forming, storming, norming, performing across teams

Following Bruce Tuckman’s model that we’ve already looked at, Scrum team members may actually stay in a state of storming with external teams all the way through the project. Direct conflict may not be occurring but replaced with complaining and finger pointing behind the scenes. As a Scrum Master you may be one of the few people to see this and do something about it. You can facilitate improved co-operation and better outcomes. These types of behaviors are really bad if you are a Scrum Master and doing this yourself, as there may be no one to stop it. It can be tempting to automatically take your teams side when presented with conflict too, and although this builds up your own team, it can destroy trust and damage the wider project.

  • Do I actively monitor and resolve conflict between my own and external people?
  • Do I tend to take my own teams side when there is an inter team or management conflict?

Process conflict

If you are involved in an argument about a process that actually results in the same output, then why are you arguing? This is typical of a “best practice” mentality where only one way of doing things is seen as valid (typically your own). Concentrate on the quality of the outputs rather than the processes used to create them. An example I have seen of this was where an argument kicked off around how to run the sprint planning meeting, with one Scrum Master insisting on story tasks for each story and another insisting they are a waste of time. I’m not going to cover the pros and cons here, but both teams were producing good outputs using their chosen process.

  • Do I appreciate that in some cases different internal team processes can produce the same outputs when seeking to resolve conflict?


In some people’s view they would see management as unnecessary, I do not ascribe to this. Although you can argue this point, if you are in a role where you are reporting into a manager then this section is relevant. You cannot simply get rid of that person(s). Typically managers who sit across Scrum teams perform a role with responsibilities like these:

  • To formulate and share the big picture.
  • To be a central point for reporting project progress.
  • To facilitate the making of key decisions and sometimes make a call where consensus cannot be reached.
  • Represent the project teams as the primary point of contact for outside structures.
  • Help remove organisational impediments.

I have seen behaviors where individuals at the Scrum team level seek to take control of a project and cut management out. This causes major issues for the project, where management start to see unexpected impact from hidden decisions that can conflict with the big picture strategy they have in place. The manager who is representing the team is then not reporting accurately, ultimately undermining the project by losing control of the big picture. At a minimum it is courteous to involve a manager in a potential decision that affects the whole project. Ideally a clear justification for a change should be made too, so everyone is lined up with why a change is needed. There may be good reasons you don’t know about for previous decisions being made.

  • Do I fully understand the role of my manager(s) and how it relates to the rest of the organisation?
  • Do I understand that the management team are part of my team and are there to direct the big picture?
  • Do I involve management in any project wide changes that my team or I wish to make?

Scrum of Scrums

Here are Mike Cohen’s questions (link below):

  • What has your team done since we last met?
  • What will your team do before we meet again?
  • Is anything slowing your team down or getting in their way?
  • Are you about to put something in another team’s way?

Link accessed 26/09/2015:


I’m actually going to critique these questions as I personally don’t agree with them. See what you think about my argument. When listening to others people’s answers, except for the fourth question do you even care about this information?! With a team focus it is easy to ignore the answers. Take the first and second questions, is a detailed update on task level information for each story useful? Is progress for each story useful? As a more important question, do you really care what another team is doing? Taking the third question, are you bothered about what is slowing another team down if it doesn’t affect you? In the final question consider moving this to sprint planning, which is a great place to assess impacts, and wouldn’t result in late impact notifications. Think about inviting a member of another Scrum team along for them to see if they are about to get impacted. Your team may have a poor understanding of what the other teams have been doing and have no idea that they are about to break some new work that another team are going to do. Now I will recommend a different set of questions:

  • What is your team delivering to another team (name them) and when will it be ready?
    • Example: My team are working on moving the new test data into your environments this will affect everyone and it’ll arrive on Friday.
  • What is slowing down your team or getting in their way that you expect someone else here to help you with (name them)?
    • Example: My team is finding the current application server too slow and need help from Bob.
  • What is your team going to do that you expect to break someone else’s work (name them)?
    • Example: My team is going to change a person titles table name, it will break all the related tests.
  • My team is currently on / off target to achieve their sprint goal and I intend to fix this by (if off)?
    • Example: We are off target to deliver, as the new computers aren’t here yet, I am talking to Phil about this today.

Except for the last question this is far focused on resolving inter-team dependencies. It means I am making statements that people care about rather than random status updates. Look for long running items that need to be planned in or solved as a group. Many of these questions can result in long term concerns being raised.

  • Do your team impact another teams without sufficient warning?
  • Are you being impacted by other teams without sufficient warning?

Long term technical debt

The problem I’ve seen here is that teams will often create ways of avoiding dependencies rather than actively solving them. Creating two versions of tables, two sets of tests and only running their own etc. We can actually cheat these dependencies by storing up technical debt that will have a major impact on the project later on. As a Scrum Master you need to be looking out for these issues. If there are dependency failures then you should look to facilitate better ways of working rather than workarounds.

  • Is your team building up technical debt to avoid inter-team dependencies?

Scrum Master to Scrum Master relationships

In this case we are looking for silo focused behaviors caused by the Scrum Masters definition of success being their own team’s progress, rather than success being viewed at a project level. A pure focus on team success leads to Scrum Masters ignoring the other teams unless they are directly impacted by them. If they are impacted this typically results in annoyance and a blame culture ensues. Look out for a lot of issues being escalated to management when this is happening.

  • Are my relationships with other Scrum Masters positive, collaborative and ultimately successful?

The big picture view

Here we see the Scrum Master helping to facilitate project understanding among their team. They may prompt management for more information if they are not getting it. A failure to understand long term project goals, timescales and project inter-dependencies can lead to teams running blind and making poor and expensive decisions like overbuilding areas of a system at great cost.

  • Do my team and I understand the whole project, its timescales, major milestones, goals and how we fit within it?

Retrospectives and change

Retrospectives will highlight where something is not working well. That is fine until we try and make changes locally that affect everyone else. Scrum Masters should pay careful attention to wider team impacts from retrospective items. A team who dislike how testing is done should not simply change the way they test. These action items should be moved to a cross team discussion. They are still valid but changes must be made with the other teams in agreement or the project will break. Management should also be invited to these sessions to understand the impact. Changes may occur outside of the retrospective meeting but the same principle applies.

  • Do I ensure that when my team wants to make a change that affects everyone it must be agreed with everyone?

In summary

These are the questions I’m adding to the Scrum Master role:

  • Do I actively monitor and resolve conflict between my own team members and external people?
  • Do I tend to take my own teams side when there is an inter team or management conflict?
  • Do I appreciate that in some cases different internal team processes can produce the same outputs when seeking to resolve conflict?
  • Do I fully understand the role of my manager(s) and how it relates to the rest of the organisation?
  • Do I understand that the management team are part of my team and are there to direct the big picture?
  • Do I involve management in any project wide changes that my team or I wish to make?
  • Do your team impact another teams without sufficient warning?
  • Are you being impacted by other teams without sufficient warning?
  • Is your team building up technical debt to avoid inter-team dependencies?
  • Are my relationships with other Scrum Masters positive, collaborative and ultimately successful?
  • Do my team and I understand the whole project, its timescales, major milestones, goals and how we fit within it?
  • Do I ensure that when my team wants to make a change that affects everyone it must be agreed with everyone?

I’m sure there are more you can come up with and I’d be interested in knowing if you agree.

I’m sure there are more you can come up with and I’d be interested in knowing if you agree.

Leave a comment

Metrics That Destroy Your Organisation

In this post I’m going to show you the serious effect metrics can have on your organisation and customers. At the end of the post I’ll also offer some practical advice on how you should apply this information.

Short Term Effects of Metrics

Let’s start with a simple example of the effect of setting a sales department two different metrics:

  1. Time to sell a product
  2. Customer satisfaction

Note: I am not suggesting to just have one metric in a department this is purely an example. The negative effects are most likely to occur if you have no customer related metrics. 


  • Time to sell a product:

We can see that the department have met the metric of time to sell products by reducing the quality of sales provided to the customer. To meet the target the department has also cut back on product customisation meaning the customer is less happy when they get the actual product.

  • Customer satisfaction:

In this case we can see that the department met the metric of customer satisfaction with a more tailored product coupled with more in depth demonstrations to the customer. This resulted in a better final outcome that made the customer happy.

When measuring revenue the focus on time to sell a product may give a a short term win only to see customers desert the company a year later, so be aware of delayed feedback even if things seem positive. There would be nothing wrong with having both of these metrics in place as long as the trade offs were understood.

Long Term Effects of Metrics

Now let’s look at the more serious effects of metrics appearing in the long term. The department has decided to invest money into improving the time to sell metric by speeding up quotes. Inadvertently this may put more pressure on the customer and actually lead to a lower satisfaction rating.


The long term effects of concentrating on the wrong metrics can result in more and more detrimental changes. At the worst case the customers may disappear and the organisation collapse.

Metric Affect Processes

Over time the processes of the sales department will be aligned to meet the metric, which has become the artificial measure of success. Those processes can get more and more complex to meet targets that are actually damaging the organisation. In many cases the feedback from the people talking with customers will simply be ignored, as it does not benefit the head of department’s review.

Customer Centricity

Typically we would see each department with its own set of metrics and meeting those being the measure of success or failure. For example the sales team measure themselves on speed of receiving money, and the product delivery team on time taken on a client’s site:


In this organisation there are major delays between sales and product delivery that are not picked up by those metrics.


By shifting to customer satisfaction across the whole offering we would see this. Customer centricity moves us towards the customers view of how they interact with the whole organisation. It moves the metrics and processes optimisation to centre around the customer’s experience.

Customer Centricity = Shifting Project Funding

Here is a typical funding structure for projects where money is allocated to each department.  Localised departmental improvements are being made. These projects are affected by the departmental metrics.


With a customer centric approach a wholesale shift occurs in project funding. Rather than localised departmental improvements the portfolio of projects is now based around the customer’s view. This may mean that some departments receive very few projects and others receive a lot:


Customer centric metrics focus on the end to end experience of the customer and their journey through the organisation.

Using This in Real Life

When seeking to invest in improvements it can be tempting to  start by going in and looking at business process efficiency or what an internal employees think of their processes. Here is what you should be doing…

Evaluate the situation:

  • What do your customers think of the whole service?
  • What are your department’s metrics that currently define success?


  • Align the project portfolio around the customer experience.
  • Align the departments and organisations metrics around the customer.
1 Comment

Avoiding Project Disasters

I’ve been spending some time thinking about how projects start recently, and looking at the ideas that are generated to create new products. So I thought I’d write a post on this to give some hints and tips on ensuring you build the right thing.

Here are the two key stages that occur when starting projects:


So this is obvious? Well you’d think so, but we can go badly wrong with these steps because of our assumptions:


Let’s deep dive into this…..


Assumptions about Problems:

Let’s start with the assumptions made about the problems that users have. Here we’ll look at some silly examples (OK if these turn out to be the idea that becomes the next big thing just give me a cut of the profits):

  • Cyclists can be seen most of the time but not necessarily heard and need something that makes a constant noise.
  • Walkers need a mobile gaming system they can play whilst being able to see where they are going.
  • Setting up dates is a pain so what people need is a service that takes them to a random local place to meet.

Subtle Assumptions about Problems:

Some start-ups have died off because of crazy assumptions about what a user needs. However although the crazy examples are often easy to spot, things can be FAR more subtle than that:

  • Customers aren’t buying on our system because they can’t do one click credit card payments.
  • Customers love our products but are put off with the decor in the shops.
  • Our customers aren’t happy with our current paper process because they hate filling in forms.

Our assumptions can creep in all over the place and some of these can cause costly mistakes. These are hard to spot, they sound sensible and logical.

How to Avoid Assumptions about Problems:

This is where user research comes in. There are many techniques such as surveys, ethnography (going and seeing what they do in practice), interviews, group discussions etc. All of these seek to validate assumptions:

  • Customers aren’t buying on our system because they can’t do one click credit card payments. Real problem: Cost of postage is very high and when they come to pay they drop out.
  • Customers love our products but are put off with the decor in the shop. Real problem: Two large security guards at the front door are putting people off entering.
  • Our customers aren’t happy with our current paper process because they hate filling in the form. Real problem: We don’t warn them to bring ID then when they get here they have to do two trips.

Any project that runs with unvalidated users needs is at risk of failure or even making things worse. Your product owner can mask serious issues by sounding like they know what they are talking about. They are not the user, make sure you validate any opinions.

To Summarise….

Get your  users to tell you what they need, and if you are trying to improve a product ask them where their current pain points are.


Assumptions about Solutions:

Typically having validated the needs of the user we then look to create a solution. Those solutions can be completely unsuitable. Let’s use some real ones!:

  • My dog needs water
    • Create flavoured bottled water for pets
  • People like to smell nice
    • Harley Davidson cologne

OK those flopped, so let’s look at some more subtle issues where solutions appear to be very sensible:

  • A loan system where you have to use sliders to see costs. Result: Doesn’t work well on mobile devices.
  • A system that is accessed with a password on a computer keyboard. Result: Doesn’t work well in a dirty environment.
  • A tablet application for airport staff. Result: Doesn’t work well outside.

How to Avoid Assumptions about Solutions:

Again this is where the disciplines of UX design and interaction design can help. There are many techniques such as prototypes – high fidelity interactive / paper, wireframes etc.  All of these seek to validate assumptions about the solution(s). Seek rapid feedback on your solution(s). The best feedback is when the product is live!

To Summarise….

Get your users closely involved when designing your solution until they get what they want. Get your product out there as fast as you can by cutting down features, you can add more when you know you’re succeeding.

Leave a comment

Feedback Loops in Agile

Feedback loops are one of those things we all know something about, from the annual review process, to the speedometer on the car we are driving, we are receiving feedback from the world around us that we can act on it. After looking at a typical Scrum based project, I will show how feedback is a critical part of agile by mapping it to the principles. Built into the principles there are feedback loops used to…

  • find out as fast as possible if the project outcome will result in the expected benefits
  • improve the project outcome
  • ensure the software works properly as early as possible
  • ensure minimal effort is expended on re-work throughout the project
  • ensure that the software is built as efficiently as possible
  • ensure that collaboration and learning is as efficient as possible
  • improve the way the team works together

Feedback in a Scrum Based Project

Here’s a simple example of a Scrum based project set up. Within the sprint each story is worked on, then demonstrated in a show and tell at the end of the sprint. Finally there is a monthly product show and tell that gives a few key stakeholders the big picture view. Note: this picture purposefully shows the delivery stages being completed one after another to simplify the example described below:

Story Feedback

Consider the increasing cost of receiving feedback from a product owner or user as we get further through the stages. If these people were to tell you that the process you have designed was completely wrong during the Story Acceptance Criteria and UI Design stage the cost of change would be minimal. If this feedback was received as late as the monthly product show & tell we would obviously see a high cost to fix (or throw away). There is an additional hidden cost of re-learning (one of the seven wastes) when we go back to the problem and re-analyse it, which can make things much worse if the feedback is slow. Building feedback in to this model to be early and often greatly improves the situation and helps us remove the poor practice of completing stages before seeking feedback. Now let’s look at the agile principles and how they have feedback built into them:

Agile Principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Projects range from high risk new ventures, typically start-ups, through to those with a definite need such as operating system upgrades. In business we typically release products into the marketplace with some degree of risk. A really dangerous situation occurs when we find ourselves assessing the risk incorrectly, we are so bought into our project or feature idea that we actually think it’s certain to succeed, until it doesn’t. We can get feedback from those people who are not customers to positively re-inforce the likelihood of success leading to more delusion. Ultimately we look to improve on uncertainty with factors like previous experience to lower the risk, however it is better to get real feedback. Agile has this principle of delivering to customers early in it to lower the risk of failure by getting feedback as soon as possible.

As a product owner you should always look to cut scope where there is risk in the market, looking for the real minimal marketable feature set. You can build on your success if it works and minimise loses if it doesn’t.

This feedback loop is used to find out as fast as possible if the project outcome will result in the expected benefits.

Agile Principle: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Within a project people are learning as they go, trying to lay out every requirement up front in great detail is very difficult due to the amount of complexity in most projects. Rather than assuming that we just need to try harder to nail everything down Agile shifts to allowing changing requirements. Further to this there may be feedback from the marketplace as a competitor adjusts their strategy, allowing this flexibility makes us more likely to succeed.

This feedback loop is used to improve the project outcome.

Agile Principle: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

By making sure that our software is fully working on real environments with real components we get feedback about how well the solution will work. Great disasters have been known to occur at the end of projects when a full scale environment is built for the first time and we learn too late that our solution isn’t performant. By delivering the working software frequently we can get feedback that it will work when released.

This feedback loop is used to ensure the software works properly as early as possible.

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

In the past infrequent contact with business people would lead to the wrong product being built, then expensive and time consuming re-work occurs based on change control. By bringing the business and developers together we greatly shorten the feedback loops. The creation of the product owner in Scrum is a direct response to this problem.

This feedback loop is used to ensure minimal effort is expended on re-work throughout the project.

Agile Principle: Working software is the primary measure of progress.

Within waterfall projects we often see success in terms of the analysis and design stages being signed off on time, only to see disaster at the testing stage. Defects are found, users aren’t happy and the project spirals out of control. This is down to documentation being a poor substitute for feedback from working software. If you don’t have working software you are receiving poor feedback. This is an inefficient way of working.

Even using agile methods it can be very tempting to build up lots of screens that look like they are working without any real end-to-end scenarios truly being ready, this is adding great risk to a project even though it makes it look like progress is good. Using mock objects and having a lack of real data are typical culprits in this area.

This feedback loop is used to ensure that the software is built as efficiently as possible.

Agile Principle: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Here we see a feedback loop from people talking with each other. It is very difficult to get complex and large amounts of information across to people. In these situations our assumption that we have transferred 100% of our knowledge will be incorrect. From this post you will likely get 10% as you are reading, discussion rises to 50%, so we can see face to face communication is far more effective than documentation. When working through problems together this rises to 75%.

This feedback loop is used to ensure that collaboration and learning is as efficient as possible.

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

Here we see a feedback loop from within the team, focussed on how they are working. This helps improve efficiency and promotes a feedback culture. This is done at “regular intervals” to highlight the importance of re-assessing efficiency regularly and not just once at the end of a project.

This feedback loop is used to improve the way the team works together.


Protect the Team

“Protect the team” is part of the Scrum Masters role on a project. Please note that this post is not a discussion on the rights and wrongs of project setup. Let’s look at what this should and shouldn’t mean in practice….

  • The background

The Scrum master is there to maximise the productivity of the team by ensuring the Scrum processes are as effective as possible. They are there to help the team reflect on how they are working and improve.

They protect the team to help the team achieve their sprint goals and achieve this by:

  • Keeping the team focussed on their goals.
  • Protecting the team from external interruptions that will damage the sprint goal.
  • Ensuring that the goals are realistic.
  • Protecting the team from itself.

I hope you find little controversy in what I have written here!

  • How it can break down

The primary issue I have seen with Scrum masters is when they protect the team from their own delivery team. At its worst I have heard a Scrum master say, “Do you want me to get rid of him”, directed at someone involved in running the project.  The chickens and pigs sketch was a primary example of this, it suggested that the “chickens” or non-Scrum team members were not committed to delivery. This created a them and us culture, seeing anyone outside of the team as meddling with progress.

I believe one of the failings of Scrum is not to insist on a big picture or system wide view. When the goal of the sprint takes priority above everything else this can damage delivery overall. Here are some simple examples:

  • As a database administrator I need to know how much space the team are likely to need for a test database so I can build it for the next sprint.
  • As a the head of security I need to know how the payments engine interface is secured so I can get it certified to go live.
  • As a service manager I want to talk through how code quality is being addressed so I can be sure it’s maintainable.

Let’s be pragmatic! In this case I believe it is the role of the Scrum master to help understand and express the impact of the interruption. This can be light touch, it is not to patrol for anyone attempting to talk to the team and get rid of them. This closed view of a Scrum team can damage a project and introduce delays. We also need to be careful with solutions like, “I’ll talk to them and get back to you”, as this can create waste in the form of poor information hand-offs, leading to additional delays.

A good way of spotting this behaviour is when team members start to use the word “management” in a derogatory fashion to describe non-Scrum team members. This re-inforces a them and us culture. 

  • The solution

As a Scrum master you may wish to minimise interruptions, that’s fine:

  • Maybe you ask for a meeting to be scheduled for a later part of the day, if it’s a large subject.
  • You could openly accept interruptions just after the stand-up.
  • You can ask for non-team members to think carefully about the urgency of their request before interrupting.

These are simple suggestions and I’m sure you can come up with more that fit your situation. What we must avoid is a them and us culture, as a Scrum master help everyone to feel like a team!