Thursday, February 14, 2019

Leadership Agility for Agile/Lean Sustainability - Caleb Arnold

Thank you to everyone who attended, very engaging and informative conversations.

What types of problems or stories does the group have about leadership not understanding how to support Agile/Lean teams?

Group think on what teams/organizations need from leadership to support Agile/Lean teams.


Often leadership or even teams will not embrace the values and principles of Agile/Lean and expect the practices to give the organization the benefits.

Building trust in your team

 

Tuesday, February 12, 2019

Beyond Retrospectives: A Practice Pattern for Continuous Improvement (1 of 2)

Beyond Retrospectives: A practice Pattern for Continuous Improvement (1 of 2)
Agile Open Northwest 2019
Adam Light @KnowledgeLean  #BeyondRetrospectives


Agenda


Why does improvement form retrospectives plateau?


What would a better continuous improvement process look like?



Beyond Retrospectives: A Practice Pattern for Continuous Improvement (2 of 2)

Beyond Retrospectives: A practice Pattern for Continuous Improvement (2 of 2)
Agile Open Northwest 2019
Adam Light @KnowledgeLean  #BeyondRetrospectives

Improvement Kata Pattern



Goal Components


Comparing and Combining Improvement Methods


Coaching Guard Rails

A Crash Course in Design Thinking

A Crash Course in Design Thinking
Jenn Henry & Adam Light @KnowledgeLean
Agile Open Northwest 2019




Use Experiments to Get Better at What You Do: A Hands On Simulation

Use Experiments to Get Better at What You Do: A Hands On Simulation
Agile Open Northwest 2019
Adam Light @KnowledgeLean #BeyondRetrospectives #ToyotaKata

  







Agile Discovery: Involving the Team with the Customer and the Business

Agile Discovery: Involving the Team with the Customer and the Business
Agile Open Northwest 2019
Adam Light @KnowledgeLean


5-Question Quiz: Why do we need this?

Agenda
  
Discussion Topics +  how they relate


Managing Up by Setting Better Goals


Managing up by Setting Better Goals\

Adam Light
@KnowledgeLean

What are the sources of goals from outside the team?


Assess likelihood and impact...then identify which items we want to move up, right, or left.


Discussion example based on expected need for scenario planning to make difficult decisions

Monday, February 11, 2019

Notes from AONW 2019 "Cultivating Attention" session, Wednesday 2/6 11:30 am

We looked at four challenges to effectiveness that teams face and how cultivating the skill of paying attention can help overcome those challenges. These all have their source in the normal functioning of the human brain:
  • Distraction (caused by inherent busy-ness of the brain) requires stable attention so teams can focus on what's important.
  • Silos and factions (caused by the inherent tribalism of the brain) requires connectedness so teams can collaborate effectively.
  • Jumping to conclusions and making assumptions (caused by the inherent bias of the brain) requires open-mindedness so teams can make good decisions.
  • The fight/flight/freeze response (caused by the inherent reactivity of the brain) requires self-awareness so teams can find resilience in the face of change.
Teams can find their way to these qualities over time (one participant described a team that developed them by working together for seven years). I provided a brief overview of ways from my book, Cultivating Attention, to get to better attention more rapidly using specific techniques for developing present-moment, non-judgmental awareness.  Examples include watching your breath, noticing your team members with curiosity and openness, reflecting on the operation of bias in your thinking, and being aware of how the body sensations of reactivity influence cognition. These practices can all be done by individuals: but the real key is to find ways to provide flexibility and individual autonomy so they can be embraced by whole teams of diverse people with varying priorities and preferences. We agreed that this team-level implementation needs to be:
- Facilitated by an outside person who is not enmeshed in the dynamics of the team.
-  Highly customized to the context of the team: its culture, personalities, business and technical environment, and leadership.

--
Joseph H Anderson Consulting, LLC
(206) 351-5607

Cultivating Attention: the Paradoxical Secret to Team Success now available from Amazon. Learn more.

