Coaching Roadmap - The Journey

Coaching Roadmap - The Journey

Session hosted by:

Bryan Stallings Bryan LinkdedIn (bryan.m.stallings@yahoo.com) and Samantha Denning Samantha LinkedIn (samantha@fwdresolutions.com)

What we did:

• Reviewed some aspects of a ScrumMaster's role where coaching competency is vital

• Agreed that there is a considerable gap in the knowledge / experience / competency of a skilled agile coach over that of a newly minted ScrumMaster

• Discussed the lack of "one sure way" to develop one's capabilities in the competencies required of an effective ScrumMaster, Team Coach, Agile Coach, etc.

• Presented the Agile Coaching Competency Framework (see Agile Coaching Institute website for details) as a well-accepted model in the community for defining the competencies of the agile coach role.

• Walked through and around the model (see the photo) and participants were asked to reveal which competency was their strength, and which, should they strengthen it, could be of best use by their teams.

• Described the Co-Active Coaching program for developing professional coaching competencies

• Demonstrated professional coaching via a live demo

• Responded t0 participant questions

Takeaways:

• There gap in the knowledge / experience / competency between a skilled agile coach and a ScrumMaster with little experience.

• Most ScrumMasters and Agile Coaches rely primarily on a limited application of the mentoring competency. In other words, these individuals are merely telling others what to do.

• Mentoring is NOT the same as coaching, though one does use some coaching skills when mentoring effectively.

• The road to competency is a journey without "one sure way" to develop one's capabilities.

• The Agile Coaching Competency Framework (see Agile Coaching Institute website for details) offers a well-accepted model.

• Many individuals in these roles are applying the descriptor "coach" to themselves without any actual competency beyond that of an agile practitioner. Among those in the agile community refering to themselves as coaches, there is a need to increase awareness, expertise and competency.

• Among agile coaches, professional coaching is the least understood and applied competency, and therefore the area which presents the greatest opportunity for learning.

• Professional coach training either focuses on coaching an individual (for example, Coaches Training Institutes's Co-Active Coach training) or a system of individuals (for example, CRR Global's ORSC training).

Thank you to the fantastic people that joined us for the session!

The Six Trumps - AONW session Tues 2:00pm

The Six Trumps: Six Learning Principles that Trump Traditional Teaching
 

opening exercise:

• sum up the following ten numbers: 1  2  3  4  5  6  7  8  9  10
• how did YOU get the answer? Did you try multiple approaches?
• it's a metaphor for learning: people each have their own ways to learn
• the mind has evolved for pattern matching; every minute of every day

Think of a training you took.

• Was it effective? Why / why not? Have you applied anything that you'd learned?
• Do I want my audience to simply HEAR me speak, or do I want them to LEARN the content?
  

"If you are in education, you are in the business of brain development. If you are leading a modern corporation... you need to know how brains work." - John Medina, author of Brain Rules: 12 Principles for Surviving and Thriving at Work, Home, and School

Sharon Bowman's Six Trumps slides on her site at: bowperson.com/sharons-micro-courses

Fill in the blanks:

1. Movement trumps ____________
2. ____________ trumps Listening
3. Images trump ____________ 
4. ____________ trumps Reading
5. Shorter trumps ____________
   
6. ____________ trumps Same
   

Vic will be teaching the 2-day Training from the Back of the Room course:

• August 4 & 5, 2018 (before Agile2018) – San Diego, CA – REGISTER
• September 15 & 16, 2018 (after AOSoCal) – Irvine, CA – REGISTER

More info at TrainingFromTheBackOfCalifornia.com (TBRcal.com)

Victor Bonacci

coach, trainer, podcast host
linkedin.com/in/vbonacci
@AgileCoffee - AgileCoffee podcast

servant leadership: PATH podcast

Training from the Back of the Room classes: TBRcal.com

cards available at: agilecoachingcards.com

#NO - Jay Bazuzi - Wednesday 10am

Testing the Crap out of Requirements Using Black-hat BDD - Wednesday, February 7, 2018

It is no secret that problems with requirements have a significant impact on software projects, so why do we just accept them as law and steam ahead with development? What if there were a way to test them and make them better, before a single line of code is written and possibly wasted?

This session presents an approach to testing requirements using BDD, but with a twist. Typical BDD, which we will call White-hat BDD, aims to faithfully translate given requirements into scenarios and examples using the simple Gherkin specification language. There is some art required here, as typical requirements are expressed in the formal language of shall/shall not, etc., and rarely includes illustrative examples, but the goal is to match the intent of the provided requirement as closely as possible.

Black-hat BDD, on the other hand (which I just made up), aims to clearly and obviously subvert the intention of the provided specification while still following the letter of the law, so to speak. In this way, counter-scenarios and counter-examples provide evidence of weaknesses in the requirement. Instead of allowing these weaknesses to quietly lead to misinterpretation or to fester as awkward constraints or holes in the product, this approach points them out directly and dramatically, so that they can be immediately fixed. Think of it as breaking the integrity of the requirements by exploiting weaknesses, similar to the way that black-hat hackers take advantage of security holes in software.

This approach can be used to address requirements that are:

• Contradictory
  
• Impractical
  
• Incomplete
  
• Inconsistent
  
• Un-testable/Unquantifiable
  
• Vague
  

The general approach is as follows:

1. Start with a provided requirement (whether it is expressed in requirement-speak: shall, should, shall not, etc., or in user story form)
   
2. Come up with a Black-Hat BDD scenario/example that intentionally comes to 'bad' behavior/results but is consistent with the wording of the requirement
3. Allow the requirement giver to clarify by straightening out the scenario/feature
4. Back and forth until no more glaring holes are identified
   

The conversation between requirement tester and provider, where the requirement is successively refined and improved, is much more friendly than it might seem based on my choice of terms; it is not adversarial, but a cooperative effort to produce a better end product. It can even be a little fun.

One important warning -- don't let these counter-examples end up accidentally in the 'real' BDD suite. Find some way to clearly mark them as inappropriate. One way is to use unique keywords, like 'Counter-Scenario' and 'Counter-Examples' that are not legal Gherkin, or to put the word "Nefarious" in the title.

For our session we practiced with examples from a made-up project, which was centered around the idea of tracking, predicting and coordinating brain waves/states for users so that they can target either single or shared experiences in an optimal state. The canonical example would be a group of users that want to simultaneously achieve a highly creative or productive 'flow' state, like for a collaborative work session.

Here are the flip-charts from our lively discussion:

Thanks, everyone!

-- David Snook

Pictures from a few sessions

https://photos.app.goo.gl/vltnED9Mg0RoCRMR2

Only at Agile conference ;)

Playing the ScrumMaster of ScrumMasters Role - Monday, February 5, 2018; Adam Light