When does coaching end and doing start?

“Coaching is unlocking people’s potential to maximize their own performance. It is helping them to learn rather than teaching them.” ― John Whitmore

Coaching is an interesting and confusing notion, as an Agile coach in my current role we must be explicitly invited by a team or an individual to coach, usually this is driven by an awareness of a specific problem or a general desire to improve in some area.  The goal of the coaching is to enable an individual or team to solve the problem or to provide structure and support to enable the learning.  The goal is not for the coach to solve the problem.

The goal is not for the coach to solve the problem, the goal is to coach you so that you can solve the problem.

I have reiterated that because it is so critical and so confusing. A team has asked for help with a problem and you are not going to solve it?   In fact you may actually let them fail and watch them flounder – how is that helping?

This essentially gets wrapped up in the whole “Give a man a fish” thought process, a coach wants to equip the team or individual with the skills to solve – not just this problem but the next problem and the one after that. A coach may very well know an answer to the problem described, but the agenda of a coach is to grow the team into being able to solve the problem, or at the very least to understand why a particular solution may be appropriate.  This can lead to confusion and frustration especially if the problem is causing pain or costing money. The team often want the problem solved far more than they want to learn.

A coach may ask questions that guide thought processes or sow seeds of ideas, they may point out smells or examples of behaviours that may be dysfunctional and warrant further thought, all this is intended to focus attention where it can have the most impact, but all without without explicitly solving the problem.  But when the team doesn’t understand this relationship it may appear that the coach is not helping, after all the coach may appear to only identify problems and doesn’t offer solutions.  This a common failing of coaches and of me in particular. There is a certain irony that one of the most common coaching guidance I give is around getting to understanding the why of a situation but I sometimes miss explaining this vital information when it relates to my coaching.   But when you coach multiple teams it is very easy to assume that everyone understand the coach relationship and this can lead to confusion and frustration.


Coaching example

A very useful example is a situation where two people on a team are having interpersonal issues, Wendy continually leaves a mess at a pairing workstation and this drives Paul crazy, he gets frustrated and seeks out a coach and asks the coach to help. The coach will very likely ask if Paul has discussed this with Wendy and if not why not. Paul may ask the coach to speak on his behalf or to mediate, but again the coach may suggest that Paul should act alone. The coach may offer guidance on how to have difficult conversations (There is a great book on this subject: Crucial Conversations) but it is not the Coaches’ role to be mediator or to engage in conflict resolution.  If the matter is more serious they may refer the issue to HR just as any one else might but it is not the Coaches role to solve the problem or to get involved, merely to equip the person with the tools necessary to solve their own problem.

Levels of Coaching

If you consider the coaching on a one-to-one level it may be easier to see how the different levels of coaching are applied and when or why different techniques are applied.

If we take writing a first draft of a user story as an example.

  1. At one end of the spectrum the coach could ‘teach’ or talk about general story writing techniques and practices and give examples.  (Teaching) abstract ideas – blogging, courses, lectures, presentations etc
  2. Or it might be useful for the person being coached to work through a generic example with the aid of a coach (Training). Workshops or interactive activities such as games.
  3. Or it might be useful for the person being coached to work through a real example with the coach available to ask questions or the coach asking questions and offering encouraging ideas (Coaching/Consulting/Advice)
  4. In some cases the coach may sit with the person being coached as a partner sharing thoughts and ideas in a balanced way sharing the work (player coaching/mentoring)
  5. At the other end of the spectrum it may be that the coach actively participates in a pairing situation and shows the person being coached what is being done and explaining why.  – At this point the line between coaching and doing is a line in the sand and depending on the engagement level of the person being coached the level of learning and improvement may be negligible.
  6. And finally the coach does the work on behalf of the team/individual even though the team could do it for themselves. At this point there is no coaching value at all.


Of these five levels most Agile Coaches operate at levels 2 and especially 3, occasionally in 1 and 4, but 5 is unusual, certainly in my current role we explicitly say that we shouldn’t ‘do’ and if we stray we should be aware that we are no longer coaching.  In contrast a Scrum Master spends more time at 3 and 4 and often at 5  or even 6 – resolving impediments, producing metrics etc. But the overlap between the roles is subtle and there is no hard line. It is more a question of the intended outcome, rather than how it is achieved.


Of course the ideal and the reality can be quite different, I have been giving some product owner coaching recently and this is a double edged sword, the product owner aspect of software delivery is one of my favourites and I get enthusiastic. So I have been helping write story maps, and identifying personas and writing stories but every once in a while I’ll start doing, throwing out my ideas, making corrections without discussion and my biggest sin, taking over at the keyboard!  Thankfully usually one of us will spot it quickly and non-verbal cues will put me back in my coaching box.

My summary is really that not understanding the goal of the coaching leads to all sorts of problems, the teams facing a particular problem may feel they are not getting the assistance they need. It may be difficult to measure whether a coach is effective when they go out of their way not to ‘do’ something. The role is both very broad and very misunderstood.

But when the role is understood and when those being coached understand the relationship and the value of it, the situation changes drastically. It is a hugely rewarding role and the relationships can be fun and fruitful. When you accept that you are expected to solve your own problems (with guidance) it can be very empowering, a coach becomes someone that can help YOU expand YOUR understanding and ability, but credit belongs to you, not to the coach, they just point the way – you have to do the work.

Will Agile lead to the end of gender bias in IT?

This is a touchy subject and one where I realise I am treading on thin ice by making sweeping generalisations on an emotive topic, however it is a topic that needs addressing.

