Monday, November 21, 2011

Be Transparent

This is part 3 of 3 posts on Scrum. Part 2 of this post is Learn the Scrum Rules of Play.

An important part of being transparent is played by having a transparent way of working. This helps alignment in the team and with its surroundings and enables discussions on improvement. In the next few postswe will introduce two tools for recording and enabling discussions on a way of working: the workflow and the collaboration matrix. A workflow provides a high level, semi sequential representation of (a part of) a process. It brings together roles, tasks and work products in a concise manner. A collaboration matrix gives an overview of knowledge and skills needed for certain work products.

Let’s start with a workflow of a process we already know: the Scrum process. In Figure 31 through Figure 34 we gradually build up a workflow of the Scrum Process. Furthermore we show explicit activities for the Product Owner and Scum Master to clarify their role in the Sprint. A key to the symbols used in this workflow can be found in Appendix C.


In the blog post Learn the Scrum Rules of Play we saw a number of Scrum elements that help the business and the team to be transparent. The Product Owner role provides the team with a single point of contact for decisions about requirements and order of implementation. The Product Backlog gives a clear overview of the work remaining toward the goal of the release or project. The Definition of Done shows which criteria must be met before a story will be delivered as part of a Usable Increment. The Sprint Backlog gives a clear overview of what the team forecasts to get done in a Sprint and how they plan to do that. Figure 31 shows these Scrum elements and their connection.

Figure 31: Scrum Workflow - Plan the Sprint


Figure 32 shows that during the Sprint, the Product Owner keeps track of business needs. The team works on executing their plan and living up to their forecast. Throughout the sprint, the Scrum Master supports and facilitates the team and Product Owner.

Figure 32: Scrum Workflow - Daily Work
Figure 33 shows that at the end of the Sprint, in the sprint review meeting, the team provides transparency by providing updated estimates throughout the Product Backlog, where needed. At the end of the demo the Product Owner shares his view of remaining stories toward the release or project goal and his plan for reaching that goal. Looking back, the team comes up with two or three spearheads for improvement they are going to try out the next Sprint. The way in which the Team organizes itself is really up to the Team. If it works, keep it that way. If it doesn’t, try something else that works. Always look for more effective ways of doing things. You can use experiences from others, but do it as an experiment to see if it fits your team. That’s Scrum.

Figure 33: Scrum Workflow - End of Sprint
Now we are going to look at some practices that are not part of Scrum, but are often used to increase transparency. In the workflow shown in Figure 34 we show some work products that are not part of Scrum  but have proven useful in a lot of our projects. These include a Sprint Burndown Chart and a Release Burnup Chart (further discussed in Chapter 6 Estimation and Planning) showing the amount of work remaining toward the end of the Sprint and Release respectively. We also added an Impediments List for communicating and keeping track of impediments for the team and a Risk List for communicating and keeping track of perceived risks and counter measures (also found in RUP and PRINCE2).

Figure 34: Scrum Workflow – Supplemental Practices

The Usable Increment that is one of the Scrum work products is not shown here but is explained in the blog post Get Things Done.
The fact that Scrum distinguishes no specialist roles within a team, does not mean that the team should consist of only generalists. Most IT efforts are way too complex to pull that off. The notion of roles is useful to communicate the knowledge and skills needed within the team to be able to deliver value to the customer. It can also help in determining which stakeholder representatives to invite to workshops on specific work products. Figure 35 gives an overview of stakeholder roles and team roles and the way they could collaborate to create the Scrum work products we discussed in this section.

Figure 35: Scrum Collaboration Matrix

Just make sure team members are flexible in the roles they play and are prepared to do whatever is necessary to get the job done.

Part 1 of this post is Self-organize using Scrum.
Part 2 of this post is Learn the Scrum Rules of Play.

Other Relevant Posts:

3 comments:

  1. It is the responsibility of the Scrum Master to ensure that the Product Owner does not change requirements or acceptance criteria during the Sprint review and reject a done backlog item because it does not meet the changed requirements. If the requirements have changed, a Product Backlog item needs to be created to address the changed requirements in a future Sprint.

    ReplyDelete
    Replies
    1. Dear Casey, Thanks for your comment. Sounds like the relationship with your Product Owner is somewhat tense. I would say there should be a healthy balance between picking up small incremental improvements with as little ceremony as possible and diverting bigger changes that go beyond the original acceptance criteria to new product backlog items.

      Delete
  2. This comment has been removed by a blog administrator.

    ReplyDelete