Wednesday, February 28, 2018
Tuesday, February 13, 2018
Monday, February 12, 2018
Friday, February 9, 2018
Session Name: Product Owner and Manager, How to lead people not manger them
--
Edward Praudins
Through downward delegation can you form leadership skills and technics in people to help develop themselves naturally. How you sell this method to upper management is to continuously get agreement to have employees assume more manager roles. Show them the need to delegate and show them the quantifiable results they can produce. Therefor allowing you as the manager to focus less on projects, and process improvements and more on being a career engineer.
If anyone has additional questions please reach out and I am more than happy to put a call together to share more concepts.
Thank you,
Manager | Services Engineering & Development
Information Technology | Costco Wholesale
W: 425-416-2387
Let's Get Physical - Day 2 @ 8am
Informal discussion about how the space where the team works affects how they work, and the quality of interactions they have.
Some questions we considered:
Some questions we considered:
- What makes for a good workspace?
- What makes for a bad workspace?
- How does the workspace affect interactions?
- What have you done to create a better space?
References:
Work Environment Redesign- Deloitte
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).
Thursday, February 8, 2018
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:
- Movement trumps ____________
- ____________ trumps Listening
- Images trump ____________
- ____________ trumps Reading
- Shorter trumps ____________
- ____________ 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
Victor Bonacci
servant leadership: PATH podcastcards available at: agilecoachingcards.com
Wednesday, February 7, 2018
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:
- Start with a provided requirement (whether it is expressed in requirement-speak: shall, should, shall not, etc., or in user story form)
- 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
- Allow the requirement giver to clarify by straightening out the scenario/feature
- 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
Practices to Cultivate Presence - AONW session Tues 8:00am
What is busy about our job?
- managing people
- dealing with fires
- expectations
- herding cats
- overlapping priorities
- navigating conflict
What role do you have?
- developer / dev lead
- scrum master
- coach
- psychology practitioner
Why do we need to be present?
- to be authentic
- to attend to the needs of the group
- to help them "see the system"
- to maintain emotional balance
The parable about the sensei and the teacup: the student can not accept more tea until they first empty their cup.
Levels 1, 2 and 3 listening
Theory U
Practices
- Meditation:
- Do you use apps?
- guided: Headspace, podcasts
- timers
- time to meditate:
- morning & evening at home
- at work: find a time during the day (~10 minutes)
- start a meditation group at work, sync with Slack etc.
- Physical Activity
- walking / jogging
- biking to work
- yoga
Judith Blackstone (former dancer) has a useful practice model (?) - interview on podcast
Start the day with a Check In
Start the day with a Check In
- We ran a check in during this session (glad/sad/mad/afraid)
- Overview of the Core Protocol: Check In agilecoffee.com/ Inside Out (movie) and the Check-In core protocol
- includes overview of Plutchik's Wheel of Emotions
Emotional Intelligence is improved within the groups who practice.
See also Google's Project Aristotle for the value of Mindfulness on the job
- "I'm not good at this"
- the point of meditation isn't to have no thoughts, it's to notice when thoughts exist
- "This (meditation) is something that we normally don't do"
- there may be other activities that you currently do that also weren't "normal" when introduced
Open Space is a Mindfulness practice. It focuses the attention of the hive mind to a singular point
Invisibilia podcast (NPR)
The Language of Emotions (book) by Karla McCleran
The Mindful Coach (book) by Doug Silsbee
Agile Games Session
Hello there:
I had the pleasure to facilitate this session:
1st Part: We created a list of games we've used
2nd We described the game, and a lot included different versions we used and explained why, did the team learn the principle? Were they able to take that back to their work?
The interesting part was learning what folks had done to modify classic games like "Hats and Boats", to change the purpose or conversation.
Thanks for everything
Multi Month (more than a sprint) Retrospective Technique
Way to scale time, scope, participants, techniques for a retrospective.
All of these ideas (not sure about circle of influence) are in Diana's and Esther's book: https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649/ref=nodl_
Looking forward to hearing how your retrospective goes🙂
Cheers!
Valerie Morris
Subscribe to:
Posts (Atom)