Coaching In Agile


In a recent survey, when asked what the most valuable things were that helped businesses to scale agile practices*, the most popular answers given by participants were the following:

  1. Internal Agile coaches
  2. Consistent practices and processes across teams
  3. Implementation of a common tool across teams
  4. External Agile consultants or trainers
  5. Executive sponsorship

The above tips all appear to be common sense items – bring a consistent way of working from the top down and use both external and internal guidance to support the teams in their ways of working.

The fact that these are the top recommendations, however, makes it clear that consistency and advocacy are the main areas that, in retrospect, matter the most.

Three types of coaching

It doesn’t take long, when Agilists meet, for conversations to spring up about a team they’ve met that thought they were “doing” Agile simply by sitting the courses and following the cheat sheets that they’d been left with…only to find they were still going through all the old motions and not seeing the massive performance shifts they’d anticipated. From the outside, it’s clear what needs to be done differently, that these brave businesses that have bit the bullet and started their agile journey could be getting so much more bang for their buck, despite the fact that they’re already happy with the improvements they’re experiencing. Investing in coaching and the “advocacy” element of scaling Agile combats exactly those kinds of issues – you need people in the team that know how good it can be to serve as the driving force that pushes them past a handful of isolatory scrum teams delivering things fast and small.

All of the types of coaching listed in the survey are important and will impact your teams in a variety of ways:

Internal Coaching

When scaling Agile, one of the biggest things at risk is the removal of autonomy from the team. This can happen as some of the non-endemic processes (which were often removed when the team was operating without considering scaling) begin to become part of the team’s decision making once again. Giving autonomous, flexible teams these out-of-scrum considerations can cause them to fall back into attaching themselves to business needs and priorities, undoing some of their most valuable new benefits.

Autonomy and empowerment of teams can only take hold of a team when they internally know how to use their empowerment (along with when to challenge the limits of their empowerment), when to try new approaches and when/how to decide if their current ways of working are effective. With this in mind, the application of internal coaching is clear – it’s the team’s responsibility to protect their own culture from within. This can (and should) be part of the Scrum Master’s every day role, but it is the responsibility of the whole team to be vigilant too, challenging the changes that come in to the team and coming to a consensus on how to manage them. So, as much as scrum masters, agile coaches and the fabled “pastors of fun” can monitor and make recommendations, it’s important that a team wants to protect the things they value and can police themselves communally. It’s only at this point, where the team can identify and implement their own changes and deflect wasteful or damaging changes, that they can truly be regarded as self-standing.
Internal coaching as a member of a scrum team can involve looking out for team norms, challenging the things you’re unsatisfied with and even simply turning up – a team can’t push itself without consensus and accountability from everyone involved.

External Coaching

No Agile transformation can persist in a true, continuous-improvement-minded fashion without an awareness of what’s going on in the world outside. The datum is always changing and unless there are people monitoring the new techniques, nurturing existing techniques and observing the mistakes/learnings from across the agile landscape, it’s impossible to know just how good things are, or how good they could really be. It’s one thing to adopt Agile principles and reduce the duration of your release process, but what if you learned that there were CI/CD techniques that made release durations a thing of the past and that other teams could confidently release things instantaneously…you’d want that, right?

This is a common and constant factor in Agile and it requires people that can disconnect from a specific project, even a specific business or industry and explore all of the new things that have been going on beyond the horizon. External coaching can take many forms, most commonly in the forming of “communities of practice”, the hiring of deliberately detached Agile coaches and reaching out to neighbours via events and get-togethers. What’s recommended is to cycle external coaching in and out of a team so that team can tune itself with incremental improvements (kaizen) and sequentially implement the newly learned and experimental changes as the incremental change becomes less effective (kaikaku).


Without these changes in state, teams are at risk of entrenching themselves in their own local ways of working, making it harder for scrum teams to integrate and share at scale. Look out for teams pointing out the “not-agile” aspects of other teams and ask yourself which of the teams is tunneling their agile vision or imposing their ways of working on the teams around them.

Executive Coaching

A team can only perform as well as the environment that they’re in. As such, coaching of Agile values can’t start and end with only the team(s) taking part. The line in the Agile Manifesto “Individuals and interactions over processes and tools” is often compressed down to “People over processes”, when it infact is much more about getting amazing people together, empowering them with the things that they need to be as amazing as possible, then giving them the flexibility and trust in them that amazing things will happen.

