Chapter 6: The Criticality of Real-time Information
A vision exercise. I like Geoffrey Moore's vision statement from Crossing the Chasm. One way to make sure everyone on the project team gets the Level 1 magnification is to hand them each a blank sheet of paper and ask them to write the vision statement; it's fine for team members to pair up or work in small teamlets of three. After 15 minutes have each pair/teamlet read its version of the vision statement. Responses that are similar reflect a good communication and understanding; vastly different responses signify that the vision should be revisited. What natural opportunities are there for restating the project vision throughout the Scrum project? When might the vision need to change? What happens when there is no vision statement? (Note, if you do not currently have a vision statement for your team's project, please add this to your impediment backlog as something that should be resolved with the product owner as soon as possible. If you do not have a product owner, that's another item for your list with an action to find a proxy at least for the short term.)
How can you ensure that the product vision stays visible and fresh in every team member's mind?
What do you do if the product owner does not have a vision statement? To whom might this issue need to be escalated? What specific actions can be taken to ensure that the team has a well-stated vision?
Referring to the Gantt chart view in this chapter, would this be necessary for every team and every project? In which situations would it not be applicable? Is this a view you would want to provide?
The team wants to add tasks to the product backlog. What's wrong with this idea?
The product owner is frustrated that the team says, "We only do release planning for three months into the future because we're Agile." The product owner needs a forecast for eight months in order to win a contract. What can you do? What are the pros and cons of planning so far ahead and basing a monetary exchange off of this plan?
When might a team not need a sprint burndown chart?
Let's say that your team likes the idea of a 55" LED monitor in the team room to project their sprint metrics and your manager approved budget for it. But the team is worrying too much about the perfect set of metrics causing them to stall out on making anything visible at all. Which one or two bits of information would you encourage them to start with? How would you ensure that the job gets done?
Scrum focuses more on real-time broadcasting versus distributing reports; however, which reports (the static kind) might be helpful in your environment?
How might you kick off the Management Scrum or WORST (Waste and Obstacle Removal Scrum Team)?
