Agile Coaching & Scrum Mastering

Organisations create too many specialized roles too early, leading to knowledge silos, coordination overhead, and organisational complexity that becomes impossible to reverse.

A pretty common question I get asked when teaching Scrum is about the Scrum Master as a second role for a Developer or the Product Owner. While this is a typical implementation, and several other authors are arguing for the Scrum Master to be a temporary, part-time or rotating role among the rest of the Scrum Team, I have to disagree for three primary reasons…

One interesting observation I made several times during agile transformation initiatives is that they seem to be activated by a sort of organisational energy that drives the change. This lasts for a certain amount of time, but then it usually fades and is eventually gone.

Managers constantly watching over agile teams during sprints destroys team autonomy, reduces accountability, and undermines the motivation that comes from self-organisation.

Organisational agility requires reducing ‘accidental complexity’ - rather than just implementing agile methods at the team level.

Scaling frameworks create rigid rules that clash with organisational realities, making it difficult to adapt agile practices to large, complex environments with existing constraints.

Agile coaches face a fundamental conflict between their coaching role requiring neutrality and their evangelist role promoting specific agile practices and outcomes.

I like to think of the retrospective as a piece of art and the facilitator (usually the Scrum Master) has to learn to be the artist. This meeting is totally in the hands of the facilitator, so you can easily think that it is about the facilitator. It is not: providing a process for a retrospective is very much different from being the star of that meeting. Your role as a facilitator is to provide a structure and otherwise stay out of the way, letting the team to be on the stage.

One of the assumptions of a retrospective is that the team should come out with concrete action items they will work on to become better. While this is the preferred way, it is not the only one.

Usually the retrospective is done within the team, but in some cases there might be somebody more or somebody less…

Following the Agile Manifesto’s advice to reflect at regular intervals creates superficial continuous improvement that fails to address deeper systemic issues.

In the previous post, I introduced you to Solution Focused scales and how they can be used in a one-to-one scenario. Now we’ll extend this to a team context, but first, here are some tips…

No, this post is not about increasing the size of your development team, but about how to establish some measurements in your team - typically during the retrospectives, but not only - to support continuous improvement: let’s talk about Solution Focused Scales.

One of the concepts I hear many colleague agile coaches talking about is the concept of resistance of the client. Typical sentences are about resisting the agile transition or proposals. Now here’s one thing that is important to consider: there is no such thing as resistance, there is just bad communication!

Team coaching through group processes is too slow and ineffective when time constraints demand faster development of high-performance teams.

Agile practices are often built on unvalidated assumptions rather than solid scientific evidence.

In a conversation during the last Agile Coach Camp Germany I was reminded of something I see often in agility: motivational interventions.

Organisational change initiatives fail because they don’t address all six essential conditions that must be present for successful transformation to occur.

While reflecting on my recent activities, I started to recognise an interesting pattern regarding the role of the Product Owner.

In my work very often I stress the role of the observer: it’s a vital one when practicing coaching techniques and it’s an incredibly useful tool to use in every coaching activity.

I reckon on the subject of games I am at the border of the agile community: agile games are very spread among my colleague coaches.

Coaching Organisations as Systems, i.e. Agile as a Systemic Change at the Scandinavian Developer Conference 2011.

Another ‘service post’ to distribute the slides of the Soft Skills Essentials presentation at the Mini-XP Days 2011 in Mechelen.

Here are the slides of today’s keynote I delivered together with Mike Sutton at the Turku Agile Day

Suppose you need to choose the Scrum Master for your team and there is no ’natural’ candidate available. Suppose you have two alternatives who could do the job, but you are not sure who fits best?.

Soft Skills Essentials for Software Craftsmen at XPDays Benelux.

It’s not just about teams! - ‘Agile as a systemic change’ presentation at the Italian Agile Day 2010.

I am a strong believer in the solution focused approach. Over time I answered several questions on this topic: here are some of them.

I recently had a situation where two teams based in two different locations had to start working together on a project. I used the following technique to prepare each team for the upcoming meeting.

This is a short post to share the slides of the presentation I gave today at XP 2010 in Trondheim.

Here’s a short post to publish the slides and the handout for the third version of my Solution Focused approach to Agile Coaching presentation.

Last week I went to Kraków for the first edition of the Agile Central Europe conference. The news is that the conference was, IMO, a great success - so here’s a short report about it.

As I had announced in my last post, I talked to day at Agile Central Europe, again presenting my Solution Focused approach to Agile Coaching workshop.

I attended recently a meeting of project managers where ‘agile methods’ was the subject of the evening. I noticed an interesting cultural aspect: what do you fear about Scrum?

Teams struggle to identify and address the true constraints limiting their productivity and delivery speed in complex project environments.

Here’s a metaphor I use often when coaching people. It is called the lifetree and I use it as a tool to raise awareness of the resources of the past and the possible futures and to identify strengths and weaknesses and learning paths.

Teams and organisations struggle to develop shared values and principles that create alignment, agreement, and effective teamwork in agile environments.

One thing to consider when you start your next organisational improvement campaign, be it introducing agile, improving your agile practices or, in fact, any sort of change you want: you are not in control of what happens. You never were. You never will be. No matter how much the official org chart of your company claims you are in a control position, you are not.

During my presentation about Solution Focused work in Agile at XPDays Benelux I stated that asking ‘why’ in coaching can be dangerous and should be avoided. The purpose of this post is to add some more information on this controversial topic.

Last week I was at the XPDays Benelux conference where I presented a session about Solution Focused work in agile.

Almost every day you will notice that the existing set of rules, procedures, process, etc. you normally use in your work is not enough. What do you do then? Will you add a new rule or will you delete one?

Have you ever wondered what makes Agile so special and so productive? My guess would be because it closes loops and allows fast and useful feedback.

I was at a conference recently, following a project manager’s presentation about the project he was leading.After just a few minutes into it, I felt lost in his words. I realised what he said until then was… more or less nothing!

There are a lot of people out there calling themselves ‘Agile Coach’. I’m one of them as well. But what are we exactly? What is our role in an organisation? What value do we bring each day we work with software teams?