In new-to-Agile and new-to-scaling businesses, it’s not always easy for the operation to just leave teams to work without telling them what to do. The way to combat this is to get in on the highest level and inform, from the board of directors, through to the teams and out to the supporting departments so that everyone, at a minimum, has an awareness of how these teams will be working and what they can do to give them the best opportunities for success.

Executive coaching is not about telling a team what they should be doing in order to scale. When done well, it’s about giving the teams the empowerment to think for themselves and the coaching aspect comes from identifying if they’re using the empowerment as best they can. Make teams aware of the support they have and the many forms it takes, baring in mind they’ll be unable to spend a resource if they’re unaware of it. Taking this one step further, teams should feel like they’re able to test that boundary. If they’re granted a hack day to try new things, are they identifying if one day is too much or too little?

Hopefully this short piece has helped, but if you’d like to talk further about any of the above then I’d love to hear from you.

*12th Annual State of Agile Report by Collabnet. ”Which of the following have been the most valuable in helping you scale agile practices? Check all that apply.” – Multi-choice answer section included an “other, please specify” field.

Cheers, Tam.

The Dirty Dozen (Part II)


So, how do you point out when you feel the team, or part of the team isn’t on the right track? How can you test whether you’re right to point these things out?

If you take a look at the Dirty Dozen, you can quickly identify whether something is affecting the team and, more importantly, whether there’s a clear pathway to resolving it.

The Dirty Dozen

The Dirty Dozen are the most common preconditions of people ahead of a human error, so can be seen as the root cause for many accidents, incidents and errors that make it from the team into the finished product:

  1. Lack of effective communication
  2. Distraction
  3. Lack of resources
  4. Stress
  5. Complacency
  6. Lack of teamwork
  7. Pressures
  8. Lack of awareness
  9. Lack of knowledge
  10. Fatigue
  11. Lack of assertiveness (often ownership)
  12. Accepting the Norms (the “we’ve always done it that way…” effect)

With these ingrained in the mindset of the whole team, it’s possible to objectively highlight performance issues as a group without starting a witch hunt. When you want to highlight that you feel the definition of done has been watered down and the quality of work is dropping “we are becoming complacent” sends a clear message to everyone in the team about what questions need to be asked and what needs to be done much faster than “it isn’t good enough”.

1. Lack of effective communication
Awareness that everything, including no communication, is a form of communication. Find opportunities for applying communication/find means of communicating more effectively

2. Distraction
Combat external factors causing distraction/draw focus

3. Lack of resources

4. Stress
Find ways to alleviate stress/reduce complexity

5. Complacency
Reconvene/reshuffle/take regular breaks/cycle feedback more frequently

6. Lack of teamwork
Redefine ways of working/identify areas of improvement

7. Pressures
Divert pressure/re-establish pull

8. Lack of awareness
Investigate/share knowledge

9. Lack of knowledge

10. Fatigue
Reduce intensity/collaborate

11. Lack of assertiveness
Establish roles and responsibilities/request direction. “If nobody is responsible for X, we’re all responsible”

12. Accepting the Norms (The “we’ve always done it that way…” effect)
Contrast with other teams/review processes and framework

Note that each of the dirty dozen has more than one positive response that will deliver benefits to everyone (there are many more unlisted, see here.

There’s less room for debate over whether something’s working optimally when the outcome is an improvement or a confidence check, so highlighting a risk in this format allows for matters to be tackled immediately and with buy-in from the whole team.

Team Maturity

As mentioned, these techniques come from century-old, battle-hardened industries. It takes time to get to a place where, for example, a junior in a team can walk up to an architect or a more experienced software engineer and say “You look tired, do you want to take a break?” or “You’re doing that wrong, are you aware of….” but I absolutely believe it’s the way things will go, if software engineering even closely follows Mechanical, Biomedical or any other mission-critical engineering trade.

Ideally, this means bringing it into Software Engineering at a college level, if not sooner, but there are things that can be done to bring it into your current teams too.

Agile’s “people over processes” value is the beginning of this. Focus on excellence within your teams, drive out issues as a team and keep in mind how interactions between individuals are the points of failure (and improvement) not the individuals themselves.

“When a flower doesn’t bloom, you fix the environment in which it grows, not the flower…” Alexander Den Heijer.

Cheers, Tam.

The Dirty Dozen (Part I)


I’m one of Opencast’s Scrum Coaches, here, I’m writing about “The Dirty Dozen, getting your scrum teams ready for the airfield”.

My first engagements with Lean and Agile came from Aircraft Engineering, where there was an extreme focus on safety above absolutely everything else. User needs, product value and the bottom line simply had to take a back seat to ensure that the people carrying out the work left the hangar at the end of the day in the same condition that they first arrived in.

For this reason, the perspective of decision making, organizing and continuous improvement had a much more savage (but more effective) dynamic, which made adapting to an office-based environment pretty tough. It turns out that when people aren’t always in imminent danger, businesses can (and usually will) place operational requirements above the human factors that go into delivering them. It’s harder to fix the human aspects of delivering work than it is to put your head down and do the work, so when there’s work to be done, it’s a great excuse for not fixing the interactions.

Agile in software, without explicitly stating this as an intention, does take some of that human focus and human value back, but, in the spirit of kaizen, there’s always more that can be done.

Human Factors is the practice of understanding human behaviour, psychology, anatomy and basic human physiology. It’s a mandatory module in a lot of mechanical and electrical engineering studies for this reason. This is often overlooked in software and process engineering despite a lot, if not all of the same risks to performance persisting.

One of the main things that’s considered on a day to day basis, when Human Factors is part of your everyday working life is the concept of “Compos Mentis” – being able to think or act clearly or responsibly and particularly “The Dirty Dozen” – 12 key factors that can inhibit this ability, particularly when working in a team.

Compos Mentis

“Working well both individually and in a team” is a popular line in most job applications, but this can go much deeper than simply being able to pair program without snatching control of the cursor off your teammate. In Engineering, where your life is often in the hands of your co-workers, this means being open about your own abilities, monitoring your teammates for signs of stress or injury, being aware of when everybody last ate, last rested…the list goes on! It also requires everyone to be comfortable with challenging the knowledge and capability of others, quite bluntly and objectively, without either party taking offence. This is just part of the everyday mindset for everyone in a workshop, whether they’re managing the team or the workload – everybody understands why and everybody has equal footing when pointing out the next potential risk.

At first glance, it may seem like a lot of these practices wouldn’t transfer well into an office environment, or may even cause friction, but it’s a level of team maturity that everyone should strive for and find the limits to, especially when it can lead to a better outcome for everyone.

Next time, I’ll be going through that “Dirty Dozen”.

Cheers, Tam.

So you’re a Scrum Master…


So you run the events during a Sprint, but what do you actually do the rest of the time?

This question was asked recently during a Professional Scrum Master course, and also been brought up in non-agile organisations (who may claim to be agile!). I’ve also consulted now in a number of different organisations, so it does get asked, often jokingly, from time to time.

So, let’s explore this…

I thought I would put pen to paper and, in addition to the Scrum Guide guidance ‘official’ stuff we have to do and the corporate or organisation stuff we have to do, I’ve bulleted some things I think we do. I’d love to hear your thoughts though, so please feel free to comment below to add to the list or comment so I can refine.

  • So, in the blog title above it mentions we run events, but what if an event was not run – what impact would that have? It’s good to discuss/demonstrate with the team what would be the consequences/downsides if an event was not run – empirically of course – it is one of the 3 pillars after all!
  • And when you do do your events, prep them and make them awesome and valuable to make the team better each time – see my last blog about retro events! #plug
  • Living and believing the agile and scrum dream should be something we do constantly with the team, with externals to the team, and also anyone we come into contact with – don’t be afraid to show this, be excited about this, demonstrate how it adds value
  • Working with the Product Owner on reviewing and aligning the backlog, and discussing the value of the features to be added to ensure the team are also aligned and understand the value of each one, as well as supporting the PO’s Sprint Goals and making sure the team are focussed on this – make these visual
  • Encouraging a mindset which is enthusiastic, creative, collaborative and experimental
  • Ensuring you have the right team skills, resource and tools to produce your increments and achieve your Sprint Goals
  • Making your team as transparent as possible
  • Question, challenge, consider and coach individuals, the system, the processes and the organisation to ensure alignment with the scrum framework, your principles, your experience and input from the team
  • Investigating and finding out the root causes of issues or blockers – and not just looking at the top layer
  • Promoting the team and how you work to wider audiences and encouraging anyone to view our working area and boards, encouraging anyone to you for a tour or talk or to see the team work in practice
  • Making the physical area as great as possible to work in – with team identification, celebrations, great creative boards and any visuals to excite not only the team, but also any visitors to attract and excite them
  • Mindset is everything – don’t just do agile – think agile and more importantly – be An individual or organisation who is agile adds so much more value and brings so much more than an individual or organisation who just ‘does’ agile or, even worse, thinks they do agile, but don’t. Note, hHaving a daily scrum to discuss your gantt chart before your stakeholder release planning committee meeting to discuss a CR and changes to the BRD does not make you agile ;-). So, a Scrum Master must exude all these great agile qualities – and always THINK agile
  • Work tirelessly with the team to achieve the Sprint Goals collectively and collaboratively
  • Being a good listener is important; ensuring each team member has an equal voice. This should always be encouraged
  • Ensure the team are actively growing their T-Shaped profile and if not, adapt accordingly to encourage this through pairing, learning and sharing skills
  • Experiment with different WIP limits, value points, events timings, event methods and mixing up the daily scrum to find the most effective way for your team
  • Ensure stories go through the agreed team process efficiently and timely and have a nice natural flow which the full team touches. i.e. optimise the flow
  • Making sure the team are happy, supported and sheltered from outside noise and distraction and onboard new team members with the same values the team have embraced
  • Make sure stories are achievable, broken down, understandable and add value
  • Make sure the team talks and collaborates constantly and when necessary, carefully onboard new team members to avoid disruption but maximise team involvement
  • Make sure the actions from each retro are followed up and done (see my last blog!)
  • Mentor and/or collaborate with other Scrum Masters to make sure we share experiences and always, like agile, constantly inspect, adapt and improve
  • My motto is to always make sure the team are Pairing, Sharing and Caring – we live by this, its on our white board and I make sure this happens – p.s. this is not my motto – it’s a team motto. It’s not about me – I’m just a servant to the team remember!