Surveys show that while the professional workforce in the USA is composed of 57% women – yes that’s right men are a minority.  In computing fields, the numbers are very different where only 25% of the computing related workforce are women – anecdotally the number of programmers is closer to 1 in 10 but there is a lack of data on this – one recruitment agency quoted around 10% of programmers placed were women.

So why the big disparity?

It may not be what you think, whilst discrimination may occur in the workplace, it’s impact is not statistically evident. If you look back to university only 25% of computing related degrees are awarded to women but again women account for approximately 55% of all graduates. So the workforce statistics almost exactly match the university statistics. This suggests that the impact of any discrimination or negative presentation has occurred (mostly) prior to university. My female friends and co-workers tell me that subtle discrimination is prevalent throughout their lives and this can lead to life choices being swayed by that, but that discrimination direct and indirect still regularly occurs.

Exclusion from computing and software is a choice.

Women have effectively self-selected to avoid the profession, so the real question is not why are women excluded, but why do women feel excluded or are simply not interested? Do social pressures on both women AND men dictate their career choices. Men statistically are drawn to the higher paying professions, so perhaps they too feel the social pressure of a different kind and are possibly selecting careers based on potential financial reward. Women seem to be drawn to careers that are perceived as more rewarding (vocational) but less financially rewarding, so it could be considered that in some respects women have greater freedom of choice (lack of social pressure to earn). 

However, the choice to enter software careers may well be the accumulation of negative influences discouraging women, or the lack of female role models, or male dominated media presentation of the industry. We need to understand what happened in their early lives that discourages women from entering what is generally a rewarding career path.

I have heard people suggest that it is a boys club and they don’t feel welcome, but the same could have been said about medicine a few years ago, in the UK in the 1960s only 10% of doctors were women, by 2017 it is expected that there will be more women than men and in the under 30s women outnumber men 61%-39%.  The USA is a little slower but women account for more than 1 in 3 and this number is growing. The latest figures show 48% of medical students are women.

The one hypothesis I have heard that resonates with me (and beware the man that uses generalisations) – Is that there is a tendency for women to measure their self-identify in the context of their relationships, their cliques, teams, peer groups or family. They find pleasure, reward and satisfaction from working in groups or choose professions that are rewarding.  Whereas men more often see their concept of self as measured by career status or in their work and select a career based on earning potential.  So women generally prefer work that involves people, whereas this may not be a priority for men.
Please do not see any implication that one of these outlooks is better than another or that it is a rule to be applied, I see them as different choices and priorities neither is right or wrong or better or worse. I offer them as generalizations that may help understanding. In effect both genders behaviour may be the result of social conditioning.

Whilst this is likely just one factor in a complicated decision I feel it is a reasonable hypothesis to explore. We are coloured by our experiences and this reflects what I have observed in the workplace, and in my opinion mixed teams are so much better: they are generally happier more productive and better at interacting with 3rd parties – compared with single gender groups.

So how could Agile help?

Education and the media present software and computing as being a solo activity, and worse as anti-social.  Images of men surrounded by energy drinks working all night on their own.  For socially stimulated people that is an unpleasant and negative impression.

The reality with agile teams is so radically different from this.  The coding element of software creation is actually much less than people realise, and even then it is generally not a solo activity, pairing is now prevalent which means you are rarely if ever working alone.  Software is very much a team activity with group discussions dominating the working day. Scheduled short meetings or impromptu discussions intersperse the day and rooms are rarely quiet. Software is not just coding, Agile encourages cross-functional teams and your typical team member may be doing analysis, design, development and QA, likely also support and customer interaction. And I may have mentioned this already – rarely alone. All of these activities are team activities.

Software development is a team activity.

For a group that measures self-identity based on their relationships I am hard to pressed to think of a more social activity than an agile software team. It is one of the most social structures I know, to the point where it can be difficult to disassociate the individual from the group. It is very difficult to measure individual performance. The true measure often comes down to how well you integrate with the team, and how well you can communicate.

As for unsociable hours, that is a thing of the past. Agile promotes sustainable pace, that means that teams set a pace that can be achieved week after-week, after-week, no more death marches, no late nights. In fact most agile software groups tend to have very flexible hours, with the weight put on to team contribution. Some teams choose to work early mornings and leave early, others later in the day.  And with pair-switching happening frequently and effort put in to knowledge sharing – avoiding single dependencies and silos it is actually pretty easy to have part time people that are effective and active members of the team with little if any detriment.


And then of course there are huge benefits of having diverse teams. Teams of mixed genders are more effective, a lot more effective.

So if we accept the hypothesis that women have the wrong impression about software development and that the software industry post-Agile is more inclusive, more social, more compatible with part-time work and flexible working.  And that the industry could benefit hugely from a more balanced and diverse workforce.  How do we get that message out?

How can we fix the negative perception?

How do you persuade education – both university level and earlier, to teach that software is a team sport, that the most important skills for success are the ability to work well with others to be team players, cooperators and collaborators.  And how do you educate the media to stop presenting IT professionals using negative stereotypes? 

Software development is fun, a typical agile team environment has a buzz: talking, laughing, sharing ideas, collaboration and caring for each other. Not that they are not professional, most of the buzz comes from the desire to do the right thing for the customer and the users of the software. The buzz comes from the thrill of creating something new and amazing with a group of people you respect and admire and enjoy their company.

Taking the game to the students

I’d like that to be taken to the classroom, get the message out that in real life you don’t work alone you contribute to a group, that in software development especially you succeed because you are a team and the better you work together the more we can achieve.

As part of our Agile training we play a variety of team learning games that simulate iterative development and learning. They promote team thinking and team retrospectives how working together you can be more effective and how by reflecting you can improve.

I’d like to take a cut down version of that activity to some schools and see if on a small level we can change young people’s perceptions of IT.

