top of page
Articles: Blog2

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:

  1. Team Working Agreement

  2. Team Definition of Done

  3. Task Board

  4. Burn down chart

  5. Impediments list

  6. Release Plan

  7. Backlog

New Meetings:

  1. Sprint Planning

  2. Daily Standup

  3. Sprint Review

  4. Sprint Retrospective

  5. Backlog grooming

New Concepts:

  1. Stories

  2. Story points

  3. Sprints

  4. Releases

  5. TDD

  6. Continuous Integration

  7. Cross Functional Teams

New Roles:

  1. Team Members

  2. Scrum Master

  3. 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?

#CookieCutter #Team #Tools

0 views0 comments

Recent Posts

See All
bottom of page