These are, in no particular order and just some thoughts – let’s hear yours below…


Sultan Speaks IoT

Over the last few decades, smart home systems have failed to spread widely in every home and be a coherent part of our life like what smart phones have done in half this period of time. On the other hand, the latest evolution of Internet of Things (IoT) and Big Data analysis gave new insights of smart platforms that can potentially lead to the new dream of ‘smart cities’.

It is expected that the most used daily tools and objects (Things) like clothes, brushes, keys, doors, etc. will be equipped with smart chips to be transformed into IoTs for future activities. Therefore, it makes perfect sense to think of future smart homes as huge virtual networks of Things that collect and process massive amount of sensor data and not just a few number of sensors like those introduced as individual products from IBM, Samsung and Intel. In our research, we survey the state-of-the-art of basic components of smart home systems, and introduce a framework for developing adaptive and self-learning home automation systems using both IoT and Big Data analytics.

The proposed framework is to augment homes with machine-learning intelligence to automatically detect different situations, self-learn how inhabitants act and eventually react and control the home autonomously. We propose our SLASH (Self-Learning and Adaptive Smart Home) framework for designing and implementing smart home systems that are both adaptive and self-learning. Our framework suggests integrating IoT across every home with a large network connected to Big Data analyser. Such an engine that supports analysing inhabitants’ behaviours on a large-scale can enable a new type of home automation that depends on machine learning and develops on-going automation decision over time.

For example, the user turns on the entrance light when entering his home – without any change in the status of other things- then after a defined number of reoccurrences, the system will sense the user’s entrance and automatically turn on the lights. The situation is defined per each sensor status – within the home –and according to the change(s) that led to that situation. With the increase in number of situations and the complications, SLASH can learn and act to support the inhabitant’s routine life.

