Including external stakeholders in a business-to-business product context.
A Product Backlog isn't synonymous with "work to be visualized, tracked, and completed by the team".
Planning with a focus on the team's capacity for doing work tends toward optimizing getting work done instead of delivering value.
Not all work before the team needs to directly relate to the current goal.
Visualizing "blockers" and blocked work on a Kanban board.
When using flow-based systems like Kanban, a regular synchronization meeting or standup isn't about blocked work, but the team's flow metrics.
15 minutes is usually long enough for a Daily Scrum or standup if you focus on planning instead of statusing.
It's not if, but how much, you model and analyze before writing code.
C4 modeling, including representing AWS S3 buckets on Context Diagrams and message brokers on Container Diagrams.
Manual testing isn't dead.
The significance of 1.0.0 in Semantic Versioning.
Metrics programs don't begin with metrics. They start with the problem.
Flow metrics for productivity in Scrum with Kanban.
Open, honest, and hard conversations are important to building trust between teams and stakeholders to solve problems that analyzing metrics or using a stick approach can't.
Combining coach responsibilities with line management responsibilities may lead to a diminished ability to coach toward a self-organizing and self-managing team.
Understanding the rationale behind the structures in canned frameworks, the context in which the team is working, and how to build ways of working is more important than using a canned framework "properly".
Enjoy this post?
Buy ThomasOwens a coffee
