Home » The IT Shop

The IT Shop Playbook

29 July 2010 No Comment

playbook2

Every prepared team has a playbook.  What does that mean in an IT Shop?  Poorly run shops have only job descriptions and deadlines.  Everyone is left to fend for themselves.  Instead of feeling like they’re on the same team, this can leave the players at odds with each other.  For example, if the analyst is only focused on their job, a developer who tells them that a spec item they wrote is not technically feasible  may be met with an argument instead of a conversation which may lead to a solution.  A developer who is too focused on their job may not bother with proper release procedures and leave the QA team with a compromised deliverable.  A manager who is hyperfocused on a deadline may lack the perspective to organize their team to meet it.  An architect may find themselves at odds with the users by prioritizing the redesign of the data layer over the repair of irritating bugs.   Does any of this sound familiar?

That’s why it is important for each player in the game to understand the positions around them and to share common goals.  The objective is not to “throw the ball”, but rather to “strike out the batter”.  This requires collaboration between the pitcher and the catcher, a local play.  The objective is not to “catch the ball” but to “achieve three outs”.  This requires collaboration between every member on the field, teamwide plays.  Softwareball is a dynamic game with a field that’s always in flux.  That’s why it requires a good playbook.

Teamwide Plays

Some call the large-scale, teamwide plays “workflow” or “methodologies”.  These are ways for the entire team to self-organize, to get on the same page, to communicate throughout the software development process.  Here are a few industry standards:

  • Software Development Life Cycle
  • Waterfall/Spiral
  • Agile/Scrum
  • CMMI
  • KANBAN

The large-scale plays must tie into the organization-wide playbook: communication documents such as mission statements, product strategies, project plans, requirements, specifications, and technical documentation.

Local Plays

Each player has an area of the field they are responsible for.  The developer handles the code, the analyst handles the specs, the project manager the project plan, etc.  Each of these areas has plays that are specific to their immediate surrounding areas, but do not involve the entire field.  These are local plays.  Most local plays are quite area-specific and evolve quickly so we won’t go into them in too much detail in this book, but it is important for each player to understand the array of plays available to them and for other teammates to have at least a general idea of what someone might be trying to do with the ball.

Read more about the players and their plays

Your thoughts?

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

Be nice. Keep it clean. Stay on topic. No spam.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.