Notes from AONW 2019 "Courage and Safety" session, Thursday 2/7 at 1pm

This session explored the following questions:
1. What courage can we expect from each other?
2. Since no environment is 100% safe, what is the responsibility of the environment and those who create it? What is the responsibility of the individual?
3. What are practices teams can use to promote risk-taking and the vulnerability that goes with it?
Here are notes on highlights from the discussion:
- "Courage" as a term to describe an expectation of team members is problematic. 
In some environments (e.g. the military) it might work perfectly well, but when there are differentials in power/privilege then "be courageous" creates pressure and decreases the overall psych safety of the environment. 
The opposite of "courage" may be "cowardice" so there's a heavy moral judgement that goes with it.
"Courage" has different meanings for different people: not being afraid, being afraid but acting anyway. It would be challenging and perhaps not useful to shift those definitions.
- A more useful approach is to find better language to communicate the expectation of "courage". "You must have courage" is different from "you must share/speak up." "Do not be afraid to fail" may be more useful than "be courageous." Another way to reposition "courage" is as "a willingness to make mistakes."
Practices around how making the environment more conducive to vulnerability or risk-taking. 
- It's powerful for leaders to model vulnerable and risk-taking behavior.
- The "ouch/oops" technique: when someone feels hurt/attacked in a meeting by something another team member says, they can say "ouch". The person who spoke then says "oops" to acknowledge that they recognize the impact of their words.
- The "how fascinating" technique. When someone in a meeting makes a mistake, the others raise their hands and exclaim "how fascinating!". The followup question for the person who made the mistake is "what did you learn?"
- Approach defects in the spirit of "That's a great bug! Now we can learn more about it and what caused it."
- Etsy has a "three-armed sweater" award for the biggest engineering mistake of the year: it's an opportunity for learning and celebration.
- What makes mistakes scary is the risk of being expelled from the tribe. This is baggage from our evolutionary past.  In a collaborative tech environment mistakes actually put the tribe at less risk by revealing collective weaknesses that need to be addressed. It's a shift from "any mistake puts the tribe at risk" to "your mistake makes the tribe better in the future."


Joseph H Anderson Consulting, LLC
(206) 351-5607

Cultivating Attention: the Paradoxical Secret to Team Success now available from Amazon. Learn more.

Fostering, Inspiring and Empowering Innovation (pics)


Sunday, February 10, 2019

Motivation: How to Help People Care, by Michael Caloz


How to Prioritize the Backlog, by Michael Caloz



Restoring Safety and Re-establishing Trust

Session took place Day 1, 10 am

Discussion Notes:

-Psychological Safety survey as a team activity- results could be shared in a session facilitated by scrum master or engineering manager
-Who establishes safety?
-Conflict is healthy
-Power dynamics can get in the way of the real problem
-Data-driven health checks- Atlassian, Spotify
-Listening protocol, what triggers people, create empathy
-Resources- Google Project Aristotle, Radical Candor

Thanks,
Colleen

Mobs in the real world

Discussion prompt:

Mob programming is a fantastic tool, and having mobbed for two years on a software engineering team I have great buy in for its effectiveness in serving the needs of a company. However, myself and colleagues have continued to struggle with individual recognition, in particular how our companies recognize the various types of work that happens in a mob, and the work it takes to maintain a healthy mob.


To begin, we used the lense of "who benefits and who is burdened?" to discuss the merits of mob programming.


Who benefits?

  • Early engineers benefit from a quick feedback loop as they start learning; if they have questions, it is not long until they are addressed and answered.

  • Engineers looking to learn a language or stack in order to effectively support a service; and vice versa, whoever is teaching benefits from sharing their knowledge and breaking down a knowledge silo.

  • Support team, QA, Product Owners, Managers who participate (or at least co-work) with a mob are more engaged in the software development process, and they experience a quick feedback loop for changes.

  • The company; this came up over and over again, the company benefits when engineers work in a mob.