Of course the media could help with some better role models and presenting software development in a more positive light, but that may be too much to hope for.


Self-Organisation vs Human Nature

I love the notion of self-organising teams, the belief that if left alone the team will pull together and solve the problem at hand. I also love the notion that a team doesn’t need named roles and that a team should be multi-skilled and can and will do any and all tasks necessary to deliver the work.  As a model this does work, I have seen some great teams that can and do achieve this. But I don’t think this is the norm. There are certain foundations necessary for this model to work and for far too many teams they don’t have the necessary pre-requisites.

The team must have (or have readily available access to) all the skills.

The first is to have ALL the necessary skills on the team. Which may sound obvious, but when arranging and staffing teams we will generally ensure that a couple of the core skills are present and overlook or underestimate the importance of other skills. Or some of the other necessary skills are a lot less tangible and quantifiable, ‘softer’ skills, so we trivialise or undervalue them, when actually those less defined skills are likely to be the ones that mean the difference between getting by and excelling.

I doubt many question the claim that a software developer is a specialist skill, many people can have a go at coding but most serious products require a deeper level of understanding of the code than a casual understanding. I personally believe that the role of QA is similar, many can do the basics and run test cases, but a QA is a specialist skill and those gifted at it possess a perception that few developers even grasp let alone can mimic, they see a problem differently, a Dev tends to see a solution, a QA will see how it might fail.

Similarly with design, few Devs could design their way our of a paper bag, interfaces designed by engineers must give designers nightmares. I have seen engineer designs where every function of the system is displayed on one page giving a casual software tool the appearance of a complex flight control interface. That’s not to say that some Devs don’t have design skills, but generally they are lacking. And then there is Product Ownership – the term for a collection of tasks and skills that I feel is generally drastically underestimated and a skill set that is rare in your typical Dev. In my opinion it is potentially more specialized than that of a developer or QA, and is rarer to find on a typical team composed of Devs and QAs. (Named roles or otherwise)

Drawing the expected value out of a customer or stakeholder and verbalising it, is a skill, translating that into a story can be time consuming and painful, but when done right the Devs can fly and the stakeholders are happy. When done badly the developers churn and the stakeholders grow frustrated. Product Ownership is the vanguard of Agile software development. Being able to articulate a clear vision, and present unambiguous goals and priorities, to write stories that express the value of the work without imposing a solution on the Devs can mean the difference between a goo and a great product.

To do all this requires someone that can communicate effectively with the customer and stakeholders and then transfer that information clearly and effectively to the team, to ensure that the customer is clear on priorities and is happy with the progress requires soft skills that are not at all common. This is an extremely difficult set of skills to master. To simply assume that a team will inherently possess the skills necessary to fulfil this role amongst themselves is inviting disaster. To assume that the customer is clear on their intent or direction and can express that need to developers who may not possess the experience or will to probe and challenge to identify the true need is simply inviting disaster. Product ownership skills and experience is not an automatic side effect of being a Dev – far from it.

The team must be motivated to do any of the necessary tasks.

And secondly there is Human Nature.  This may be seen as a generalization and it is a generalization that I have been trying for years to break, and to be fair there are some team members that do manage to evolve beyond their labels and become more cross-functional team members. Many will take on tasks relating to DevOps or DBA or even some of the other core skills on a team such as Design and QA but, BUT…

What I find more often than not is that if people are left to their own devices: Devs want to code, QAs want to test, Designers want to design and NOBODY wants to do documentation, administration, or talk to stakeholders or to integrate other people’s code. Maybe an over generalisation, but not too far off the mark.

The result..

And of course the whole point of self-organising teams is that they ARE left to their own devices. So we have a bunch of self-organising teams that have a mix of being unable or unwilling to do all of the tasks necessary to deliver the product.  Obviously some do muddle through and when push comes to shove they will step up and get the job done. But many just don’t want to and will either leave it to others meaning that the more ‘Agile’ team members get all the crap jobs, or more commonly I seem teams finding ways to stay busy to avoid doing the tasks they don’t like or facing the problems the team would have if they actually confronted them.

In the book the Lord of the Flies, there is a goal – a signal fire, but the boys become busy and preoccupied with the more interesting tasks and having fun, thus neglecting the fire.

I see non-urgent (and not prioritized) features getting worked on, scope creeps all the time. The ‘build process’ becomes gold plated, and the team starts a whole bunch of ‘spikes’ that take far longer than should be expected. Everyone is ‘busy’ but no one is delivering value (nobody is tending the fire). All because the team is subtly, maybe subconsciously avoiding tasks they don’t like or don’t feel they are able to do. This may sound harsh, but I have seen this behaviour far more often that I would care to count.

So do I advocate self-organized teams? Do I advocate named roles in teams?

In my experience Product Ownership requires skill and dedication. Assuming a team possesses it simply as an after thought or assuming it is a secondary role is very damaging. For a newly formed team/project someone skilled in Product Ownership should be primarily focused on that.(Not necessarily in a named role, but certainly specifically assigned the responsibility). But that assumes there is someone on the team who possesses those skills.

It should be part of the responsibilities of that role to spread that knowledge and share those skills to avoid creating a silo – (why not pair? the way you would a Dev role?) Please note I am not saying this is essential, but I am saying that it can vastly increase the effectiveness of a team. and fears of a bottleneck are unfounded, a focal point and a single filter may actually be a benefit rather than a hinderance.

In a similar vein I think that in the early days of a team of a project a flow manager/coach/Scrum Master type role can help a team form and become effective far quicker. They encourage the team to be aware of the less desirable tasks and to emphasise the importance and value of getting them done rather than focusing on less important tasks. Helping the team understand the difference between the feeling of being busy and actually delivering value to the stakeholders/customer.

