Tag: Coach

A tale of two engineers.

There are two ships traveling a busy shipping route, each ship has a complex engine and the engineering team has a chief engineer. Both ships are a similar age and size.

The first ship has a very busy chief engineer running this way and that, fixing any and every problem that comes up, he knows every inch of the engine and many parts of it are custom made by him. He is dirty and oily and hard working, whenever there is a problem – and there are many problems – he is on hand to fix it. He is dedicated and hard working, he works long hours and is always ready and willing to get his hands dirty. Without him the ship couldn’t function.

The second chief engineer has spent his time not fixing things, if a part is unreliable he has replaced it, if a component is troublesome it is gone. If there is a problem he ensures one of his team fixes it (with guidance initially) and will encourage them to spread the knowledge so that after a while he rarely if ever gets his hands dirty. He is rarely dirty or oily and it is a very rare situation to see him fixing anything. On many voyages he can seemingly sit there with his feet up doing very little in maintaining the ship and can use his time on other productive activities. Frankly if he missed a voyage the ship would probably run just fine without him.

Now which in your opinion is the better chief engineer?  I know which one I would rather have on my team.

It is often said that the goal of a good Scrum Master is to make themselves redundant, I take exception to this a little I think as in the tale above it is possible to create a situation where you are not necessarily needed all the time. But I wonder how long a team would last as a top-performing team if the Scrum Master was taken away, perhaps in the short term no one would notice, but growing and shaping and coaching a team takes time and effort, but slipping back into bad habits can happen quickly. Creating a situation where the Scrum Master has time to do other things is a good thing and a reflection of success not a sign he is not needed. A Scrum Master that is essential to a team is one that has failed, in fact if ever you feel you have an employee you are overly dependent on you have a serious issue.

How many top athletes would say “I’ve reached me peak I no longer need my coach”? My guess is that if they feel they have reached their peak they will seek out a new coach that can push those limits further.

A good coach or Scrum Master guides the team to independence, and then pushes their limits further.  They may be more useful elsewhere but that is very different from becoming redundant.

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.

file-21-09-2016-15-57-29

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.

coaching

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.

The value of a ScrumMaster

In June 2014 a new ScrumMaster was brought in to work with an existing and established development team

At the point of joining the team had already raised concerns about environments and tools but the team had been unable to express specific issues that could be resolved, these problems had been intermittent for most of the year.   The team was composed of a BA acting as Product Owner, a Lead Engineer, three other developers and two testers with the addition of a ScrumMaster this made a team of size 8, which equates to an approximate cost to the business of around £600,000/$1,000,000 a year.

The team measure their productivity using a term called velocity, which is how much work measured using a relative scale is achieved over a period of time. The amount of work fluctuates for a variety of reasons, holidays, sickness, bugfixing, mistakes, environmental issues, focus or context switching, support requirements, spikes etc.  It is an anecdotal estimate of productivity only. But has become the industry de facto standard for measuring improvement. This had been recorded over the previous year and the documented average for the 12 months preceding the new ScrumMaster is noted below as 100 basis points per week.

Velocity can only be used to compare a team with it’s own past performance, i.e. it is a relative scale, not an absolute measure but in that context it is very useful. But should be used with caution. In this case the team had an existing Datum and a set of benchmark stories. The Datum was not modified and the benchmark stories remained in this period, thus there is a consistent base level for comparison.

Year 1 (Prior to ScrumMaster)

image001

The new ScrumMaster, spent some time with the team, observing and evaluating. He sought to identify problem areas and any behaviour in the team where improvements could be made. But unlike a conventional manager or trouble-shooter he did not issue directives on changes to behaviour.

The team scheduled regular ‘retrospective’ meetings where they review the past time period and look for ways to improve.  The ScrumMaster used a variety of techniques, to coach and guide the team to focus on areas identified either by the team or by the ScrumMaster as problematic or where improvement could be made. The ScrumMaster collected and compiled metrics to aid this analysis, and facilitated meetings to be productive in deconstructing problems in a non-negative manner.

By using this approach the ScrumMaster did not solve the teams problems, he did not offer ‘his’ solution to the team, nor issue directives for improvement. The ScrumMaster worked with the team to enable them to become aware of their problems and the ScrumMaster created an environment where the team were empowered to solve their own problems. The ScrumMaster uses his past experience to identify problems and may steer the team to suitable solutions, but relies on the team to solve their own problems.