Who is burdened?

  • Senior engineers can feel the limitations of the structure and prescribed methods of mobbing.

  • Managers who are not embedded on the team have a great deal of work to do to understand individual contributions.

  • Early engineers who find themselves overwhelmed, but unable to self-advocate effectively.

  • Mob organizers; this can be anyone in the mob who tends to spend more time facilitating retros and hard conversations, coordinating work to be done or communicating with stakeholders. This is especially concerning if an early career engineer, or underrepresented voice is taking this work on as it is extremely challenging to get recognition.


What are ways to lessen the burdens listed above?

  • As a colleague, make specific call outs of the work your peers do that contributes to the health of the mobbing team.

  • Support early engineers by providing a single go-to mentor, or on-boarding buddy, who will help contextualize work being done, fill in knowledge gaps, and help the mob adapt to their needs.

  • Call out roles that you see being played that are not traditional driver/navigator mob roles. Maybe you see a starter - who can motivate everyone to get started each day and while it just may be minutes each day, over time it has a big impact. In pointing out a new role, you can then ask: "Is this role valuable to the team?" and let the conversation lead you to recognition, and sharing of the role.

  • Recognize the management hierarchy. Successful mob teams self-organize, and self-critique, which is a flat structure that often reports to a hierarchical management structure. We tracked that this difference in structure may be an impacting factor when trying to track and understand the impact of individual contributions.

  • Performance reviews: Have a very clear understanding of who is conducting reviews, and to what end. Reviews often identify strengths, and weaknesses. In a healthy mob, there is a near continuous feedback loop for what is working, and what is not, but it is important that this conversation is also had between the individual and the company they work in.

  • The example of a manager who embeds with the team (a player/coach). We heard a great example of a manager mobbing with the team, with the intention to help each individual grow. They have to keep a dual focus, on the work being done, and individuals needs, but the general sense was a manager in this role is particularly empowered to put individuals needs and recognition first. (A concern we didn't address is whether a manager in a mob limits individuals from taking on more responsibility).

  • Because a mob is so focused on work, individuals themselves may find it hard to recognize and explore their own interests and needs. Maintaining regular 1-1s seemed like an option to give time and space to reflect on individual needs.

  • Being an expert in a mob can be a burden. Technical experts may be the most aware when colleagues are not grasping a subject and work needs to slow down. Organization experts may be most aware when interpersonal issues are causing friction that endangers work in progress. We collectively called out that this burden is ok to be carried by senior engineers, but that it should be carefully called out and assessed if non-senior engineers take on either of these roles consistently.

  • Mob teams tend to manage up. Managing up is a huge help for manager to put into perspective subtle differences in assessing individual performance in a mob. If a manager is used to reviewing code contributions on github for example, the mob members have to explain that this data doesn't characterize the work being done, and offer alternatives. Remember, that if you manage up for yourself, it likely applies to the rest of your team as well.

  • Mob teams need their management hierarchy to opt in to a different set of evaluation practices on the technical, organizational, mentorship, and self-determination practices that individuals cultivate. Without reinforcement of mob best practices, mob members can lose their motivation to continue doing critical work that has turned burdensome.

  • Mobs need to also allow time for deep thought to grasp complex subjects.

  • Early engineers are easily overwhelmed, and least likely to speak up

    • If diving into a difficult domain, this can compound the effect

    • The pace of a mob can be difficult for one person to influence

    • There is persistent peer pressure to continue at the current pace

  • Mobs must continually improve through experimentation; the grown mindset is incredibly important and a mob that doesn't change proces often may be experiencing problems they are unaware of.

  • Carefully consider the neurodiversity of a team. Individuals focus needs are different, and if the common denominator isn't working for an individual, flexibility is required.

  • Allow team members to opt in and opt out of the mob with fluidity. This can be on a day by day, and hour by hour basis, but most importantly, if a mob is not accommodating an individuals needs then allow flexibility.