Scrum 3 Roles, 3 Ceremonies, 3 Artifacts, 3 Best Practices - Dan Mezick
I'm not sure how to write this session up. This was by far the most compelling session I attended. Dan is a dynamic speaker, his points are sound and I found the approach to development he described very appealing. There was so much content presented during the session I'm not sure any blog post I can write could do it justice.The session was an overview of Agile and Scrum. I've never worked in a development group that embraced the agile approach. Many of the teams I've been on have conducted what they called "Scrum" meetings, but those meetings didn't match what Dan was describing - let alone the process that was supposed to accompany it!
What was fascinating about Dan's presentation was it was more about team dynamics and interpersonal relationships than it was about the development process exactly. The same techniques being described could apply to any team trying to complete a number of tasks in support of an end goal. The whole process being described was very empirical in how the project's progress is being tracked. One example of this is to hold off making a decision until the "last responsible moment." I LOVE this concept. The idea is that as more information comes in we can make a more informed decision. If a decision is made early on it is human nature to not reverse that decision - even in the face of additional evidence. By delaying the decision to the last responsible moment we're increasing the odds that the decision being made is as fully informed as possible. I'm hoping to adopt this in my daily work as application designs are considered.
Another example of having a project managed by evidence had to do with project schedules. The idea of backing into a release date, for example, appears to be completely abhorrent in this system. By identifying the release date early the team exposes itself to "inattentional blindness" which is a phenomenon where people don't see something that's there because they are paying a lot more attention to something else. In the case of the release date, the team becomes so focused on the scheduled release date they are unable to perceive changes or events that had they been perceived would lead to a change in the release (either schedule or scope).
The 3 Roles
Dan described an appropriately organized team as consisting of 3 roles: the product owner, the Scrum master and the team.- The product owner is the individual responsible for collecting and elaborating the project requirements and putting them into the product backlog (see the 3 artifacts). This individual is the interface with all the stakeholders who are interested in the resulting product (e.g. management, sales, marketing, users, etc.).
- The Scrum master is the individual (and it is an individual - one person, singular) responsible for product backlog - they own and prioritize it. The Scrum master is not a traditional project manager. Their job is to "patrol" the product boundery to ensure no requests are coming into the product backlog that are not appropriate for that product. By having this be an individual the product backlog prioritization is not subject to the conflicting whims of multiple individuals
- The team is self-organized. The team participates in the product design. They decide on a subset of the product backlog that will be addressed in a particular sprint. A good rule of thumb is to have +/- 5 to 7 people on a team. No one who is allocated less than 50% to the project is considered a team member. "Committed people" are >= 50% allocated, everyone else is merely involved.
The 3 Ceremonies
The process Dan described is punctuated by a few types of meetings (there are always meetings, right?); Sprint planning meetings, daily Scrum meetings and project retrospective meetings.- Once the Product Owner has put all the requirements, requests, bugs into the product backlog and after the Scrum master has prioritized the backlog it's time for the team to meet. The purpose of the meeting is to decide what can be accomplished in the next development period. These development periods are 2 - 6 weeks long and are called "Sprints". In the sprint planning meeting the team identifies which sub-set of the product backlog can be accomplished in the sprint. The team must pick off the top of the product backlog (ensuring priority work is being done) but they decide how many of the items realistically can be completed. Other stakeholders can attend the sprint planning, but it's the team's meeting. Also, remember before I mentioned the team is self-organized? This is part of what that means. It's worth noting that by making the decision about what to work on this way, the team is delaying decision until the last responsible moment. The product backlog is as mature as it can be, so the team is committing to the truest priorities possible.
- Once the sprint is underway it's important for the team to meet daily to provide an update on progress. This is the daily Scrum meeting. Each team member reports what they accomplished the prior day, what they intend to accomplish that day and what (if any) obstacles are in the way. The reason the meeting is daily is to prevent "cognative dissipation." The idea is if I say I'm going to do feature 1 today, and nothing is in my way, the team is going to notice if feature 1 isn't finished (or at least had progress) tomorrow. If the scrum were held weekly, well, who remembers what they worked on a week ago let alone what commitments a peer made? Having the ongoing, consistent knowledge might prompt one of my teammates to find out what problems I might be having. Again, this is the team's meeting. Other stakeholders can attend - but they better stay out of the way...
- Once the project is complete it's time to reflect on what worked well, and what needed improvement. That's the project retrospective meeting. These meetings might expose some hurt feelings and raw emotions. On a mature team these can be worked out. The goal is to improve the process for everyone so the team, product owner and scrum master can do better the next time around.
The 3 Artifacts
There are three documents
- By now you probably have a good idea of what the product backlog is; it's a prioritized list of each feature, enhancement request and bug that is to be incorporated into the product. Normally the list is dynamic. Requests are made, bugs reported and the product owner adds all that to the product backlog. The Scum master prioritizes the product backlog and the team provides estimates on level of effort for each item on the product backlog. However, once the sprint is underway the product backlog is static (at least as far as priority goes). If requests/bugs come in they can be added to the bottom of the stack, but nothing gets prioritized to the top. That's because while the sprint is underway the team is working off the sprint backlog.
- The sprint backlog is the result of the sprint planning meeting. It's a mini-product backlog of what the team will be delivering in the sprint. Because this is what the team has committed to deliver, and that commitment was made at the last responsible moment, it is unacceptable to change the priorities of the sprint once it has begun. That's why the product backlog is static during a sprint.
- A burn-down chart is a graph that shows work to be done on one axis and time remaining on the other. Dan showed some examples. Google can help you find examples, too.
The 3 Best Practices
Unfortunately, by the time we got to talking about the best practices, Dan was out of time. He threw up a few slides and pictures to communicate the ideas, but I'm just going to provide some links which will cover the topic more completely.
- User Stories are a way to capture user requirements.
- Planning Poker is a technique teams can use to provide estimated levels of effort for items on the product backlog.
- Scrum Board (a.k.a. task board) is a tool used to reinforce the work being done. This is the only thing I've been able to implement in the immediate aftermath of the code camp. My whiteboard has been converted to track the tasks on which I'm currently working. One of of my teammates likes it, too, and has started using one. I expect we'll use one for our team in short order.