Understanding the difference between a necessity of having someone in a role and the benefit a team derives from having someone in a role are often confused and muddled and that is something I intend to return to in a future post.


I do believe teams can be self-organising and I do believe that named roles can sometimes lead to unnecessary siloing – but that is not a certainty and that goal should not dwarf the desire for an effective team. I don’t believe that throwing a team together and taking away titles will magically make a self-organising team. Self management is a learned skill like any other and takes time to learn and to perfect.

I also don’t believe that taking away named roles removes the need for specialist skills. Saying we don’t want a named QA or Dev or PO doesn’t mean you don’t need those skills on the team.

Understanding which skills are needed is vital for an effective team, whether it is self-organised or not.  But even with the necessary skills the team still needs to understand the direction (vision) and be motivated to reach it.

All he does is state the obvious…

A few weeks into a new project and I was given the feedback that all I had been doing is stating the obvious and pointing out pretty much fundamental Agile principles and practices.

At first I was a little offended, I want to be adding value and so it was more than a little disappointing to hear what I felt like was a negative assessment of my work. And so I reflected on what I had been doing, partly to see how I could do better and partly to reassure myself that I was adding value in the right areas.

As I reflected I realised he was right. I had been stating the obvious, but what is not generally well known is that the obvious is not so obvious at all. 

If there is one criticism that could be fairly leveled at me is that I let teams flounder too long before I step in. I have the belief that if a team solves it’s own problems without help they learn far more. If the team doesn’t appear to be seeing a solution I then move on to subtle hints – dropping seeds of ideas, and if I still feel they are not seeing things and I get to the point of ‘stating’ then it is because I don’t think the team is going to solve the problem without more pain than is appropriate for the situation. 

In this case I had been challenging the team to produce working agreements and agree what their definition of done was. This is a scaled Agile project and my fear was that if the whole team did not agree ‘done’ together then one sub team’s ‘done’ would be imposed on all, or worse ‘done’ would be inconsistent between the teams. I also urged them to agree how they would integrate their work, I gave them advice on ‘Vertical Slicing’ and some advice on story writing, especially ensuring that the ‘value’ of a story was clear. All pretty obvious stuff – that is if you knew it already.

But these are new teams and some of the team are new to Agile, I suppose what is disappointing is that it was me that had to state the obvious, and not one of the more experienced team members. Self-organisation only works if the teams take the responsibility, and are then sufficiently motivated to deliver on that – more on that in my next post. 

If my advice was so obvious why did it take an outside observer to see it? Why couldn’t the team see it for themselves?  The answer of course is that solutions only become obvious when you see them,  and it often takes an outside observer to point out what should have been obvious all along. All too often we see things as obvious after they have been pointed out to us or later feel they are so obvious we don’t say anything not realizing our team mates were struggling.