In the following quarter there was a notable upturn in velocity (productivity)

Year 2 (First quarter after ScrumMaster)

image002

The ScrumMaster is responsible for creating an environment where the team can reach a long-term and consistent performance – a spike or a blip is not considered sustainable, so it is important to not seek to boost productivity with short-term fixes like overtime or cutting quality. The aim is sustainable pace and sustainable quality over the long-term.

The ScrumMaster continued to work with the team identifying more bottle-necks and waste, removing impediments and coaching the team how to work around impediments or resolve them themselves, there is always room for improvement in a team.

The ScrumMaster also spent time coaching the Product Owner and Programme Manager on expectations and in their interactions with the Scrum Team, including challenging the Programme Manager on how his priorities are fed to the team so that the team could focus to be more effective.

Year 2 (First full year with new ScrumMaster)

image003

Velocity is only one measure of productivity and is largely anecdotal, however it is the only real measure we currently have available.  The productivity improvement should be considered in that context. However, there is a clear and notable improvement in the productivity of the team over the 12 month period.  The team deserves the credit for the improvement as they have improved themselves.  But by adding an experienced ScrumMaster to an existing team he has been able to coach the team into identifying ways they could improve and in doing so doubling their productivity – a significant change in just 1 year.  In this instance it could be argued that the ScrumMaster’s coaching of this one team has resulted in £600,000/$1,000,000 worth of added value to the business and assuming the team does not regress this is an ongoing year on year gain. 

It is not often possible to measure the impact on a team, and velocity is a fragile tool for that, but I hope it is clear from these metrics the value that one person can have on a team.  It is highly likely that Year 3 will not have the same growth but even if the new velocity can be merely sustained the value to the organisation is significant.

Vision without action is a daydream. Action without vision is a nightmare

Waterfall vs Agile?

Sounds a bit daft to even be having the debate, surely by now there is no one left that still thinks waterfall is the better choice for delivery of complex software projects, unfortunately that is very far from the truth, there seem to be many that still prefer waterfall and recently I even heard it talked of in terms of the good old days.  So I delved a little deeper.

In this instance the source was a statement by someone who’s opinion was given weight. The comment was:

I could deliver ‘project x’ using waterfall if you gave me dedicated resources and we could lock ourselves away for 6-months.  

In waterfall the costs of planning are high, the costs of analysis is high, and the cost of change is very high. But by it’s nature waterfall has a clear scope(vision).   The result is that everyone is clear on the priority, the project is protected, no change and no disruption, the scope doesn’t change. Because everyone understands the cost of interruption.

In Agile the upfront cost of planning is low, the upfront cost of analysis is low and the cost of change is relatively low. The result in some cases is that ‘unnecessary’ direction change can be frequent, the project is unprotected because it can adjust, disruption can be frequent, and so the scope regularly changes for sometimes trivial reasons or low priority distractions.

In short we are not comparing apples with apples.  We are comparing focused vision-led waterfall, with an unfocused ad-hoc agile.

In the example above the team had a fairly vague goal to deliver ‘x’ but also support ‘project y’ and deliver small increments of ‘project z’, ‘project w’ and maybe even an update to ‘project v’ too. And that plan was likely to change next week when something else came along. Because of this ‘project x’ was taking far longer than anticipated. so this notion that delivery using waterfall would be quicker has arisen.

But, the problem for me is that it was not the ‘waterfall’ part of the plan that would ensure success, it was the dedicated resources and clear vision that were the crucial aspects.  Give me a clear vision and those same dedicated resources and I can be pretty sure that I would deliver what the customer wants, sooner, cheaper and more reliably using Scrum than someone else could using waterfall.

Agile is the victim of it’s own agility, it is like the free gift no one values.  Because there is less pain in changing direction in agile projects, and because the team can adjust and adapt, that doesn’t make it free and it doesn’t mean it isn’t disruptive.

Agile enables you to have flexibility in planning, it allows deferring decisions, it allows planning only small amounts, and allows changes in direction and content.  But just because you can do these things doesn’t mean you always should.

A single vision with dedicated resources is a powerful combination, Agile is a powerful tool, but as they say with great power comes great responsibility.

Agile enables you to vary the scope of your vision, to respond to change, it is not a licence to operate without a vision.

As the Japanese proverb goes:

Vision without action is a daydream.  Action without vision is a nightmare.

Who is interviewing who?

How I’d like to do it.

