The 4th annual conference for Agile Austin (Keep Austin Agile) was high-energy, plush, and well-attended. The day was a bit of a blur for me, with the excitement of presenting my session and doing interviews, such as for Agile Amped. But after weeks of noodling on what I heard presented and discussed, I found that several notions started forming up in my mind:
Agile lives, but Sprints are aging
In several sessions and table discussions, agilists complained about the nature of sprints, that their cadence is necessarily disruptive to the creative process. This definitely echoes the laments of my coworkers on Scrum teams: "As soon as we ramp up (cognitively) on the feature, it's time to shut it all down arbitrarily, just so that the sprint can end." Although the x-week sprint does put a stake in the heart of Waterfall projects from hell, it does so by forcing Waterfall into a tiny box (a sprint), where it can do less harm. Within the confines of that box, the mini-waterfall lives on, with downstream folks (QA, docs) bearing the brunt of the crunch.
Looking toward Lean and Kanban
I heard much longing to find a way to lower the stress and remove the mini-Waterfall box altogether, with lots of exploration of Lean and Kanban concepts. People sighed at the dream, noting that a truly unbroken stream of development would require far, far better epic and story development than most shops know how to do, and I agree. Dragging down velocity is murkiness — about the architectural big-picture, the integration impacts and touch-points, the implicit requirements and forgotten dependencies — none of which Scrum, with its myopic focus, handles particularly well.
To remove this murkiness will require, perhaps, a willingness to rebalance our teams, to add more analysts and architects. Even (gasp) add more writers, so that we could move the product documentation up to the pre-coding phase, to force stakeholders to grok and argue about what's being proposed before the team commits any code. (Most teams would find it faster to code to and test against documentation-as-specification rather than dream it up from stories.)
Just this morning I saw my longing for Lean mirrored in a piece by Tom Johnson: Context switching and efficiency -- Kanban to the rescue? Perhaps it's time to pursue this. Definitely time to read up.
Scrum of Scrum must be visual
Related to the search for a better way to work was a search for a better way to see. I attended a talk about the need to achieve a comprehensive Portfolio view across teams. He described a physical method: cards (one per feature/epic) posted in swim lanes on the director's glass wall, to show whose urgency was bumping what from completion, with notes explaining the situation. I've also worked with that physical method, once on the director's glass office wall and once on the wall to the break room, and my experience says it's critical to keep the cards small enough to preserve the big picture at glance — if it sprawls too much, the brain truncates it.
The goal of Scrum of Scrum is to break teams out of their silos and make everyone aware of and responsive to the fires flaring over the cube walls. Unfortunately, relying on whisper-down-the-alley from short-term memories of those who managed to attend is inconsistent at best, and distributed teams are even more disadvantaged. We need a visual SoS, so even just a table that summarizes the cross-team statuses is a step towards grasping the whole:
However, to truly defeat team silos with a visual board, I think hand-maintained systems can get us only so far. We need our tools to automate this for us, such as Portfolio for JIRA, for shops using JIRA.
Comments