Kevin E. Schlabach

Category: Framework

  • The Red Bible

    Every new hire at one company I worked for got a copy of Jeff Sutherland’s Scrum: The Art of Doing Twice the Work in Half the Time. The red cover. Hard to miss.

    Due to my role, people would find me and ask what I thought of it. They expected enthusiasm. What they got was: “There’s a bunch of good points in that book. But I hate the gratuitous title and cover.”

    Twice the work in half the time. That’s the promise on the label. What about twice the quality? What about delivering twice the value? Speed and volume are the wrong things to optimize for, and stamping them on the cover of the movement’s de facto onboarding text sets the wrong expectation from page one.

    The conversation led somewhere useful.

    I’d explain that when the Manifesto was signed in Snowbird in 2001, the 17 signers weren’t a Scrum delegation. XP had the largest contingent. Crystal was in the room. The Manifesto itself doesn’t mention Scrum at all.

    Treating Scrum as the destination misses what the movement was pointing at. It’s a good place to start. Prescriptive enough to teach, concrete enough to get traction. But the path doesn’t end there. Kanban and XP each offer something Scrum alone doesn’t. A fit-for-purpose approach looks different for a 6-person startup than a 200-person engineering org, and no single framework covers both well.

    There are high-holiday agilists: people who know the vocabulary and can name Scrum ceremonies. And then there are practitioners who’ve wrestled with the ideas, hit the edges of the frameworks, and kept going.

    That said, handing everyone the same book does something real. A shared experience creates a common vocabulary and a reference point people can actually baseline and grow from. That alignment has value, especially early.

    A Scrum book is a decent starting point. Just don’t stop there.

  • Crystal Methods existed before SAFe

    Last week I referenced Alistair Cockburn, and this week I want to go a step further into his work.

    If you don’t know Alistair, he was representing his Crystal framework at the signing of the Manifesto in Snowbird 2001, and later created the Heart of Agile movement.

    Sitting in his talk at a 2010 Agile conference, I saw something in his teaching that wasn’t prominent in other Agile approaches. This diagram provides a visual overview.

    When planning organizational structure and process, he suggested leveraging this grid. Up the Y-axis is the level of criticality: near the bottom is something like a simple mobile gaming app, while the top represents systems where life may be at risk, such as software used in an operating room. Across the X-axis is organizational scale: on the left is one agile team of 6 people, and on the right is an organization with 20+ teams and 100+ people.

    His point was simple: if you are building a mobile app with a single team, you clearly need a different process than if you are building clinical healthcare systems with 25+ teams.

    This is obvious once one pauses to ponder it.

    The agile movement has since evolved, and we now have scaled frameworks intended to adapt team-level Scrum to larger, more coordinated organizations. But taking a “placemat” framework and applying it as a rubber stamp across every team goes against the above realization. If you force every team in your organization to follow the same framework and pattern structure, then you are inhibiting teams, not enabling (or protecting) them. You might need more governance in some areas, but don’t impose this on all teams because of the few.

    Allow teams to leverage a process that is fit for purpose. 

    Add governance and complexity to processes that demand it. Simplify and streamline for the teams that don’t. This may be more complicated than managing a tidy one-size-fits-all approach, but the goal of your organization should be to enable efficient delivery of value with appropriate quality, not to make the PMO easier to manage.