Save £12 Million every year > Save £3 Million every quarter   
The Big Agile Toolkit: no Dogma, no Bias, no Accreditation, no Exams & no Fees   
 Coaching Events and Styles  Coaching Events and Styles   Inexperienced Teams   Inexperienced Teams

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, nevertheless.



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 overall total.

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.



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 number six. 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 project. 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 inexperienced people.

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

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.

Buffer



 Coaching Events and Styles     Coaching Events and Styles   Inexperienced Teams    Inexperienced Teams



Glossary:     a  »   b  »   c  »   d  »   e  »   f  »   g  »   h  »   i  »   j  »   k  »   l  »   m  »   n  »   o  »   p  »   q  »   r  »   s  »   t  »   u  »   v  »   w  »   x  »   y  »   z


#personas  »   #artefacts  »   #archetypes  »   #patterns  »   #change  »   #personas  »   #increasingoutput  »   #reducingvariation  »   #improveefficiency  »   #abstraction  »   #predictionandcontrol  »   #management  »   #organisations  »   #socialnetworktheory  »   #failfast  »   #quality  »   #waste  »   #complexity  »   #learning  »   #adapt  »   #inspect  »   #improvement  »   #models  »   #complexadaptivesystems  »   #informationflow  »   #sytemsthinking  »   #butterflyeffect  »   #unpredictability  »   #chaos  »   #emergence  »   #emergentbehaviour  »   #distributedcontrol  »   #continuousimprovement  »   #complexityscience  »   #gametheory  »  
 Agile In 6 Steps    |    Projectivity    |    Instant Agile    |    Risks    |    Auditing Agile Projects 
Big Agile Toolkit Book (Amazon Japan)   |   Big Agile Toolkit Book (Barnes and Noble)
Buy the Big Agile Toolkit Book   |   Buy the Big Agile Toolkit Kindle eBook
Agile Project Experience Measurement APEx






   


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
   
Topic: 49  Page: 64/444  Progress: 14.4%
 About    |    Author 
Follow @BigAgileToolkit


This content can be copied to third parties for personal use if you acknowledge the source of the material with website URL (http://www.bigagiletoolkit.com/) and Twitter hashtag (#BigAgileToolkit).
In all other cases, no part of bigagiletoolkit or associated text or website may be copied reproduced or redistributed in any form or by any means without prior permission in writing from the author.
Agile Project Governance for Cost Conscious Companies™

All rights reserved.