2 fast 2 valuable
Use:
This format let's you assess different working practices. So it's particularly useful for a newly formed team or where team members have different ways of working from each other (for example they haven't been pairing)
Length of time:
60 minutes +
Short Description:
Team members place a post-it note for each practice or tool they use against two axes. The axes are how much value something helps deliver, and how fast it helps you deliver. This lets you identify and talk about items that, for example, some team members feel slow you down but others feel speed you up. As a result you can focus on concrete ways to change day-to-day work to address the difference
Materials:
- Flip chart or whiteboard
- marker to draw axes
- post-it notes
- sharpies
Process:
First draw the two axes large enough to hold at least 5-10 post-its per team member. People can tend to add a lot of items
Once the axes are on the board draw on the quadrants this represents and explain how to place items against them. Add one or two to give people an idea of how to contribute.
Next allow 10-30 minutes (depending on team size) for people to place their post-its.
This can get bogged down in discussion over where something should go. The facilitator should allow the discussion to run while it is constructive but if starts to drift or hit a stalemate then remind people they can add the same item more than once and that can be discussed at the end.
Once everyone is finished talk through what is on the board. Looking for areas where
- everyone agrees,
- areas that are useful for coaching or surprising (e.g. tests are not valuable, or deploying software slows us down),
- and areas with stark differences (often this is where developers and "project managers" differ on the value of, for example, roadmaps for stakeholder reporting).
If there are a lot of areas to discuss you can highlight the areas and dot vote to prioritise the discussions.
When discussing the discoveries the highlight is to discuss how to increase the value the team can deliver and the speed it can deliver at.
Example 1
TDD might be considered by some to slow them down even though it protects against defects. Potential actions are to practice katas together or mob on changes so that a team style develops or to refactor code to improve its testability
Example 2
Or developers might consider work creating roadmaps to slow us down but delivery or project managers can explain that it enables them to communicate and set expectations. Actions can be set to reduce the effort required to create and maintain the roadmaps so that they still release value with less impact on team speed
Source: