There are three styles to cover three specific project coaching circumstances.
These project coaching styles are based upon the experience of the team you coach. You will coach
inexperienced teams, teams with some experience and some very experienced teams.
We will address these three coaching opportunities in the next paragraphs. For now, however, we want to concern ourselves with the expertise of the
team and how this influences the coaching events we will perform and the coaching style we will select.
The coaching events are delivered to individuals and
to teams as a group. So there is a doubling of these possible events when you consider the two possible audiences.
There is, as yet, no definite model to agree how to practically and accurately define an exact representation of each of the
three types of group or to clarify exactly where the boundary is and the switch from one group to another occurs. So,
this can be a difficult circumstance
to identify accurately.
However, we offer a mechanism to establish how you can seek to identify this and introduce the technique of Agile Project Experience measurement or
APEx measurement. This is an attempt at a pragmatic measurement of the agile expertise within a team that can be defined empirically. However, as with
many attempts to define human contribution it is often reliant on subjective assessment as well as measurement. But a measurement it seeks to be,
Agile Project Experience Measures (APEx)
In APEx measurement you wish to uncover what is the level of experience of the whole team. You do this by establishing the experience of the various
team members. This will determine which generic coaching style you apply to team coaching events and which project coaching style you adopt in the
circumstances where you are coaching that individual.
The first question you want to uncover is to determine how many successful and unsuccessful agile projects a person has worked
on. Out of interest immediately, we will take the persons experience on a successful and an unsuccessful agile project in the same light for the
purposes of the measurement. Positive experiences on a successful agile project are, of course, useful and powerful influences for your project.
Positive experiences on an unsuccessful agile project can be significant learning experiences for the individual and just as useful to your project,
which is why we treat them in the same way.
You may, however, wish to discount the involvement of an individual on an unsuccessful agile project if you feel the experience or their contribution
was not productive or if you feel it did not help to advance the agile experiences and expertise of the individual. You achieve this, of course, via
swift interviews and remember, you will not get this assessment perfect first time. But, because the objective of performing APEx measurement is to
uncover an assessment of the overall expertise of the whole project team, a mistake on one less experienced individual will have a small effect on the
Let us look at the calculation method for APEx measurement. First, we take the number of agile projects and use this to determine the individual agile
expertise. We then assess the number of agile projects and assign an experience sector to the individual. We total the number of personnel in each
experience sector and perform a simple calculation based on experience weightings we have developed. This produces a total for the whole team.
It is safe to say that, as you run more and more agile projects within your organisation, you will seek to adjust these experience weightings with
greater and greater success in the calculation of your APEx measurement. For now, let us look at an example.
Agile Project Experience Measurement Example
Let us take an example of a project team. Let us say that there are 11 people on the project team.
Six of these people, just under half of your project team, have never worked on an agile project before. The rest have some experience, some
more than others.
As we said earlier, there are three experience sectors. These are inexperienced teams, teams with some experience and some very experienced
teams. To derive the team experience we look at the relative experiences of the individuals. Their experience is simply identified in sectors
to denote low, medium or high experience.
Experience is established based on the number of agile projects they have worked on before. This is done regardless of whether that agile project was
successful or unsuccessful or whether the agile project took place inside or outside your organisation.
Naturally you can enhance the metrics by adding further
weighting if you feel it is more beneficial to your project if the individuals experience was derived from projects within your organisation. It would
make some sense, certainly. However, we are not seeking to present the perfect model for this and offer it as a basis for localization and improvements
that are pertinent to your project environment and landscape.
So, we revert back to the assessment process to determine agile experience levels.
If an individual has never worked on an agile project before they are classed as low experience.
If an individual has worked on one, two or three agile projects they are classed as medium experience.
If an individual has worked on just one agile project before, in our experience, you have a subjective decision to make. If it was, in your view,
a positive encounter with agile techniques and process then they are classed as medium experience. If however you feel the encounter was not a positive
one or the project was not really agile, then you are better to assign this as ostensibly nil experience.
Without question, if an individual has worked on three or more agile projects then they are classed as high experience individuals.
We have found that a team that exhibits a team quotient
of 2.5 or less has an unacceptable level of agile expertise, is unlikely to
operate as a high-performance team and this lack of agile expertise
introduces a serious risk to the successful delivery of the project.
This level of risk contravenes the resources Commitment of the project
and demands immediate repair via the Project Disengagement method. More information about the project Commitments and the Project Disengagement
method are provided elsewhere in The Big Agile Toolkit.
So we will place six people in the low agile experience sector.
Now, we will look at the other five project personnel.
We examine how many agile projects they have worked on before.
In this instance, we have three people who are classed as medium experience and two individuals with high experience.
Now we apply the agile experience weightings.
For low experience individuals, we apply a weighting of one.
For medium experience individuals, we apply a weighting of 10.
For high experience individuals, these are the people who provide the most transformational opportunities for your
project and, to represent this extra impetus, we apply a weighting of 20.
Now we perform the simple calculation.
We multiply the number of people in each experience sector by the agile experience weighting.
This provides us an agile experience quotient for each agile experience sector.
In our example, we have six people in the low experience sector.
The low experience weighting is one and so our agile experience quotient for the low experience sector is the
We have three people in the medium experience sector.
The medium experience weighting is 10 and so our agile experience quotient for the medium experience
sector is the number 30.
Finally, we have two people in the high experience sector.
The high experience weighting is 20 and so our agile experience quotient for the high experience
sector is the number 40.
So now, we have three experience quotients.
There is one for each experience sector.
The three experience quotients seek to represent the level of positive
influence that the people within these sectors will provide to the project.
So you can see, we have assigned an experience quotient of 6 to represent
the positive influence that six inexperienced people will bring to the
Furthermore, you can see, that those people on our project with medium
experience will bring five times that benefit to the project.
Finally, you can see, that those people on the project with high levels of
agile experience will bring around seven times the benefit received from
Taking into consideration our past experiences on projects,
it is the experience quotient and its magnitude in comparison to the other
quotients of the other experience sectors that is the important indicator
of the total agile expertise of the project. Whether this represents the likelihood of an agile team
working together efficiently will take a little more work and research. For
now we have a set of three numbers that tell us how one sector influences the project and how much more influential it is vis-Ã -vis other sectors.
Let us look at less favourable project expertise profiles to attempt to explain this circumstance a little further.
If we imagine a scenario where your project still has 11 people.
However, imagine that we have lost three of the more experienced personnel
and these have been replaced with people who have no agile experience
We can see, our experience quotient for the low experience sector has
increased. It is increased from 6 to 9. Our new project personnel profile
gives us medium and high experience sector quotients of 10 and 20 respectively.
The numbers from sector to sector are increasing. They are going up. This looks good.
However, as we said earlier, the trick is to compare quotients across the whole profile.
Here, we can see, the medium quotient is barely higher than the low quotient.
The high quotient, our indicator of how influential our experience people will be,
is only twice that of the low quotient.
In reality, this means, the two experienced people will be spending
most of their time coaching the nine inexperienced people. This looks more like
an agile training course than a project. At the same time as performing
the coaching, the two most experienced people still have to drive forward
an agile project. This is a risk laden experience profile and would welcome some outside support in the form of agile coaching and management.
Now let us look at a more risky profile.
In this instance, our project team has no individual who has worked on
3 agile projects are more. Our most experienced team member is someone who
may have worked on only one agile project beforehand. This may even have been
a project outside this organisation.
This one most experienced team member has 10 complete novices to coach,
as well as drive forward an important agile project.
There is an experience quotient of nil in the high experience sector.
And the experience quotients of the low and medium sectors are equal. Furthermore,
they are very low quotients too. With even the very best will
and willing effort from each of the 11 individuals, this is never going to be
a high-performance agile team.
As we see from the diagrams, for each APEx measurement we derived a quotient for the team.
Teams themselves can exhibit their own combined expertise.
Experience shows that agile teams exhibit a low, medium or high
level of expertise and this expertise can be represented by a team quotient.
This is simply derived by dividing the total experience quotient of the whole team
by the number of people in the team.
Experience shows that the relative expertise of the whole agile team can be
established by comparing the team quotient against two team experience thresholds.
We also find that a team that exhibits a team quotient
of 4.5 or more has an acceptable level of agile expertise and is likely to
operate as a high-performance team. The successful delivery of the project is, of course, dependent upon a number of influences.
However, the expertise of the team is not adding any risk to that successful outcome.
Finally, we have found that a project with a team quotient less than 3.5
introduces a serious risk to the successful delivery of the project. This level of risk also contravenes the resources Commitment of the project
and should be enacted immediate repair via the Project Disengagement method.
A project with a team quotient between 3.5 and 4.4 introduces a low risk to the successful delivery of the project. This level of risk does not
contravene the resources Commitment of the project
but you should recommend a high experience individual to be assigned to the team. If this is not possible for all the project then they
should be assigned for a specific period of time to support and coach the team during its most crucial stages. We will look at those stages now
and start to uncover the styles you will adopt to cover these coaching stages.
If you have responsibility for agile coaching, naturally as a coach, you will take a more guiding and less dictatorial stance. However, the distance
you maintain from a project cannot be too great or you risk loosing track of the project, its issues, people and progress.
To minimize this, regularly attend and monitor activities at the most important project event: the Daily Forum. Try to observe how team members
interact whilst identifying all those project team individuals who do not contribute. All projects need supportive troops and motivated individuals. It
is the job of the coach to help uncover these circumstances.
This is an important responsibility for a coach and there are different ways to deliver your project coaching solutions. In the Toolkit, we introduce
three coaching approaches and we discuss these in a little more detail so you can tailor the delivery of your agile coaching services. First we
look at the Inexperienced teams and the approach to coaching them.