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.

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
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.
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)
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)
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.
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.

Reality

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.

Diversity

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.

Team leadership in Agile teams

Yesterday I had two people both of whom I have a lot of respect for, independently say that having a single person in charge of a team ‘works‘.

I was taken aback by this, partly the surprise that two people would say the same thing on the same day, but mostly because this goes against my experience and my opinions on good team leadership. This caused me to step back and reconsider my opinion and my reasons for it. For me there is a great pleasure in being challenged on my opinions especially ones that I was so sure of and so I have given it a lot of thought.

My experience

I have worked for other people directly or indirectly for more than 25 years, and I have managed teams myself, I have also coached quite a few teams – so was able to witness leadership from the sidelines. By a very quick count of those I can remember I would say that 70-80% of them were (in my personal opinion) poor leaders, there were a few that got the job done by force of will, or by leveraging authority, or by imposing death marches on the team. The organisation sometimes saw them as successful but the teams thought them dictators or bullies.

Many team leads simply were unwilling to see any perspective other than their own. Others who were clearly insecure at accepting other people’s ideas. But there were a few good or even great leaders that didn’t see management as a tool for control but as a scaffold for building the team and achieving things, if only these could be cloned.

So I am probably coloured by my experiences but the notion of one person in charge of the team fills me with dread. and whilst I wholeheartedly agree that the model of a single leader can work with the right person, that does not mean that it will work in most cases or that those qualities are the norm, and it certainly doesn’t mean it will work as a model in every case. What is more I think those great leaders would thrive in an environment where they didn’t have defined authority- but more on that later.

I can only imagine that just as I have been coloured by my experiences my colleagues have equally been coloured by theirs but they have had the good fortune to see better leaders than I have and I would like to (and will) discuss this further with them to see why they feel this is a good approach and whether my instinctive reaction and poor experiences are in contrast to theirs.

“Leadership should mean giving control rather than taking control and creating leaders rather than forging followers.”

David Marquet

oh Captain, my Captain

The military is often used as an example of one named leader, but there is a distinction in the military and that is they have needs that are very different to a software team. Those differences are a need for independence and a desire for expedience in decision making: Military units will often need to operate independently without contact with their parent structure. So it may be necessary for a local arbiter. In a business environment it is rare that a disagreement is so urgent that it could not be referred up if there was a dispute with an impasse. The other aspect of a military organisation is that life and death decisions need to be made very quickly and so there may not be the luxury of time to debate and reach consensus.

However, even in military structures there are examples of leaders who take the view that they are the Product Owners, they will say this is what I want to achieve, you tell me how… and then the suggestions are made and the leader simply endorses the team’s advice (Make it so..). Naturally there is an element of accountability but the trust that this demonstrates in the team is significant in empowering the team and growing them.

This notion is explored more deeply in this book: Turn this ship around

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Agile principle No 5.

We want conflict and debate

In software teams it is often the debate that produces the greatest thinking and ideas so stifling the debate is a negative. Having a single person making decisions stifles debate, it thwarts conversation, and it disempowers the team. If a team is overruled often enough they will stop making suggestions, if one person becomes so myopic in their opinions it can make the team feel powerless and excluded. Also where there is a defined leader they have a tendency to not be transparent, information is selectively shared (in both directions) and again lack of information impedes debate. In short I believe that having a defined leader is in conflict with the Agile principles.

The best architectures, requirements, and designs emerge from self-organizing teams.

Agile principle No 11.

Merging the what and the how

Having the same person responsible for both the what (vision) and the how (implementation) stifles innovation. Rather than the team determining the best architecture and the best solution it becomes driven by a single individual. Again this is at conflict with the Agile principles, and whilst you may say that a good leader wouldn’t let this happen, experience and evidence is to the contrary. Power corrupts and if someone has the responsibility and authority it becomes hard for them not to use it especially if they perceive the team is making a mistake, and if teams are prevented from making mistakes they will stop experimenting.

We want balance