My advice would be to concentrate first and foremost on creating a place where people would want to work, then marketing your organisation to the candidate, they should really want to work for your company, that way you start with a better candidate pool, immediately giving you a better chance of finding the best employees.

Then – even if it feels impersonal, a series of consistent structured tests (IQ and Psychometric) and then formal structured interview questions where the results and responses are noted and then referred onto an independent panel for a decision on hiring. Forget the gut-feel, forget the technical questions, forget hostile interview techniques, they really don’t work. Throughout all this ensure the candidates are treated well and made to feel important.

Sounds like hard work, it sounds like it undermines the hiring manager, it sounds incredibly time-consuming and bureaucratic, perhaps even expensive. But if your goal is to consistently hire good quality candidates it is going to be hard work and you will have to accept that there are some things that cannot be effectively and consistently assessed in an interview situation.

My final thought is that if you have got your hiring right, it is very likely that the most capable, most experienced and most reliable person for a role is the one currently in it. Don’t lose them.  Look after good employees they are your company’s most valuable asset.  Treat them well and do whatever it takes to keep them.

recruitment tips

And next time you are in an interview situation, ask yourself who is interviewing who?

Typical interview styles

The interview itself.

What I have observed is that interviewing is generally composed of one or more of a very small number of techniques:

  1.  Free-form, gut-feel unstructured or semi-structured chat and questions between candidate and hiring manager.

  2.  More formal pre-defined questions structured and consistently asked to all candidates.

  3.  Some variety of standardised test, essentially IQ based.

  4.  Questions posed by a technical expert with a desire to highlight his superiority rather than assess your capability.

  5.  A technical test or series of technical questions intended to be pragmatic and fair.

  6.  Aggressive panel questioning

  7.  Psychometric testing: verbal/numeric/diagrammatic reasoning or personality tests.

  8.  Presentation by interviewer on why the candidate should work for you.

There are studies and statistics that rank the effectiveness of the different techniques for selecting good candidates, I won’t pour them out here – I am not an expert and I’d just embarrass myself. But in my experience 1 is the most common, often combined with 4 or 5. But logic states that 4 is a waste of time and puts off candidates, and studies show that 1 and 5 are actually very, very poor indicators of ability and capability for the role and do not result in long-term success.

So what works? 

2, 3 and 7 are by far a better method of assessing candidates, followed by an independent panel-decision based on the documented evidence taken from the interviews – the interviewer should not be allowed to make the decision independently as they display bias (subconscious or otherwise).

But 2, 3 and 7 are hard, it requires yet more work on what is already a tough and time-consuming process, so very rarely gets done.

The reciprocal nature of an interview (8) is so often overlooked, if you want the best people and you want to get the best out of them, then not only do you need to decide if they are right for you, you need to convince them that your business/team is right for them. You should be putting as much effort in to impressing candidates as they put into impressing you. You are competing for them in a buoyant market.

recruitment2

Doing it right.

As an interviewer, my best experience has been for a company that did a combination of 2, 3, 7 and 5. We put a lot of effort into interviewing, but the majority of people still failed the combination of tests, especially the technical test. The test felt ‘easy’ to us and some candidates did well, but the results didn’t match the apparent skills of candidates, in hindsight I think it confused the process. The problem is that technical tests are not effective at assessing ability during an interview, there are simply so many other factors at play.

Relying on structured questions, IQ tests and psychometric tests may feel clinical and impersonal, but very likely the best way to find the right candidate. But ego plays a role and when hiring for a team, we are only human and so many hiring managers want to rely on their own instinct, even if evidence demonstrates this is unreliable, so it is hardly a surprise that many hiring managers favour their instinct over a structured process.

What makes a good interview?

My experience of recruitment is largely anecdotal, I am not a professional interviewer or HR expert. My limited experience of interviewing has been as a candidate, a hiring manager, or sometimes even as a subject expert. I’d estimate that over my career my experience is approximately 8:1 in favour of being an interviewer over being an interviewee, but I have been on both sides of the table often enough to know how it feels from either perspective. 

Over the last 5 or so years the amount of effort I have put into recruitment has been considerable, especially considering it is not really meant to be a significant part of my role. I’d estimate that I have hired an average of one person ever 2 months or so.   I even like to think I am pretty good at it,  although as you will see I am probably mistaken in that opinion.

