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

Coaching on Agile Methods
Coaching teams that have identified a need for support in certain areas
Helping teams identify areas where they need support
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.

Summary

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.

Forecasting, asking the why? behind the When?

A Product Owner, or development team will often be asked for an estimate or a forecast for a product; a feature; an iteration; or a story. But when you go to a team member and ask them it is not uncommon for the colour to drain from their face, twitching to start, and their pulse to race. Past experience says that the next words they speak will haunt them for the foreseeable future, maybe even for the rest of their career. It is only a rough estimate you say to reassure them, but they just know you have other plans and the fate of mankind lies in the balance. Or so it seems.

dilbert estimate

The difference between a forecast and an estimate.

For most practical purposes there are only subtle differences, the main one being that a forecast deals exclusively with the future. When I think of the two I tend to think of an estimate as information and a forecast as expectation. It is likely that I will use estimates to create my forecast and I may use multiple estimates and even apply other factors to derive my subjective forecast. Whereas an estimate is generally an isolated objective assessment.

Both have huge degrees of variation; accuracy; precision; and risk factors, but in some instances it may very well be that my estimate and my forecast are the same for all practical purposes.

For example, If I was asked to estimate a journey, I may say that it is between 15 and 45 minutes and on average it is 30 minutes. If I am asked to forecast when I will arrive, that requires knowing not only the estimate but the time the journey starts and if there are other factors such as a need to stop to get fuel, or food. I may also add a certain weighting to the journey based on the time of day. Thus my forecast, whilst based on an estimate may not be the same as the estimate. Other times though I may simply take the estimate and it will become my forecast.

In practice though the terms are used interchangeably and likely it really makes very little difference, except when it comes to expectations. If I ask “How long will this take” I am asking for an estimate, if I ask “When will this be done” I am asking for a forecast, both are fine so long as everyone knows what is meant by the question.

Forecasting is misunderstood

Forecasting is guesswork, it may be scientific guesswork and it may be based on past experience and metrics and clever projection tools, but it is a guess. You will be wrong far more often than you are right. The more professional and clever and precise the forecast looks the more confidence you may instill in that guess. But it is still a guess, and when your audience gains undue confidence in your guess they have a tendency to believe it as fact not forecast. It might be that a guess is all that is needed but dressing a guess up and delivering it with confidence may create a perception of commitment.

A forecast is commitment (in the eyes of the one asking)

In normal circumstances by giving a forecast there is an implied commitment, even if you give caveat after caveat, and at any point where you even hint at a commitment to delivery to a fixed scope, fixed cost AND fixed date you are setting yourself up for disappointment. And sadly that is what a forecast is seen as by most people.

By all means work to a budget or a schedule or even a scope (although that is very likely to vary) but ideally ONLY one and never all three.

Understanding why a forecast is needed.

There are many reasons why people ask for forecasts, and the why is the most crucial aspect of the process. Understanding the why is the first step to providing the right information, and hopefully changing the conversation. Forecasting for stories and features is both more reliable and more accurate but the project/product level forecasting is where there is the most confusion and least understood purpose.

If possible, try to change the question of “When?” in to an understanding of “Why?”

Generally speaking we gather information to help us make decisions. If the information will have no bearing on our decisions then the gathering of that information is wasteful. Forecasting all too often falls into this category. We take time and effort to produce a forecast and yet the forecast has no bearing on any decision, that effort was wasted, or more often the level of detail in the forecast was unnecessary for the purpose for which it was used.

Making predictions of unknown work based on incomplete information and a variety of assumptions leads to poor decisions, especially when the questions being asked are not directly reflective of the decisions being made.

In my experience the Why? generally falls into three broad categories:

How long will this take?
How much will this cost? and
simple curiosity/routine.

But most people don’t ask why, they spend time creating a forecast and present it without knowing how it will be used. Some people asking for a forecast/estimate may not even know why they are asking, they just always get a forecast. But let us delve a little deeper.

How long will this take?

Why do you need to know? Some typical answers are:

I need to plan
I have dependencies
I need to prioritize
I have a deadline

How much will this cost?

Why do you need to know? Some typical answers are:

I want to know if I will get a good Return on Investment
I need to budget
I need to prioritize
I have limited available funds

Curiosity/routine

We always ask for a forecast, I need to put something in my report
I want reassurance that you know what you are doing
I want to know if my project is on track

What you will notice about these questions is that when you ask why, the first request for a forecast suddenly doesn’t make sense anymore, they are not really interested in the forecast itself, but in some other factor that they can infer from the forecast. If the intent is clear then the question can be tailored to get the required information in a better way.

e.g.

I need a forecast – Why?… I need to know when I can allocate staff to the next product/project.

In this case would a simple high level guess be sufficient? I feel confident that staff won’t be available for the next 3-6 months, in 3 months let’s review, I’ll have a better idea then…

I could put a lot of effort into a detailed forecast but an instinctive response may give all the information needed, saving us a lot of trouble.

I need a forecast – Why?… I want to ship this to maximize the Christmas shopping period – or I want to time the launch for a trade show etc.

This isn’t a request for a forecast, this is a request for an assurance that there will be something suitable available for a particular event/date. I can give you an assurance and confidence level without a detailed forecast, I may even change the priority of some features to ensure that those needs are factored into the product earlier. Or can de-scope some features to meet a certain date.

I need a forecast – Why?… I have limited funds available, and I want to know when I can start getting a return on this investment.

