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 the Paris Method  Coaching the Paris Method   Agile Project Experience Measurement APEx   Agile Project Experience Measurement APEx

Manage   »   Coaching   »   Coaching Events and Styles

So, at this point, you have your team. They are hand picked by, or flown in for, you and your project. Some will bring optimal qualities to the team and most will need some form of additional skill to be able to run at ideal performance for your project. This can be done in formal training scenarios or can be provided to your project personnel by coaching and by your day on day encouragement and guidance on the project.

Many of the skills will be learned and enforced on the project itself. This is why it is always best if you can identify personnel who have worked on such projects before and can start to demonstrate and permeate the underlying agile behaviours swiftly. But this is a goal that is not always easy to achieve. Daily, you will gauge the expertise and needs of your project team. This will guide the style you or your coach will adopt when called upon to intervene and provide coaching services. So Let us look at the project events you are likely to get involved with as a coach and specifically those events where we interact with and guide project team members.

These include improving the communications on the team. Time is a very scarce resource and this type of project uses time at a very low granular level. You run meetings tightly without long debate and without exploring every possible avenue or every perceivable outcome. You operate a Daily Forum which is time fixed and run closely and strictly to time. These are behaviours you can influence by coaching the team.

Gradually the team members will see the rest of the project and their peers seeking the swiftest conclusion to a session and that debate is not always the answer. Trial and assessment by expert and knowledgeable business partners is the deciding factor in acceptance. Our views are interesting indeed on such matters but they are not part of the project if they are counter to the advice and direction stated by the business assessment personnel.

Gradually the team members will learn that there is a difference in emphasis regards the measurement of quality on an agile project. Although this concept can be taught and communicated to the project personnel, it is a slow skill for experienced people to learn, convert to and embed. On projects before, their role involved them using their experience and guidance to assess and influence the design or behaviour of the output themselves. It also meant that they were to establish if this output was of a particular and acceptable quality before passing to the next stage. On an agile project, that demand is not present. The business personnel are the arbiters of quality. We are getting a little ahead of ourselves as this topic is dealt with elsewhere in the Toolkit. What it represents though is that some new skills are needed to be added to the individuals skillset but some are gradually becoming unnecessary for this type of project. The individuals skillset is expanding and changing.

Another skill you can successfully coach is, ensuring the team are operating in a non blame culture. You can send your people on a training course to tell them this fact but it is time wasted if, day on day, they see blame led behaviours, finger pointing or hear lots of told-you-so comments. Certainly, tell your team from the outset that your project will operate a non blame culture. But this needs to be enforced when the first mistake occurs on your project and there is a temptation to open an internal inquest. Try to avoid any of your people wasting time to uncover guilt, fault and culpability.

Without question, record such events as mistakes or error. But the important trick is to say that this particular error will not take place again, take the matter up in your Daily Forum. Explain what has happened, keep the description of the story open and without personalizing the actions involved. State the unsavoury outcomes which resulted and their effect, then give the responsibility back to the team to ensure the mistake cannot happen again.

That is it. Move on. Mistakes will take place again. Hopefully, with your guidance and coaching, they will not be repeat errors. They will be different ones. However, if the same mistake does keep occurring, then the resolution of the error has not worked. A coaching session will be required with those who are directly involved to uncover what events are taking place that appear to be unsolvable.

We coach all project team members; there are no teachers pets or favourites. These will include business people, business analysts, testers, development personnel, release managers, project managers and other coaches. You will likely coach trainers who provide training to the users of the final solution. You will likely coach your change board in how you need that function to operate. You will likely coach your methodology staff to see how the method can be embedded within the organisation and how an agile transformation can be established. Whatever way you coach, you will coach using your generic agile skills and knowledge of agile solution delivery as well as your expertise in coaching using The Big Agile Toolkit.

You will coach a project event or circumstance until you determine and agree with a project manager that an event requires no further coaching. These events include all the major events within the Toolkit. They are the Daily Forum, the Workshops for Risk, User Requirements, Setup Planning, Delivery and Release Planning as well as all activities throughout the Lifecycle stages of Define, Survey, Develop, Release and Run.

The style of coaching you adopt will be adjusted as you gauge the expertise and needs of your project team. So before we look at the coaching events you will perform and the styles you can adopt, let us first look at the expertise you have on your project and an assessment process to quantify it.


 Coaching the Paris Method     Coaching the Paris Method   Agile Project Experience Measurement APEx    Agile Project Experience Measurement APEx

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
Coaching Events and Styles


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
Topic: 48  Page: 63/444  Progress: 14.2%
 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 ( 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.