Scrum 101
I’m known as the ScrumMistress around the office, but as of the end of August I’ve actually officially earned the name. I attended a ScrumMaster course put on by the Software Productivity Center & Winnow Management and am now a certified ScrumMaster.
Scrum is an iterative, incremental, Agile process for developing any product or managing any work. It is a project management process, but certainly not a methodology as that would be too heavy. The key to Scrum is having self-managed teams. A ScrumMaster is the person in a project team that is responsible for Scrum values and practices within the team.
At 2Paths we live and breath the Agile Manifesto:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.*”
When signing up for the ScrumMaster course I had expectations of learning “New Great Things” that I could bring back to 2Paths to implement to augment our current Scrum and Agile practices. It was refreshing to instead have it confirmed that at 2Paths we’re actually pretty much already following the Scrum process to a T.
Scrum Roles
There are three roles in play in Scrum: the Team, the ScrumMaster, and the Product Owner.
The Team
The team is usually around 5-9 self-managed people who are responsible for the actual work to implement product functionality. Team members are accountable to the team, not to a manager.
The ScrumMaster
The ScrumMaster is responsible for Scrum values and practices in the team. The ScrumMaster is a “Process Manager”, not a “Project Manager”. They establish key scrum meetings, protect the team from interruptions, and facilitate removal of any blockages facing the team.
A ScrumMaster should be a good facilitator, be open-minded, tactful, and deal well with conflict.
The Product Owner
The Product Owner is usually the Client, but could also be internal to a company. They are responsible for the Product backlog, establish and promote the vision of product, and are responsible for the ROI by prioritizing work. Scrum dictates that this should be only one person.
The Scrum Lifecycle
The Scrum Lifecycle of a project differs widely from traditional software development lifecycles in that work is done in fixed time-boxed iterations, or “Sprints”, yet the scope of work done in the project is variable.
Scrum Planning
In this phase, high-level requirements are gathered and compiled into User Stories. A User Story is a requirement formulated as one or two sentences in the everyday language of a user. The deliverable from this phase is the Product Backlog (list of User Stories), which is owned and prioritized by the Product Owner. The Product Owner can re-prioritize items in the product backlog at any time.
Sprint Planning Pt. 1 (selection)
The highest priority User Stories from the product backlog are chosen for inclusion in the current Sprint Backlog. The Product Owner cannot re-prioritize items inside the Sprint Backlog, only items in the Product Backlog.
Spring Planning Pt. 2 (decomposition)
User Stories from the Sprint Backlog are decomposed into tasks and the team will negotiate estimates for each of these tasks.
Daily Scrum
This is a daily standup meeting for the project team, facilitated by the ScrumMaster. The daily scrum should take no more than 15 minutes. In the daily scrum three simple questions are asked of each team member:
- What did you work on yesterday?
- What will you work on today?
- Are you stuck?
The team will then look at the Sprint burndown chart – a graph showing how much estimated time is remaining in the Sprint. Daily re-estimation of task effort is also key to Scrum.
The goal of the daily scrum is to ensure good communication between team members and to ensure all team members have the information and tools they need to carry out their work. The ScrumMaster is responsible for facilitating removal of any roadblocks facing the team or team members.
Sprint Review
In the Sprint review, the team demonstrates the work completed in the Sprint to the Product Owner and other stakeholders. A main idea behind Scrum is to show results soon and show results often.
Potential Deployment
At this point stakeholders decide if they want the latest Sprint results deployed.
Sprint Retrospective
At the end of each Sprint, the team members and Product Owner have a meeting to reflect on the pluses (what went well) and deltas (suggested changes or improvements) of the Sprint. The deltas will be recorded as actionables for future Sprints, and deltas from the previous Sprint will be reviewed. The Sprint Lifecycle restarts from here to Sprint Planning of the next Sprint.
Scrum à la 2Paths
We at 2Paths were already pretty much following the above scrum process to a T, although we had been letting a couple aspects slip. We had started neglecting the Iteration-end Team Retrospectives, which we’ve since resurrected. These sessions have been invaluable for constructive feedback in the way we do things, and helping us strive to constantly improve.
We had also been a little slack in the daily scrums in terms of team members giving full descriptive details of their current and future tasks. The team was getting use to answering their daily questions in extremely general terms which was not very useful to other team members, and ultimately to the team itself. We’re trying to change this so that team members’ daily input has enough detail to be constructive to the scrum process. As usual it comes down to team cohesion and productivity hinging on good communication.
In the course I learned a couple of other ideas that we’ve since implemented at 2Paths, such as drafting a Team Charter. The team sits down at a brainstorming session to draft a list of rules to which each team member needs to adhere. These are rules made by the team for the team to foster a cohesive, communicating, and respectful atmosphere. These rules can span any topic from personal conduct to philosophy to technical considerations.
We’ve also begun playing “Planning Poker”, which is an innovative way of estimating time for tasks by the team. We had formerly used a rock/paper/scissors method where on the count of three each team member put out their fingers indicating their time estimates for a task, but it’s been too easy to let other team-members’ estimates influence one’s own estimate. With planning poker we all have to chose a card representing our estimate, then all turn over our card simultaneously.
In my ScrumMaster course one of the best things I learned was how good we have it here at 2Paths. We have a lot less red tape it seems than a lot of my fellow ScrumMaster classmates which makes it a lot easier to get things done. We already have our Scrum and Agile practices in place, and have clients who have quickly become Scrum and Agile converts. Oh, and I almost forgot about the other best thing I learned – the secret ScrumMaster handshake. Who knew?!
Tags: agile, certification, scrum
