Pragmatic Agilist

In the glory days when giants still walked the earth and the Agile Founding Fathers created "the team," they decreed that there would be three "team roles:" The Product Owner The Scrum Master The Team The product owner would be omnipresent and omni-knowledgeable, the scrum master would (somewhat mysteriously) "move boulders and carry water," and the team itself, the AFFs explained, would be "cross-functional."  Without being told how, the team would just swarm around the work and get it done:  analysis, design, development, testing, release, the works.  Boo-yah! It's a seductively simple fallacy of division to interpret the concept of "cross functional" team to mean a "collection of cross-functional individuals."  New agilists are quick to apologize that "we still have functional silos here" as though it would be much better if everyone could do all the same things.  Grab some equally skilled poly-funct

As you join your teammates in your sparkling new agile team room , and you all do your best to quickly "become agile," I guarantee that despite being surrounded by brightly colored index cards and sticky notes, you may sometimes feel...angry.  Here you are, supposedly liberated to be "self managing," out from under the collective thumbs of your corporate hierarchy, and you realize that you are reminded briefly of the Lord of the Flies .  Your agile pilot has quickly, as promised, surfaced all possible risks and issues to the project.  That idea sounded good on paper.  In real life, you have ripped the comforting blanket of denial from yourselves, and now, rather than waiting for the UAT team to take the bulk of your business users' thwarted fury eighteen months from now, you already see problems right at the beginning of the project, where you've never seen them before: Inappropriate cost estimate Unrealistic project schedule Slap-dash business cas