What is striking though is how much time this takes, very anecdotally I’d estimate that depending on the quality of the CVs that I receive, on average only 5% will make it through the screening and interviewing to getting an offer(probably less). But the 95% that get rejected still consume a lot of time, and of the 5% selected we don’t always get it right, and I’m pretty sure quite a few good candidates get missed. The process is far from ideal.

recruitment

But what makes for a good interview?

As a candidate I have had interviews lasting less than 15 minutes (where I was offered) and interviews spanning 3 days, for a graduate recruitment programme, and just about everything in between. I have had good experiences and bad.

Some, in fact most interviewers seem to forget that the candidate is also interviewing them, and that the candidate is deciding if they want to work with you in the same way you are assessing them – it is not a one way decision by any stretch. Such is the lack of understanding and sheer arrogance of some that I have been asked extremely obscure technical questions that provide no clear value, I have been challenged(insulted) to gauge my response, I have had panel of interviewers quick-firing questions and had interviewers who were clearly reading my CV for the first time during the interview.  Why would any good candidate have any desire to work for you after an interview like that?

I haven’t kept accurate records, and I appreciate this is anecdotal but I’d estimate I have turned down close to three job offers for every one I have accepted over my career. Now I am well aware that I am fortunate to have in-demand skills at a time when the market is booming, I have also had a lot of rejection.  Similarly, as a hiring manager I’ve had too many candidates turn down offers, or more frustrating get a better offer before we could complete the hiring process.

The hiring process is so expensive and so important I am surprised at how often it is treated in a cavalier manner.   Why oh why would you be so arrogant to treat candidates with anything less than the respect you would expect them to show you?

Coaching is the easy option?

I have run into a strange dynamic in the agile transition today.   As part of the transition to an ‘Agile’ organisation I have been pushing HR to create and formally recognise new roles, specifically Scrum Master and Product Owner, up until now it has been by unofficial secondment.  Part of me feels pleased that we are getting traction over the move and formal recognition is a major step forward in the Civil Service.

But now I have hit a rather significant hurdle, how grades are classified, the Civil Service – or at least this particular location – classifies and grades roles based on accountability, responsibility and number of reporting staff.  So a servant leader that coaches and supports and has no direct reports comes out classified as a very junior admin assistant, the people doing the role it turns out are two or three grades higher than ‘proposed’ which is clearly a serious mismatch.

The advice has been to reword the job description to add responsibilities and authority and accountability, but that feels wrong to me. I am trying to educate and apply Agile principles to the organisation and this feels like a very unpleasant compromise.

It seems that somehow coaching is classified as an easy skill and the lack of apparent direct accountability and responsibility does not sit well with the pigeon holes that the roles must fall in to.

I have tried explaining that coaching is actually far harder than managing, using coaching skills to help a team discover for themselves what to do next is a very difficult skill, but when done right what they learn gives a far deeper understanding and more likely to be maintained than any amount of compelling, controlling or micro managing task assignment.

Those involved seem to understand and appreciate what I am saying but we are challenging the system, it will be an uphill battle. This is new ground and a transition to Agile is rarely easy and it seems the bigger and more established the processes the harder it is to change.

But I wonder why coaching is seen as an easy option. It rarely is. A coach actually has to be pretty mean, they have to be tough.  We have to turn a mirror on people and often show them some unpleasant aspects of themselves, often they are unaware, which can be even tougher to deal with. I sometimes have to sit back and watch someone fail knowing I could have prevented it – not because I want to see them fail, but because failure can teach far more than correcting them.

I sometimes get pressure from management to assign tasks, or to get the expert to do a job because it is quicker, or to challenge certain behaviours directly. I resist and this can and often does reflect badly on me, but I resist because I believe providing an environment where the team learns for themselves is far more valuable than any short-term gain resulting from taking away their independence.

I see my job as protecting the team and creating an environment to grow and learn. I do this by asking a questions to provoke ideas, I challenge where I see potential, sometimes I stray into leading questions if I think it helps but I try very hard not to provide answers, and if I slip into leading rather than coaching I hope I get someone turning a mirror on me and coaching me how to be better.

I love my job, but I don’t coach because it is easy, I coach because someone needs to be tough and push you to do better.

There is a quote in Lyssa Adkins’ book – Coaching Agile teams, which I will paraphrase a little, it says so much.

A friend likes you the way you are, a coach respects you too-much to let you stay that way.

Anyone that thinks a coach or a Scrum Master is the easy option should try walking in those shoes for a while, it may put a whole new perspective on things.