June 1-5, 2020
with Jim Benson
Zeigarnik Effect: once we begin a task, we can’t NOT be thinking about it.
“Individuals and interactions through processes and tools.”
Organize your options (your backlog) using the Cynefin framework (obvious, complex, complicated, or chaotic).
Chaotic: FIRE! Put it out, then analyze immediately
Obvious: delegate or automate as much as possible
Complex/Complicated: spend your attention here. Pair, mob, teach, and learn through the work
Anti-pattern: Rosy Retrospection. The longer you wait to retrospect on an problem, the more you will discount how bad it really was.
Add Retrospect and We Need To Talk columns after Done on your board.
Place items that you learned something from in Retrospect, to reflect on later and cement the lesson. This is periodic improvement.
Place drastic (chaotic/FIRE) items into We Need To Talk after Done. Don’t wait to retrospect on these, do it as soon as things are stable. This is continuous improvement.
with Richard Kasperowski
Ask yourself: “What is the best team you were ever on?” What was it about that team that made it great? Probably trust, safety, and fun.
We mostly ascribe these factors to luck. They just happened to put the right people together. It’s a roll of the dice. But These things can be fostered on purpose for any team!
Team Emotional Intelligence (TEI) ->
Psychological Safety (PS) ->
High-Performing Team (HPT)
Team Emotional Intelligence can be formed/enhanced through the use of the Core Protocols.
A High-Performing Team performs objectively better than other teams doing similar work. (It’s not intangible or subjective!)
It’s quickly becoming standard to measure (software) teams using the four key metrics from DevOps (deployment frequency, lead time, MTBF, and MTTR).
Aspects of HPT:
Respect for team members’ ideas unlocks the team’s genius.
Freedom is the basis of any great culture. HPT members have freedom. (This includes the freedom to not be on a HPT!)
Protocols: Pass/Unpass, Check out. A team member may opt out of any activity (pairing/mobbing, a protocol, a meeting). This is not to say that this won’t have consequences for them and the team, just that they are free to choose.
Try a Check-in as a “fourth question” in your next Daily Scrum.
Personal Alignment: “I want __.” This is way open-ended. If it stumps you, try narrowing the possible responses to a list of virtues:
Intention Check: “When you did/said __, what was your intention?” -> “I’m curious—will you tell me more about ___?”
It may make people uncomfortable to say, but an HPT is founded on LOVE. Connection is a big part of that.
The Decider protocol (thumbs up/down, flat hand).
In the case of a thumbs down, the voter can offer a suggestion that would get them to a thumbs-up.
The flat hand indicates that you trust the team’s collective judgement either way.
“A HPT navigates conflict.”
One of the protocols is a Protocol Check—error handling is baked in.
A team that uses the Core Protocols is continuously integrating their team, actively fostering the above qualities of HPT.
with Peter Green
VUCA (Volatile, Uncertain, Complex, Ambiguous)
We realize that things are not as they should be, and respond in two ways:
Both of which (ironically) lead to the same result. In order to actually move the system forward, Palmer asserts that we should instead Stand in the Gap.
The poorest performing ship turned things around when Marquet stopped giving orders. Instead, staff brought their ideas to him:
These map directly to Pink’s factors of motivation (Autonomy, Mastery, and Purpose, respectively).
Problems and work in a complex domain are dependent on context. We cannot simply copy processes/procedures from one complex domain and expect them to work in another. (See also Cargo Cult)
If we’re no longer giving orders, what do we need to trust the team to make the right decisions?
This forms the focus for the work of managers in an Agile organization:
Improve the System
As much as possible, let the teams themselves be responsible for things that don’t fall neatly under these headings.
The Three Jobs apply along both the Human and the Objective dimension. Examples of how work maps to these jobs and dimensions:
There is some overlap in this work with Scrum roles. A Product Owner will work to Create Clarity around their product, for instance. A Scrum Master would certainly be involved in Improving the System and Increasing Capability (especially on the Human dimension).
Managers should partner closely with PO/SM for Scrum Teams whose members report to them. For example, when Creating Clarity, the manager and PO may collaborate on setting the team’s Purpose, Mission, and Vision, while the PO would take on Strategy, Customer Segmentation, and managing the Product Backlog on their own.
You can still use the Three Jobs to own the work you do have a say in, while working to expand your influence.
Q: How does this work with SaFE?
A: “I have yet to see it work” for the Complex domain, it seems better suited for Complicated work (“I don’t know this, but we have an expert who does”).
Q: Where’s the line between the work of a Scrum Master and a Manager?
A: It depends on the team’s capabilities.
Managers progress from Expert to Achiever to Catalyst. (Does this line up with ShuHaRi?)
with Howard Sublett
with Richard Cheng
A good Scrum Master is always on the verge of getting fired.
(This is likely because a good Scrum Master has to be able to be direct and have difficult conversations with managers and leaders.)
Is it a full-time job? Yes.
Should a Scrum Master work across multiple teams? No. (Remember that Focus is a Scrum value)
Scrum Master, Product Owner, and Development Team member are three different skillsets/mindsets.
Can a Product Owner become a good Scrum Master? Yes, but only once they have unlearned the Command and Control mindset and embraced Servant Leadership.
Or, are they improving?
On The Agile Coach/Scrum Master relationship: In general, an Agile Coach should coach Scrum Masters on their work with teams, and partner with them on organizational issues. It is not recommended for Scrum Masters to report to an Agile Coach.
On Scrum Mastering while remote: Using the right tool(s) have become much more important in remote work—keep it simple, though. Also, create and maintain good Working Agreements.
On breaking into the Scrum Master scene: jump onto a team and get started!
The Scrum Master doesn’t stop their team from failing. Rather, they ensure that the team learns from their failures.
with Chris Li
A team is a small number of people (<10) with:
By promising to hold ourselves accountable to the team’s goals, we each earn the right to express our own views about all aspects of the team’s effort and to have our views receive a fair and constructive hearing.
Without Trust, team members cannot have transparency and the effective communication that comes along with it.
(Not “trust” as in, “I trust you to get this done” or “I trust you to do a good job”. If you trust someone, you can be vulnerable and open with them.)
Without Conflict (AKA Creative Tension), there can be no unfiltered passionate debate. Without Conflict, people’s best ideas are not available to the team.
Without Commitment, the team will delay making decisions and taking action.
Without Accountability, resentment will grow within the team, and their leader/manager will become overburdened with babysitting duties.
A team succeeds and fails together.
“I got my stories done” == “The hole is on your side of the boat”
Imagine bringing a new person onto your team. If that person asked you about your team’s purpose (or workflow, or performance goals, etc.), how would you answer? How would your teammates answer? Do this thought experiment before you actually have a new team member to onboard.
“Human APIs” between teams
When someone behaves badly, and their colleagues say “oh, that’s just how they are”, that’s a smell.
with Diana Larsen
Bob Martin has shown how programming has advanced over decades thanks to increasingly stricter limits in programming languages. Structured programming, OOP, and FP each introduced constraints that allowed programmers to focus on adding capability rather than on mitigating errors.
Larsen’s premise here is that the same principle, that constraints enhance capability, applies to your team’s agility as well.
Did you know? The term “Knowledge Work” was coined by Peter Drucker.
Fluency = unconscious competence.
The skill/attribute comes naturally, rather than as the result of applied effort. This is the result of consistent practice!
Pre-agile: Command and control, work (as tasks) is assigned to workers by managers. Decisions come from the top-down.
Focusing: The team thinks and plans in terms of the benefits their sponsors, customers, and users will see from their software. Scrum, non-technical XP
Delivering: The team can release their latest work, at minimal risk and cost, whenever the business desires. DevOps, CI/CD, XP, Kanban
Optimizing: The team understands what their market wants, what your business needs, and how to meet those needs.
One of the biggest challenges in enabling Optimizing fluency is giving the team true control over its product direction. The distinction between an Optimizing team and a Delivering team is that, within the constraints of its charter, the Optimizing team makes its own decisions about what to fund and where to focus their efforts. Managers need to delegate this power to teams, which is often a difficult change for organizations.
This stage is particularly disruptive to traditional organizations. It often requires reorganization and the political will to make it happen. Titles, promotional paths, etc. get shaken up.
Leaders tend to like it; middle managers tend to fear it.
Strengthening: The team understands its role in the larger organizational system and actively works to make that system more successful. The future of agile. (Sometimes marked by cutting-edge techniques like Team Self-selection and Open Space strategy meetings)
…are all limited in an Agile environment.
LIMIT your organization’s focus to improving one of these zones at a time.
Think of each new limit as a tradeoff.
“We’re giving up __ for __.”
When you argue with reality, you lose, but only 100% of the time.
Understand the organization’s reality and its limitations when choosing the level of fluency to target.
Don’t impose change from the outside. By involving people in the creation of an improvement plan, you create buy-in and motivation to carry it through.
Simple / Obvious: Problems are easy to solve and have one best solution. You can categorise and say, “Oh, it’s one of those problems.”
Complicated: Often made up of parts which add together predictably. Requires expertise to solve. You can analyse this problem if you have the expertise.
Complex: Properties emerge as a result of the interactions of the parts. Cause and effect are only correlated in retrospect. Problems must be approached by experiment, or probe. Both outcomes and practices emerge.
Chaos: Resolves itself quickly, and not always in your favour. Often disastrous and to be avoided, but can also be entered deliberately (a shallow dive into chaos) to help generate innovation. Problems need someone to act quickly. Throwing constraints around the problem can help move it into complexity. Practices which come from this space are novel.
Disorder: We don’t know which domain dominates, so we behave according to our preferred domain (think PMs demanding predictability even when we’re doing something very new that we’ve never done before, or devs reinventing the wheel rather than getting an off-the-shelf library). Often leads to chaos when the domain resolves (I know least about this domain, but it’s way more important than I originally thought it was!)
(Can we use this to refine a product backlog?)
with Paul Tevis
If you want to understand an organization’s leadership, strategy, and culture, sit in on their meetings.
A meeting’s purpose should be a verb phrase (eg, “generate ideas for…”, “share perspectives on…”, “scaffold the code for…”).
Repeat the purpose early and often throughout the meeting.
Share it in a slide or other visual.
Put it in the chat.
(In general, use the meetings’ chat as a narration of the meeting.)
Work outcomes: decisions, lists, etc. Human outcomes: awareness, understanding, persuasion, buy-in, etc.
Match the meeting’s structure and engagement to its purpose!
For example, idea generation should probably involve some silent brainwriting (and probably shouldn’t look like a mob programming session).
And a decision-making meeting would
Make the meeting’s structure and engagement obvious.
Anyone in the room should be able to stop the meeting (or prevent it from starting) if they do not understand its purpose or how they should participate.
Upgrade: Provide material that explains these clearly (not just verbally).
Design for the engagement that you need.
Use Google Slides (or PowerPoint) interactively! Have some slides that participants can write on/add their ideas.
Watch for resistance from complicated setup or tools
Question your favorite tools—are they the right fit for the meeting?
Use a non-technical solution if you can (eg, showing a fist-of-five rather than using a polling app)
Take this seriously—people’s attention is fragile and expensive.
For every hour of meeting, and average of 15 minutes of breaktime. (10 minutes for in-person meetings—Zoom fatigue is real!)
No break should be shorter than 10 minutes.
Use a visible timer.
Restart firmly on time.
Upgrade your breaks:
Check in on attendees’ energy levels often, maybe using a poll to eliminate social pressure.
Senior leaders sometimes hijack meetings. It’s going to happen. Try to get some intel ahead of time on who is likely to do this, and learn about their goals. Try to get their buy-in, so they don’t hijack.
Facilitation is done from a posture of invitation, not control. Improv skills come in very handy here.
To make chat-based input more safe, have people
If anonymity is important, have them set their Zoom name to blank before using chat.
Find out what is making the group unsafe, and remove it. Have leaders give their input last. Don’t make it too safe, though—feeling some vulnerability when meeting is a creative sweet spot.
If someone is distracted during the meeting (looking at their phone, typing, etc.), invite them to leave as needed. No one should be captive to a meeting when their attention needs to be elsewhere.
(from a leader/authority): “How do you know __ works?”
(the Aikido move): “Tell me more about your experience with __.”
Expect to spend about 2x of the meeting time to prepare for it (if it’s not a meeting you’ve held before).
with Lyssa Adkins
with Kim Brainard
Many organizations say they value “innovation”, but their culture breeds anything but. (Fear of rejection, lack of ownership, etc.)
What suffers more breakdown in your organization?
Try the next right thing. Don’t worry about whether people like it (or whether they like you).
(also known as the Satir Change Curve and the “Project Valley of Death”)
Agile is a mindset, not a methodology.
There is no repeatable method for learning and discovering.
Don’t just think outside the box—step outside the box.
When pressures increase, honest communication stops.
Leaders and staff must spend time learning together.
If there are no relationships, there is no culture.