Using the Agile Cookie Cutter
How would you set up your next project? What would you require? I know what I’ve tried in the past – here’s a brief inventory of my standard Scrum Toolkit:
New Artifacts:
Team Working Agreement
Team Definition of Done
Task Board
Burn down chart
Impediments list
Release Plan
Backlog
New Meetings:
Sprint Planning
Daily Standup
Sprint Review
Sprint Retrospective
Backlog grooming
New Concepts:
Stories
Story points
Sprints
Releases
TDD
Continuous Integration
Cross Functional Teams
New Roles:
Team Members
Scrum Master
Product Owner
Boy, that’s a pretty long list of stuff. Looking at it, it sort of gives a guy cause to pause and wonder just how any team could absorb all of that. I guess that explains the deer-in-the-headlights look I get sometimes when I introduce teams to Agile processes. Do you need all of that to write good software?
This list is what I might call my “Agile Cookie Cutter”. It is the common set of ideas and practices that I try to role out with every team that I work with. But lately I’ve been thinking that slapping all this on a team all at once isn’t so smart. What I often see is teams going through the motions, adopting these practices whether or not they really need them. People get frustrated when they adopt processes wholesale and then run into problems with subsets of practices. What ever happened to gradually introducing practices and empirically testing their effectiveness?