March 31st, 2021
with Tricia Broderick
Cooperation: “I’ll help, as long as my work still gets done.”
Collaboration: “This is our work.”
Conflict is necessary for a team’s wisdom to emerge.
Don’t try to remove conflict from work, try to remove drama from conflict.
Rescuer creates Victim creates Persecutor.
Resolve drama by shifting the roles:
Rescuer to Coach.
Victim to Creator.
Persecutor to Challenger.
And reveal the problem in the system.
Think Again by Adam Grant
with Dave Prior
The Product Goal is part of the Product Backlog. But it also describes the Product Backlog. How can you have something that describes the thing that it’s also a part of?
Vision is no longer mentioned in the Scrum Guide. Does Product Goal replace Vision? No.
The Product Goal makes it easier to find a Sprint Goal: “what is something we can do in two weeks that moves us toward our Product Goal?”
The Product Goal is a velvet rope that keeps the riffraff out. (Although, people lined up outside the club are still eventually a concern of the club owners.)
If you do identify multiple Product Goals at a time, should you have a backlog of Product Goals while focusing on one at a time? Lean thinkers would say no to this–focus on one, throw the rest away. They’ll either become obsolete while working on the first one, or they’ll come back up because they are still important.
Meaning, don’t look to it for all the answers. It’s not desgined to be changed, but it is designed to be added to. The best way to do this will emerge for your organization.
Before the goal to focus it, the Product Backlog was the container for everything–all of the ideas for the future of the product. In practical application, though, this quickly becomes a dumping ground, a catch-all for things the Product Owner couldn’t quite figure out how to say “no” to.
But with the Product Goal, the Product Backlog is an opinionated description of the future of the product. Items that don’t pertain to the goal can be readily dismissed, resulting in a cleaner, more valuable Product Backlog.
“The team should agree on a safeword with management”
“Scrum makes the broken surface really fast.” When coaching, instead of “here’s how to fix this for better Scrum”, point out how Scrum has revealed an obstacle to your team/org’s goals.
Re-evaulate the Product Goal every sprint. Re-evaluate the Vision every quarter.
Product Goal vs. Epic? An epic is smaller, but also larger than a Sprint Goal.
Product Goal Canvas (Ralph Jocham)
with Richard Lawrence
“Enough to start work, but not enough to finish work without more collaboration.”
Too early leads to waste and rework. Too late leads to scrambling and dependency delays.
Items should progressively split as they move up the backlog.
Like a Work in Progress limit. About 2 sprints worth of stories, with bigger items further down.
When pairing Scrum with Kanban, the Kanban board contains the Sprint.
To keep the limit: don’t take meetings or hold conversations about items further out. Schedule those meetings for further out. If those stories are reordered lower in the meantime, cancel the meeting.
(Anecdotally, one BA went from a 60-80h work week to joining the team for happy hour in one sprint by doing this.)
This is like having a meeting for programming. Refinement is an ongoing activity of the team, and does not require everyone to be present for all of it. Estimation should still be done all together.
Small vertical slices is the common factor in successful software teams. (Uh, source? Not Project Aristotle)
Teams can learn to slice stories vertically in about 3 45m sessions by doing this exercise:
The Enabler (or Chore) item is an anti-pattern that helps to hide or avoid more complex scenarios where the user gets value.
This rears its head often in Business Intelligence/Data development. The antidote is that for Data work, the PBIs should be questions that the user wants to answer using reports or tools like Power BI. Start with the most interesting/valuable one!
“We have to nail down all the details before we can build this”
“You didn’t put that in the AC, so that would be a separate story.”
Details are emergent! Before coding begins, have enough detail to start and not enough to finish.
with Lyssa Adkins
Agile Coaches are the 21st century’s leaders. Trying to account for what they do by 20th century (industrial) means is necessarily missing the point (like dividing a moving train into boxcars).
What coaches do is invisible from outside the team.
Making other people more effective and accountable
The question “what did you do?” is meant to get at “what is your worth?”, usually from someone paying you.
Coaching Agile Teams, p. 280