This isn’t a request for a forecast, it is a request to plan the product delivery so that revenue can be realized sooner and for the least investment. It may be possible to organise delivery so that future development is funded from delivering a reduced functionality product early. Or that development is spread over a longer period to meet your budget.

I need a forecast – Why?… I need to budget, The way this company works I must get approval for my project expenses and staffing in advance so I need to present forecasts of costs and timelines. This answer is twofold, first – can you challenge the process? It might be better to have a fixed staffing pool and prioritize products/projects such that the most important ones are done first and then move on to the next, in which case the forecast for this is irrelevant, it is a question of prioritization. Or if the issue is ensuring staffing for the forthcoming year could I simply say whether this product will not be completed in the next budget year?

I need a forecast – Why?… I want confidence that you know what you are doing. This is not a request for a forecast it is an assessment of trust in the team. There are many more reliable ways to ascertain confidence and trust in a team than asking for a forecast.

I need a forecast – Why?… I have a dependency on an aspect of this project. This may not be a request for a forecast of this project, but more a request to prioritize a dependency higher so it is completed sooner to enable other work to start.

I need a forecast – Why?… I want to know if my project is on track. Essentially what you are saying is that I want to track actual progress of work done, against a guess made in advance that was based on incomplete information and unclear expectations. And I will declare this project to be ahead or behind based on this. I am sure those of you reading this will know that what you are measuring here is the accuracy of the original guess, not the health of the project. But we have been doing that for decades so why stop now?

finally the closest to a genuine need for a forecast

I need a forecast – Why?… I need to prioritize or I want to know if I will get a good Return on Investment.

Both of these are very similar questions, but are really requests for estimates not forecasts a rough estimate helps me gauge the cost and when I evaluate that against my determination of the value expected to be gained from the project it may help me decide whether the project is worth doing at all or if there are other projects that are more important. E.g. If it is a short project it may impact my decision on priorities

But even here it not the estimate that has value it is just information that helps me evaluate and prioritize. If I already know that this project has huge value and will be my top priority does forecasting aid with that decision?

When does it make sense to forecast?

Listing those questions above it seems like I am suggesting that a request for a forecast is always the wrong question and is never really needed. And it is true that I did struggle to come up with a good example of when it makes sense to do a detailed project level forecast that included dates or any type of scheduling expectations.

It may be necessary for a sales contract, to have a common set of expectations. Although I would very much hope that sales contract for agile projects are for time and materials and are flexible in scope and dates, if not cost too. So for the purposes of setting expectations and in negotiations I can see that there is value in an estimate, although I do still wonder if a detailed forecast adds anything here that a reasonable cost estimate doesn’t cover. If possible I would rather work to an agreed date or an agreed budget than suggest a forecast that may lead to false expectations.

But the reality is that sometimes your customer does want one and wont tell you why, or doesn’t know why. Some customers (and managers) are willing to accept that a forecast will cost time and money and the more detailed it is the more it costs, and of course being more detailed may not make it any more accurate.

More detailed investigation for your forecasting is likely to build greater confidence but may not be more accurate and you should ask the question “will more detail have a material impact on your decisions?”, and if the extra effort wouldn’t affect your decision then it is just waste.

I would caution that if there is no other alternative and a forecast is made, that it is revised regularly and transparently, the sooner the forecast is seen as variable the more useful it is. There is so much assumption tied to a forecast that it becomes a ball and chain if there is not an expectation of it changing and so it must be refreshed regularly to prevent the early assumptions being seen as certainty, or they will lead to disappointment later.

Short term forecasting

The real value in forecasts is when the forecast is for a short frame of time. Over the short term we can have much more confidence in our forecasts, especially if we have been working on this project for a while and have historic information we can base our forecast on. There are fewer assumptions and less variables.

Can you forecast which features are likely to be included in the next release?
If I add a new feature now can you estimate a lead time for this?
Can you give me an estimate of how much this feature would cost?

By limiting the scope of the forecast to an areas where we have more confidence in our expectations the forecasts become more meaningful and whilst there is still a danger they are seen as commitments the risk is mitigated by the shorter time frame.

Alternatives to forecasting

Many of the questions above could have been resolved with much less effort than a detailed project level forecast. In most cases we could achieve sufficient accuracy for decision making with a high level estimate. E.g. A product like that is similar to ‘x’ therefore I’d estimate 4-8 months for a small team. Or as a rough estimate 12-18 months for two teams and calculate costs accordingly.

These estimates are certainly broad but if you have confidence in your teams and you believe they will use Agile principles to get value early and are able to communicate progress and be transparent with issues then I see no issue with broad estimates. It is sufficient to allocate staff and resources, to prioritize, to schedule and to determine Return on investment decisions.

For the other questions you may achieve far better answers through the use of Product/feature burndown charts, user story mapping, or even simple high level Road maps. These tools provide useful information which can be used for managing expectations, identifying dependencies and visualising the progress of a product. And crucially – aid in setting priorities and keeping the progress transparent.

Asynchrony’s First-Ever Internal Conference — Matt Philip’s blog

Among the many exciting things happening at Asynchrony this year, one of my favorites is our first-ever internal conference, coming July 15. I’m a big fan of organizations that take time to learn and share their learning. Especially given that Asynchrony is growing and establishing new offices, it’s vital that we share learning across offices […]

via Asynchrony’s First-Ever Internal Conference — Matt Philip’s blog