SLASH is different than all previous work in smart home field in the sense that it starts without any predefined configuration, but rather as a new born baby gaining experiences from different situations as it grows. SLASH framework utilizes the relatively consistent behaviour of different users, captures and stores IoT/Things sensor data, and analyses through machine learning and big data analytics how the smart home should interact with inhabitants.

The framework is described in more details in an IEEE published paper stating the different stages of data collection, manipulation and data correlation that could potentially provide people with a better experience and quality of living.

If you’re interested in learning more about this or would like to indulge in some conversation, do drop us a line!


Awesome Retrospectives part II by Rich


Previously I talked about my enthusiasm for retrospectives and how it’s a self reflection process that, done correctly, ensues and enables the team and individuals to grow. Moving on from this I wanted to share my thoughts on running these sessions.

It’s important to plan what you, as a Scrum Master, want to achieve during the retro session and what is needed by the team at that particular time. So, ask yourself:

  • Are the team a bit flat or is an energiser needed?
  • Is there an undercurrent, so a feedback discussion (possibly through anonymous feedback) is required?
  • Is the team new, so getting to know each other is important?

It’s vital to identify what is right for the team at that particular time to maximise the value of the retro.

Now, you have decided the type of retro you want to do, think of where you are going to have the session. Please don’t have it in the same place everytime! Is it the Summer to have outside? Mix up the rooms, buy some treats and make sure everyone attends. Why wouldn’t the team want to attend if it was different, fun and awesome each and everytime?

Now, I’m not going to go into what retro activity you actually do, as you can Google these or be innovative and create your own – it’s endless. I will probably share my favourites in another blog, but once you have had decided the aim, the activity and the location, there are a few other basic rules for the Scrum Master:

  • Always encourage participation
  • Always encourage collaboration
  • Everyone should have a voice
  • Encourage sharing
  • Encourage caring
  • Encourage honesty
  • Encourage creative thinking

And always have actions (for any of the team to pick up -but get an owner in the session!). Make sure things change – we want to continuously improve and adapt – we’re agile right!

Now, to close the retro, I would always summarise the session, covering off the actions and owners. You could always end it with a one word on exit scribbled on the white board or on a Post-it note to get everyone’s feelings as we head into the next sprint. Remember, we want everyone to be enthused, engaged and excited for the next sprint don’t we?

Now, throw everything away from the retro – except the actions of course (you’re gonna write these up so you can track these), and that way you can focus on the outcomes and not problems. That’s it! Simple, right?

Before I end, just to put in a nutshell for your awesome retro:

  • Prepare well
  • Deliberately facilitate
  • Vary activities and methods – every time
  • Track actions
  • Make it fun and different
  • Listen to everyone
  • End it with positivity

Remember – this is to add value and not just to go through the motions as a Scrum Event – so don’t let it turn into that.

Don’t waste this valuable opportunity to grow as a team. Let your retro be awesome.


Awesome Retrospectives part I by Rich


Richard Haydon is one of our senior scrum masters, helping our clients deliver great digital services to their customers. We asked him for some thoughts on retrospectives and he started with a quote:

“We do not learn from experience…we learn from reflecting on experience” John Dewey

As a Scrum Master, my favourite event has got to be the Retrospective! I just love it! And it’s not just because I always make them fun through learning, it’s because I know the team will grow every time as we open up, be honest and therefore develop and flourish together as a team. That’s what’s it all about isn’t it? Working hard, but learning and having fun along the way with great colleagues who you trust.

As a team, it’s a great indication of success, and the retrospective is a great way to achieve this. So why not make it awesome – every single time?

I’ve heard from teams about previous Scrum Masters where retros have been the same every week (mad, sad, glad) 😦 and that brings tears to my eyes. In my experience this will only lead to unhappiness, boredom, habitual thinking, lack of focus and participation and – guess what – no actions.

It makes me so sad that these events could be wasted when they should be so valuable to the team – and therefore the Scrum Master.

So… why wouldn’t you want to maximise this session and make them all awesome?!

I’ll chat next time about prepping, but, before that, we go back to basics. The retro is about how we work together, not the what – it’s a reflection.

“…reflection is a self-involvement process… personal experience, feelings and cognition are intermingled in recalling past experience, resolving current difficulties, easing out uncomfortable feelings, evaluation one’s present and past performance and searching for new perspectives and new solutions.” (Yip 2006)

Till next time.