The IT Shop Playbook
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.