Realizing that common sense is not very common and what may seem obvious to one person may not be seen at all by another is actually one of the more difficult aspects of coaching. Sometimes I ask what seems like a basic or even stupid question because I sense others in the room may be unsure. Sometimes this makes me look like an idiot but sometimes it is clear that the stupid question was not so stupid. (And for the record sometimes I ask to promt conversation or clarification but often I simply don’t know and I figure that if I don’it know maybe I am not alone.

So please, state the obvious in your teams, especially if you feel it may not be so obvious to everyone else in the room.


Just what is an Agile Coach?

An Agile Coach is a relatively new job title, one that has become popular over the last 10 years or so and is a role that causes a great deal of confusion: what do they do? and how do you know if they are doing a good job?

It is also a title that covers a great many responsibilities, sometimes Agile Coaches will coach teams, sometimes they will coach organisations. For the latter I prefer other terms and so for the purposes of this article I will assume that the role is one aimed at coaching development teams within an organisation.

What the role is not…

An Agile Coach is not a manager,

although many Agile Coaches will have had experience as managers or at least have had backgrounds similar to other business leaders. An Agile Coach will generally have a broad history of working with people, and understand how to manage people – and how not to. In organisations with Agile Coaches they will often reduce the demand for managers or in some cases eliminate the need for managers entirely.  But not by taking on their responsibilities, but by showing and enabling the teams to fulfill many of the responsibilities for themselves. This is generally much tougher than managing directly, as they must do it without authority. Much of an Agile Coaches responsibility will be in building teams and encouraging good working practices and collaboration with colleagues.

An Agile Coach is not a Project Manager,

although again they may have a degree of knowledge and experience in this area. An Agile Coach will be there to work with teams to deliver software, but an Agile Coach is much more likely to ask “Why?” than they are to ask “When?” A coach is far more interested in whether a team understands a priority than they are in ensuring a team meets a deadline.

An Agile Coach is not a lead developer,

although they may have once been one, sometimes they may pair with people on a team, coding or testing or designing, but they are not there to be productive but to enable the team to become more effective. Sometimes through advice sometimes by example and most often by enabling safe failure, a Coach will likely let you fail and then ask questions to help you understand why you failed.

An Agile Coach is not a facilitator,

although they may facilitate meetings and events. A facilitator will often be neutral and unobtrusive. A Coach should know when to prod, poke, be provocative and even contrary or when to stay silent. I know coaches that will deliberately and consciously stay silent during a meeting, noting for themselves what their advice would be but just watching to see if the team reach the same outcome. Other times, suggesting a false path to see if the team challenges them. Other times they may guide a team to an outcome if they feel the team will benefit and will be able to make similar choices in the future. Most often I find myself sowing seeds of ideas in the hope it will trigger the team to come up with a solution for themselves.

An Agile Coach is not a trainer,

although they will help you learn. An Agile Coach may at times teach in the conventional sense, but more often they will enable you to create opportunities to learn, and when they do training or seminars it will likely be composed of learning opportunities more so than lecturing from the front. A Coach will generally try not to tell you how to do something nor even show you how. Normally they will ask questions that encourage you to figure it out for yourself. This is not of course the only way to coach and sometimes it is more effective to show and then ask why you did something a certain way. But it will be rare that a Coach will tell you how to do something without ensuring you understand why you are doing it. As you can imagine this can be an area of frustration at times.


What are they then?

An Agile Coach is Experienced

An Agile Coach is generally someone that has been there and done it. There are a whole host of learning material on Agile Practices; delivering software; and managing people and businesses. But there is no substitute for someone that has done those things first hand, and better yet had difficulties or failed at doing some of those things. You will likely find that an Agile Coach has years of experience of delivering software in general, often having done a variety of roles.

I believe the reason for this is that in most situations where a coach adds value it is not a solution that is sought, but and understanding of the problem. Someone that possesses nothing but canned solutions to questions, hasn’t had the benefit of the journey to understanding that the question asked is rarely the question that needs answering.

To get there requires the ability to see beyond the question, and in my opinion at least, this comes far more from experience than teaching. I find some of the best lessons are in the form of fables and analogies. Because they are able to stir our own experiences to enable us to better understand why we do something rather than being presented with a solution.


Experience is the teacher of all things

– Julius Caesar

An Agile Coach has plenty of soft skills

the chief of which is empathy, which comes from experience. The ability to understand the perspective of a developer or QA or the other members of the team comes a lot from experience, which is why so many coaches started their careers in software delivery teams. But the role also requires communicating with management and customers and other teams which requires great communication skills and yet again can benefit from having been in a management role, or project lead, etc. The role may involve 1-1 coaching, mediating conflicts, giving difficult but constructive feedback, building relationships with teams and encouraging them to build relationships among themselves. Negotiation, selling, planning, listening, advising provoking and challenging. A great coach excels with soft skills. A few coaches have an abundance, most of us are skilled in some areas but are still growing and learning to develop these skills.

An Agile Coach is responsible

but not accountable, they are responsible for guiding the teams in Agile Principles and Practices, but priority is given to understanding why, over learning how. But they are not accountable for the teams following Agile principles, the teams themselves are. The coach can show the way but does not force you on to the path.

An Agile Coach needs to be humble

On the best days a coach is a force magnifier, they are able to show a team or an individual how to improve, but the coach will rarely be able to say “look at what I achieved”  instead they will sometimes be able to say “Look what I helped achieve” but more usually watch from the sidelines as credit is given to the team or the individual. If you are looking for glory this is not the job for you.  You are often even held in a negative light when you shine the spotlight on problems that were previously unseen. A thick skin is essential.

An Agile Coach needs to be hungry

Being Agile means always wanting to improve, and to do that requires a desire for learning, through experience and through other forms of learning, books, conferences, discussion groups. An Agile Coach that isn’t learning and pushing themselves will likely very quickly become ineffective.

An Agile Coach is open to new ideas

Agile is not a methodology, it is a desire and determination to find better ways to develop software and help others do it. An Agile coach should not be wedded to a framework, be it Scrum or Kanban or XP or any of the others, they are tools to reach an end. When we limit our scope to only one framework we cease to be an Agile Coach. We should be aware of the options and be open to new ideas. That doesn’t mean we don’t favour some over others, but we should have an acceptance that they are merely a tool to do a job. Each may have areas they are better suited, and perhaps with sufficient understanding it may be possible to combine ideas or cherry pick elements from other methods.



The benefits of an Agile Coach

An Agile Coach’s expertise is much broader than Agile methods, whilst at it’s core the impact can extend from teaching the basics of the various Agile methods through to expertise in the various roles in an agile organisation – such as Product Owner, or implementing XP practices, coaching organizations on Agile transformations or simply process improvement. But most Agile Coaches have expertise that goes much further and may well be skilled at coaching interpersonal issues, team building, management techniques, personal development, conflict resolution and most of what would be considered ‘management’ skills.

I would broadly break down the benefits of an Agile Coach in to four areas

  1. Coaching on Agile Methods
  2. Coaching teams that have identified a need for support in certain areas
  3. Helping teams identify areas where they need support
  4. Helping organizations identify ways they can improve teams at a macro level

The first two the teams are likely consciously aware of and so are able to identify the need and make the request. The latter two by their nature are likely areas that the teams are not aware they have an issue, or feel it is something they cannot change (in isolation or at all)

The four stages of competence:

Unconscious Incompetence: If you are unaware you lack a skill or are unaware of a deficiency you cannot ask for help. A coach should be able to observe and identify where you may have areas for improvement, it is common for us to be unaware of our bad habits or blinkered thinking, we get stuck down rabbit holes, sometimes this can be on an individual level and sometimes teams can be the same way. It generally takes someone from the outside to see the problem and help move it from unconscious incompetence to a conscious incompetence, once we are aware of a problem we can choose to do something about it.

Conscious Incompetence: If you are aware of a problem, you can take steps to improve. Sometimes you can do this on your own but sometimes it makes sense to ask for help, asking for a coach to help guide you, they may have past experience or suggestions or techniques to help. With effort you can generally move from conscious incompetence to conscious competence

Conscious Competence: At this stage – with some effort you have the skill or have obviated the defect, but it still requires effort.  Now it is really a question of practicing the skill until you become proficient (unconsciously competent), the value of a coach here is not in the evolution of the skill or the breaking of a bad habit, it is in the observance of new bad habits forming and stopping them early.

Unconsciously Competent: As you improve one skill area and become unconsciously competent – you have a mastered a skill, you may discover more skills you lack, and the cycle repeats.

How to measure or for that matter manage an Agile Coach?

There are generally considered to be a number of situations where it is very difficult to measure and therefore difficult to manage someone:

  • Where the person’s expertise is broader or deeper than that of the person measuring them – essentially how can you assess performance if you cannot judge if it is good or bad and to what extent it is good or bad.
  • Where the person’s contribution is intangible.
  • Where the contribution is situational and variable, there is no yardstick. (Such as creative or innovative work.)

An Agile Coach falls into all of these categories.

There is no easy objective way to measure performance as there are no KPIs. The coach’s goal is to improve a team or an organisation, if the organisation/team improves – was that because of the coach or for other reasons? There is no objective way to tell.

At some point it becomes a question of trust, and subjective assessment.

If you have a problem and ask for help, a good Agile Coach will give you a solution, but a great Agile Coach will show you how to solve the problem for yourself.


Not all Agile Coaches are the same, and not all will possess all of the skills above. Each one will have different strengths and weaknesses and a lot will come down to how they interact with the team they are with. Like any profession there are some Coaches that are better than others. But in my view any team should be able to improve with the right coach, but not every coach is right for every team.

If you believe that you cannot improve with coaching (and some teams do claim this), then you are probably right, a mind so closed to the possibility of learning, or that someone else may see something you can’t, then maybe you cannot grow and you may be incapable of improvement. But consider that even the best sportsmen, and artists have coaches, the most successful business execs often have outside mentors. The limiting factor is not the coach it is your willingness to grow.

I’d also add that some coaches are better with teams at different stages of Agile maturity or the different stages of a team development, that does make one better than the other. I’ve seen some extremely experienced agile coaches that are so advanced in their understanding of Agile methods that they find it difficult to relate to teams that are at the start of the agile journey, they try to push the teams to new concepts before they are ready, rather than guiding them to their own growth. 

In the same way not all Agile methods are right for all teams or organizations, understanding the strengths of your teams and the strengths of you coaches and finding a match may be the key to success. Some teams may require more time with them than others too, this is not necessarily a reflection on the ability of the team or the coach but on the skills being improved and the type of coaching that is happening. Sometimes a change of coach can stir things up and open new growth opportunities.

Overall I’d suggest that a coach is more guide than leader and asking one for advice is not a sign of weakness, it is a sign of strength. none of us know everything and the willingness to ask for help to learn is a crucial step to growth.








The effect of Bystander Syndrome on an Agile team

For those unfamiliar with the term, Bystander Syndrome is a condition where responsibility is diffused as a group becomes larger.

From Wikipedia:

The bystander effect, or bystander apathy, is a social psychological phenomenon that refers to cases in which individuals do not offer any means of help to a victim when other people are present. The probability of help is inversely related to the number of bystanders. In other words, the greater the number of bystanders, the less likely it is that any one of them will help. Several variables help to explain why the bystander effect occurs. These variables include: ambiguity, cohesiveness and diffusion of responsibility.

The larger the team the lower the sense of responsibility.

I have noticed a similar trend with self-organizing Agile teams, as the team becomes larger the individuals on the team appear to show signs of becoming less accountable and have less of a sense of responsibility for issues on the team.  Dull or unpleasant tasks get ignored and deferred, whole team action items get ignored with the defense that they expected someone else to take it.    With self-organizing teams there is no single person that is accountable for this and the accountability is so diffused that there is no sense of responsibility. Accountability is reduced proportionally to the size of the team.

But even when there are just two in the team there can be issues. I am sure every other married couple is perfect and this doesn’t apply to you, but there are many occasions where my wife and I each assume another will do a job, only to discover that neither of us has done it.  “Did you pay the gas bill?”  Some jobs have a tendency to fall between our fields of responsibility and get missed. As a result of this we now have a whiteboard in the kitchen and on a daily basis I can see the jobs I have been avoiding and hoping someone else will do.


My observations

Behavior changes depending on the circumstances and how clear the expectation of responsibility is. For example:  If there was a system where the team needs to go and look at a queue of service issues they would be far less likely to look and take up the task, than if the issue was emailed to the entire team.  And the larger the team, the less likely any one individual was to look.

What is particularly noticeable was when a single person was specifically named in an email and asked to look, the response rate would be much higher, and if someone came in person to ask a particular person the rate would be higher still.   In essence the harder it becomes to avoid acceptance of responsibility the more responsibility we seem to accept. But it all seems to be subconscious. I would hazard a guess that the team were not overtly aware that they were dodging responsibility. In most cases each individually felt what they were doing was the most important task for them.

I am not a psychologist and these are just observations of a few teams in action, but much to my disappointment it appears to conflict with my notion that self-organized teams are the ideal.

Where no leader is assigned a hero emerges (or a martyr).

An exception to bystander syndrome seems to be an emergent hero, someone who sees the lack of responsibility and begins to fill the void. Often one member of the team would end up taking the defacto responsibility upon themselves, even though it should be a shared responsibility, this sometimes results in a variation of siloing. The consequence of this is that a hidden dependency occurs, and as there is no formal responsibility when that person is on leave the task gets forgotten or ignored. This may also result in negative behaviors such as informal internal hierarchies or power plays.

This situation also builds resentment, if the self anointed person is making decisions for the team the others may resent this “decision making without authority”, if the tasks are dull or menial then the self anointed martyr may resent feeling obliged to pick up the slack. Neither outcome is healthy and may require an outside impartial person to see and help overcome the resulting dysfunctions.

The value of visualizing your work

In Scrum we ‘forecast’ the work at the start of the Sprint and the tasks are added to the ToDo column on the board, with KanBan we have a prioritized backlog of ready items to take and we take the items from the ready queue (ideally in order).  In both cases similar behaviours occur. Some team members have a greater sense of responsibility than others and so unpleasant work is not evenly distributed, the enthusiasts or martyrs take undesirable jobs. And if any work doesn’t get put on the board the team feels free to ignore it entirely.  Which is why it is so crucial to create cards for all work needing to done by the team and clearly prioritize them, and why the use of a board becomes so valuable for self-organizing teams. It is a way to visualize our work, and by doing so we visualize and reinforce our responsibility.  The board is pretty hard to ignore. In many respects the board become the boss. It tells you what to do, what is most important and which things need help.


Action Items from meetings

Ever noticed how in a meeting the whole room can agree that something needs to be done but when asked who will do it, the whole room goes silent. We suddenly become bystanders hoping that it is someone else’s problem, that someone else will volunteer. But as a self-organising team we are all equally responsible aren’t we?

This is a point of internal conflict for me, if an action item does not have an owner it often doesn’t get done, so it is normal practice to assign an owner. We make someone accountable before we leave the room, but by doing so we immediately absolve everyone else of responsibility. We create a silo, maybe it is just for that action item, but it is still a single point of failure. The creation of unnecessary silos is something that I don’t like on principle, but at the same time I am well aware that silos are the best way to get something done. When responsibility is clear the task is far more likely to get done.

My ideal would be to defer the decision on who will do a task until the task is started. When Fred – the team martyr – volunteers to take every action item, because the rest of the team suddenly find something fascinating on their phones or on the ceiling when it comes time to ask for a volunteer, we create a situation where he becomes a bottleneck,  others could do the task, but feel they are unable to because it has been assigned. If the task does not make it to the board we may not even realize he is a bottleneck.

But deferring deciding who brings us back to a situation of a task falling through the gap. My preference is to assign a task for someone to create a card to put on the board for any action item. (I’m always looking for a better way.) It feels like the right sort of compromise, someone takes responsibility for getting the card to the board, so we can be confident it will get there, and once on the board and prioritized the teams understand the need to pull tasks in priority order. Leaving the decision of who will do it until the last responsible moment.

Team size

Independently and for reasons other than diffusion of responsibility, Parkinson (as in Parkinson’s Law), concluded mathematically that groups larger than 20 were ineffective and that the optimal max size for an effective group was 8 or less, which by happy coincidence is pretty close to the Scrum guide of a max of 9.

He was studying governments and leadership groups but the same principles apply to any group asked to make independent decisions and has shared responsibility and accountability.  He found that the communication overhead of larger groups made decision making hard. He also noticed a tendency for the groups to focus time and energy on topics the whole team could understand. Which resulted in a bias towards triviality, the less complicated the topic the more you could become involved.

Smaller groups were generally more effective and better able to make decisions.

What exactly does a manager do?

Most of us have had managers at some point, and in business they are widely accepted as a necessary overhead.  Mostly management is about organisation and communication. A manager is a single point for communicating downwards, they are a focal point for communicating upwards. They can be a decision maker, they can set priorities, they can remind us of responsibilities. They can remove obstacles. They can guide and support and resolve disagreements. Often they also do administration, and reporting. Set goals and ensure you are working on the right thing, are getting the training and support needed, and perhaps even ensuring you are happy in your work. Not much of that requires authority, it is mostly support.

For some of us we have been lucky. Occasionally I have had a boss that I have hardly noticed, he has given me space to do many of these responsibilities myself, only being there when absolutely needed. A boss can do this when he is confident that he can trust you, and that you are able to perform the role independently.

So if sometimes bosses can do this, why not all the time? Is the need for a manager a reflection that the team cannot function without her, or is it because she doesn’t trust the team?  My guess is that sometimes it is one; sometimes the other and sometimes a bit of both.

How does it help us?

This is all very interesting but how does it help us?  I think  there are a few things we can learn. The first is that we are asking people to be both independent self-starters and great team players in the same breath. I am not sure those of us that have been in this space for a while can remember how tough these two skills are to learn and how often at first they feel like they conflict with each other.

Most people grow up with parents setting boundaries and stepping in when needed, or teachers setting clear guidelines.  Most jobs have someone checking to ensure you are clear what you need to do and to ensure you are following through on your responsibilities. So taking that away with no support mechanism is risky. Even people used to making suggestions still expect someone else to decide. And worst of all most people grow up believing that making mistakes is a bad thing. You cannot expect people to unlearn these behaviours over night simply because we believe self-organised teams are great.

Ask someone if they would rather not have a boss and they will jump at the chance, that is until they realize that not having a boss means accepting all their boss’s responsibilities.

What we can learn from this?

  1. If you can avoid it do not have teams greater that 8 people.  Communication and decision making are significantly improved. Bystander syndrome is reduced and responsibility increased.
  2. Ask yourself – do you really need a Manager, or a Team Lead or a Project Manager for this team?  What role do they provide that the team alone cannot?  If the reason is a question of trust or the skill level of the team, what can be done to resolve that? If a team ‘needs’ someone to manage them, I’d suggest this is a sign of other deeper issues.
  3. Self-organizing teams require new and different skills, these are learnt skills and will take time to master. Provide support and guidance and let the team learn them. Be on the look out for emergent leaders or martyrs and help the team become aware of them too.
  4. Visualizing work is one of the most powerful ways I have encountered for reinforcing awareness and acceptance of responsibilities. A kanban board is far more effective than any status report or project plan.
  5. Mistakes are powerful learning tools. Help the team learn to fail safely. Hold regular retrospectives and celebrate the mistakes, find new and better ways to work as a team.

My final thought is that there are many things a team can do on their own, I believe that with the right support, training and experience a team can function almost independently. Certainly without the need for middle management or project management. But that doesn’t mean it will be easy, or that you can simply pull the manager and step back.

Scrum introduces a Scrum Master as a transitional role to guide the team towards independence, and Agile Coaches may do the same in other environments but more likely in a less structured manner, but in both cases the goal is to create independent self-organised and continually improving teams.



Building on the foundations of Joy

I have recently finished reading the book Joy Inc. by Richard Sheridan which is the story of a small software company that has been successful, most notably as being a great place to work. The CEO had come from a an extremely successful start to his career, he had been promoted up the greasy pole to VP of software for an established firm and he had become wealthy in the process. By most conventional accounts he was a success, but he wasn’t happy.  He made a decision to change his work environment with a focus on creating a place that made him happy to come to work. This single minded goal eventually led to the forming of a software company – Menlo – with him as CEO where he could create a place of work that brought him ‘Joy’.

For those familiar with the work of Ayn Rand, I found a great many correlations between Richard Sheridan and Howard Roarke from ‘The Fountainhead’.  Rich Sheridan had a very single minded vision and he chose the path his company would take without compromising on his views. The book portrays how he set the direction and imposed his plan of how things should be done, resulting in a company that has adopted many of the XP practices described by Kent Beck.  The business has been successful and the workers are happy, Pair Programming, short iterations, innovative software solutions and a focus on quality.  The workplace includes dogs and babies and sound like a fun environment. In many respects at first appearance this is a model that we could learn a lot from.

Rich Sheridan has demonstrated the effectiveness of using Agile Practices and that success doesn’t require death marches and unrealistic expectations. Rich has shown one way it can be done, and there is a lot to admire in how he has achieved it. There is certainly a lot to learn and I think there are a great many aspects of what he has done at Menlo that could be used as the foundations of creating a great company.

I don’t build in order to have clients, I have clients in order to build…

Ayn Rand

However, much as I admire Rich and see him as a modern day Howard Roark, it is because of that comparison that I also have a number of reservations.  Rich himself refers to the book “Good to Great” and he acknowledges that he is not a Level 5 leader, this was an assessment I shared whilst reading the book. All his decisions were about creating Joy for himself, but there were dozens of examples in the book of absolutes, where his vision may not be compromised. I got the impression that he made all the decisions, he decided a process and it must be followed, if someone wanted something – such as the wonderful example of babies in the office – they asked him. The decision to allow babies in the office seems to be as much about wanting to be regarded as a great boss as anything else. That is not a bad thing but I am assessing this in terms of a model that can be replicated. 

Rich is uncompromising in his objectivism and Ayn Rand would be proud. Which is only half a compliment, I always admired Howard Roark, for a while he was an inspiration for me, but at some point I realised that taking input from others didn’t automatically mean you were compromising your principles or were weak, we can learn and adapt and improve but still stay faithful to our principles.

Recruitment and single person decision making

His recruitment policy is a great example of what I see as this type of blinkered thinking. Rich has introduced a recruitment policy designed to prevent making mistakes in hiring.  The problem is that his solution is to require two separate interview days, and then a 3-week trial, and after this they make a decision and the vast majority will be unsuccessful.  Anyone else see the flaws in this? 

To get hired you must give up 17 days for one interview. For most people with jobs that is not even close to being possible, and for an good candidate looking they will likely have multiple options open to them and this level of barriers to entry makes it highly unlikely that any good candidate would bother or be able to apply.  Therefore he is limiting his recruitment to the unemployed and graduates that are able to meet his interview requirements.  Now this pool will contain some good (if inexperienced) candidates, but the process has excluded so many other great candidates that I think it is an example of a process that has forgotten what the problem is that it is trying to solve. In this case I assume to hire great employees.

He clearly loves face to face communication and paper based systems and estimation using hours. Therefore everyone must comply, everyone must communicate face to face, they may only use paper based processes and must use hours for estimation. It is not that I am questioning whether the decisions are good or bad, clearly he is getting many right – he wouldn’t be successful otherwise, but it is a company built around a single individual. He is seemingly a strong CEO and charismatic leader, but that leads to an unsustainable business model, where does it leave Menlo when he moves on? What is his succession plan?

Using Agile practices doesn’t make you agile

Menlo use a variety of Agile practices, mostly from XP, but from the way the book describes it they are a set of rules fixed in stone, thou shalt do it this way…

The practices chosen are good practices, but I don’t think that Agile is about using best practices, I think it is about a mindset of improvement. Menlo had adopted a variety of practices that generally I support and endorse, but I didn’t get any sense that there was a culture of reflecting and improvement. Retrospectives did not seem to be part of the accepted practices at Menlo.  This for me was the saddest omission, without retrospectives Agile is weak and ultimately cannot survive in the long run. Menlo seem to have adopted 11 of the 12 principles, but it is the 12th that I value most.

I so wanted to enjoy this book, it is one I had looked forward to reading for a while, but in the end I was left feeling that Menlo was actually on the wrong path. Not that using XP was wrong, but if you have a culture that is not always seeking to improve it will eventually fail. 

I probably sound horribly hubristic, and I have not achieved the level of success Rich Sheridan has, so this may sound hollow.  But Rich, please introduce retrospectives into your culture before it is too late and be prepared to let your teams guide you to improve, you may me amazed to find they have some great ideas. If you do I think you may find a way to improve on the Joy you have already found.