...if you have great people that work well together, then Scrum is a good option to help them deal with external forces (e.g. the publisher) and can improve internal efficiency. On the other hand, if you don’t yet have a great team, then Scrum only tries to create a nursery where the team has the opportunity to grow.
But what about teams that aren't so great? According to Alex, that's where "The Core Protocols" step in. The Core Protocols (pdf) (and the associated Core Commitments) are described by Jim and Michele McCarthy in their books Dynamics of Software Development and Software for Your Head. Jim and Michele developed the protocols at Microsoft, where Jim headed the Visual C++ development team. Essentially, the idea is to reduce or eliminate unproductive behavior within a team by formalizing the ways in which the team members interact with one another. The protocols include:
- Check In - Begins a meeting
- Check Out - Used by a team member to when she must leave, or when she cannot maintain the Core Commitments
- Decider - Helps a group quickly reach a decision
- Resolution - Helps the team reach a consensus when there is disagreement following a Decider vote
- Pass - Used by team members to disengage from an activity
- Ask For Help - Efficiently makes use of the skills and knowledge of others
- Protocol Check - Used when a team member believes a protocol is being used incorrectly in any way or when a Core Commitment is being broken
- Intention Check - Clarifies the purpose of a team member’s behavior
Of course, many of these protocols can be used in different contexts. Once you get the hang of them, they tend to reduce the drama anywhere in the development process. Initially, developers may shrug off some protocols as “unprofessional” (e.g. counting to three before voting with thumbs up, or exposing emotions in a meeting), but pretty quickly everyone gets used to the efficiency and the reduced stress.