How to Measure Success? Is it Even Possible?
How do you measure organizational agility? Honest answer: I haven't fully figured it out yet — but here's the story, in all its ugliness. This piece walks through a real-world attempt to define organizational agility in a way that left no one off the hook, then translate that definition into measures that actually meant something. Why activity measures are a trap. Why proxy measures are dangerous. Why comparing teams is the road to gaming. The "BS detector" used to validate the numbers, the four key trends that emerged from the telemetry (including the brutal one — that only 20% of people believed leaders were doing anything about delivery issues), and the surprising suggestion from a wise man that maybe the right thing to measure is the number of inspired people, even if they leave. A candid look at what worked, what didn't, and why context is king.
A Client Reports Back on Progress One Year After a Professional Scrum with Kanban Workshop
It's easy to obsess over the Trustpilot review right after a workshop. Did I entertain? Did I perform? Were people satisfied? But the real question is whether the workshop made a difference to the work lives of attendees a year later. This piece is a candid client report-back, broken into the good (multi-team workflows, Monte Carlo probabilistic forecasting, more frequent delivery, higher customer satisfaction, and new team members picking up Scrum with Kanban from their colleagues without training), the bad (newer teams without colleagues to learn from dismissing Kanban as "overkill" and never looking at the cumulative flow diagram), and the ugly (no full-time Scrum Master worrying about flow, and an expedite lane that would make Daniel Vacanti weep). Plus a personal note from one team member on how it changed the trajectory of their career. A reminder that a little knowledge can be dangerous — but a lot of it can be transformational.
Scrum Master role, Large Scale Scrum or not
Two sentences from Timothy Korson's LeSS case study for "Cash In Comfort" struck a nerve: "Scrum Masters are responsible for a well-working LeSS adoption. Their focus is towards the Teams, Product Owner, organization, and development practices." And: "A Scrum Master does not focus on just one team but on the overall organizational system." This piece is a short note to leaders who expect Scrum Masters to spend all their time with the team. The reality is that the role usually means working with leaders' leaders and leaders' peers, relying purely on influence — ideally riding on the coat-tails of their own leaders. Plus a nod to Elad Sofer's VeSecurity case study on why appointing managers as Scrum Masters isn't the answer either. The better path: partnership between Scrum Masters and leaders to bust impediments and coach the organization. Avoid containing Scrum Masters in a metaphorical cage. Let them do what needs to be done.