And this is where my agenda is. Software development is a balance of content, quality, cost, value, consistency, team growth and a variety of other factors. It is rare or at least uncommon to have a single individual that is able to understand and balance those conflicting elements effectively on their own. More often a single individual prioritises one above the others, driving to a deadline, or gold plating a solution, or any other single aspect usually becomes prioritised at the expense of the rest.

I believe that a model where there is shared leadership and shared management between multiple roles solves many of these problems. Having someone focused on the what and others focused on the how and someone else focused on team improvement and consistency creates conflict (deliberately) but it also creates balance and it becomes a catalyst for debate.

We don’t want a single point of failure or a silo

If we make one person responsible for direction, implementation and team growth, we are putting all our eggs in one basket, if they are on leave or sick or move on then the impact can be significant. There can be so much knowledge tied up in one person they become indispensable.

Problems with the shared leadership model

First and foremost there is a cost. For small teams it may be difficult to find team members that have a natural affiliation to the balanced leadership model, with part time POs or coaches/scrum masters or where those roles are not named but the responsibilities are shared it can be tricky. But even then I would say that calling one person ‘Lead’ or ‘Manager’ or anything of that sort is destructive. And the notion of combining Coach, PO and implementation into just one named role can lead to dysfunction. In many respects I wonder if the cost of additional named roles is worth it just to prevent the dysfunction a single leader creates. Or if the team is too small to warrant the explicit roles then get rid of named roles entirely – if a team is that small naming a leader should also be unnecessary, they ought to be able to self-organise within those boundaries.

This may sound hypocritical, after all I have spent a good proportion of my career with leader or manager in my job title. But my experiences have been an internal conflict in that role. As a Software Development Manager you become the defacto Product Owner, Project Manager, architect and team coach. But there was always pressure from somewhere and normally that pressure was to the detriment of the team, when I challenged it, I did so a personal risk. Customer and senior management pressure to deliver, cuts costs and drive timelines meant that team growth became secondary, team welfare was deprioritised and making a safe place for teams to learn from mistakes was difficult to justify. Some of that is company culture but I believe much of that comes from the pressure of responsibility and bestowing leadership carries pressure and expectation (sometimes real, sometimes assumed). And speaking as someone that has experienced it, I’d rather share that responsibility.

Conclusion

So after sleeping on the issue I am even more convinced that a named leader – whether it be Team lead, tech lead, manager, senior or nerd wrangler, goes against the principles of Agile, I believe it undermines self organising teams and leads to dysfunction and imbalance. There absolutely are exceptions and there are some team leads that are effective, but I wonder if they would be just as effective or more so in a self-organising team structure. But there are more examples of ineffective team leads where the power corrupts and they dominate the team, stifle debate and innovation and disrupt or impede team growth.

In my very personal opinion the best leadership model is a balance of What, How and Team Improvement, and the more people those responsibilities are spread amongst the better. In practical terms I’d like to see a team with a PO to determine the What but a PO who actively engages with the team. A coach that is focused on the Team’s improvement and process improvement, and the rest of the team is responsible for the How. Within the team there is no need to identify a senior or a leader they can work out amongst themselves how best to make decisions and titles get in the way. This model may come with a cost and it may be difficult to get the balance right but in my experience this balance leads to the best results.

Ironically the examples of leaders that I have seen as being successful (as measured by both results and team morale) have voluntarily and noticeable made themselves servant leaders, stepping back and inviting the team in, choosing to give away authority and creating healthy debate and healthy conflict. So if that is how they lead effectively why not make that the model to start from?

Why I came to adopt an Agile mindset.

Ultimately it was because of seeing poor leaders disempower the team and abuse teams into death marches and drive poor design decisions that I came into Agile in the first place. I saw Agile as a method for empowering the teams and taking away abusive power from lone leaders. The stimulating of constructive conflict and healthy debate are so essential to the process that I object to any impediment to this on principle.

To my delight in most cases Agile has done that and so much more, in a creative environment like software the gains of self organised teams so massively outweigh the losses that result from a lack of a single clear leader that I am more confident in my opinion that the words ‘lead’ or ‘manager’ have no place in job titles on an agile team. I would love to trial and experiment to compare, but as much of this comes down to the personality of the people involved it is hard to do more than make subjective experience based assessments.