Friday 6 May 2011
Scrum Thoughts
Scrum allows a team to continually improve upon the way they work on a constant basis. Since Sprints are time boxed to a specific iteration the team can count on each sprint end to review, improve and hone their processes.
Sprint Retrospective
· After the Sprint Review meeting the team will get together and answer 3 questions:
o What went well?
o What went poorly?
o What can be improved?
· As we are an Agile team using an Agile process we need to continually improve our process and this can only be done if reflect on our process.
Sprint Review
At Sprint end the team shows their work to the Product Owner in the Sprint Review meeting. In the meeting the team presents what it accomplished during the sprint. This is typically in the form of a demo where the whole team participates. The Product Owner has the final authority to determine if a Story is Done. If any part of the work is deemed Not Done a Story is created to represent the work that was not accomplished, but most of the time when this happens it is usually a small task that can be moved to the next sprint and it considered when committing to the next batch of work in that sprint.
Sprint Status Meeting
Sprint Status – The Daily Standup/Scrum meeting:
Each day of the Sprint the team gets together for a time boxed meeting of 15 minutes that we call the standup meeting. The team stands to ensure the meeting is quick. The purpose of the meeting is to keep the team up to date and follows the below process:
· Everyone answers 3 questions
o What did you do yesterday?
o What will you do today?
o Is anything blocking/impeding you?
· We usually also take this time to move the work items to their true state in the Task Board.
The tasks need to be updated daily to allow the team to know where they are and how they are doing against their commit.
This Status of the Task are usually represented through a Sprint Burn down chart show below:
Sprint Planning Meeting
Sprint Planning or the Sprint Kickoff meeting:
At the beginning of each Sprint the 3 roles of Scrum get together to plan and select the work to be accomplished in the Sprint Iteration. I like the Product Owner to come up with a Goal for the Sprint which represents at a high level how they see this Sprint helping our customers. Below is an example of a Sprint Goal:
Support personalization of our product
Add new Shopping Cart to the site
We then move onto the planning phase:
· The Sprint Team determines their available hours for the sprint
· The Sprint Team reviews Backlog and select user stories that can be accomplished in the Sprint Iteration.
o The work selected is chosen in priority order from the Product Backlog
o The work to be done is clearly understood by all. If it is not the team asks the Product Owner for clarification
o The team will review estimates and confirm they are correct to ensure the work fits within the Sprint Iteration
· The Sprint Team then Commits to the selected work which is represented in the Sprint Backlog
· Once the work has been agreed upon and Committed to the team then breaks the work down into Tasks where they put Estimates against each task.
The Sprint
· Time-boxed iteration with fixed deliverables
o No changes to deliverables once a team commits
§ Negotiations, maintenance, etc. are still up to the team.
o No changes to sprint duration, sprint ends on planned date regardless of completion state
· Sprint activities are end to end
o Research, Analysis, Design, Code and Test
o Some Planning / design can be done in the current sprint through Spikes for the next sprint.
§ I use this step to continually clarify the backlog
Scrum Framework
Mike Cohn’ site “Mountain Goat Software” has an image I like to use to represent the Scrum Framework:
On boarding Scrum and Team Dynamics
Along my Scrum path Team dynamics was explained to me through Tuckman’s stages of group Development. This model of group development has 4 stages:
· Forming
o Individuals meet and learn about goals, opportunities. Little shared knowledge, no trust yet, strong desire for direction.
· Storming
o Conflict and polarization around interpersonal issues, roles, goals, standards and processes.
· Norming
o Team identity and cohesiveness develops, new standards evolve, and the new roles are adopted.
· Performing
o High degree of cooperation and interdependence. Goals are achieved smoothly and effectively with a minimum of conflict.
Bruce Tuckman once said “Hyper-Performing” is “The Sum is greater than the aggregate of the parts”. I believe this boils down best what the team will achieve once they have progressed through the 4 stages.
The below graph visually represents the 4 stages:
Pieces and Parts of Scrum
· User Stories
o User stories are usually represented in the below form;
§ As a <user> I want <functionality> ( so that <benefit> )
o This allow us to clearly understand, who wants the feature, what the functionality should be and most important, what the benefit is if we do the story.
o User stories can be very large in scope. When this is true we need to break them down until there are chunks of work that can be accomplished in sprint iteration.
§
· Story Estimation
o We need estimate the amount of work/effort the story represents which helps the Product Owner prioritize value and risk.
· Product Backlog
o Consists of prioritized list of work to be done: User Stories representing, featured, spikes (research) and sometimes bugs
· Sprint Planning Meeting
o This is where the 3 roles of Scrum get together and work to select the work that can be done in the sprint iteration.
· Sprint Backlog
o The Sprint Backlog contains the work that can be accomplished in our time boxed Sprint iteration.
· Stories to Tasks
o Once the work is chosen the Sprint Team will take the User Stories and break them down into Tasks that can be assigned off to team members to accomplish. We assign a hour value to each task so that we can use this data in our Sprint Burn down chart.
· Sprint Task Board
o The Sprint Task board is basically a visual representation of where the tasks are in the below states
§ Story
· All Tasks are grouped under the User Story to be done
§ Not Done
· This is where we start all Task items to be accomplished
§ In Process
· Once we have started work on a Task we move it to the In Process Column
§ To Verify
· Before and item is really Done we need to verify the work is done to our definition of done which can be manual testing, acceptance testing, etc.
§ Done
· Once an item is verified we move it to Done and move onto the next task.
· Sprint Review Meeting
o Once the Sprint iteration is done we hold a review meeting to show our work to the Product Owner and get their buy off.
· Sprint Retrospective
o This is where the team meets and reviews how the sprint was and how to improve it.
Scrum Roles
There are basically 3 roles in Scrum
o A Product Owner who represents the customer
o A ScrumMaster who is a facilitator for the team, a coach not a boss
o A Sprint Team that consists of 7 +/- 2 people
§ Ideally the team consists of Cross functional members that are self organizing with a shared commitment.
One way that I like to explain the difference between those doing the work and those that benefit from the work is through the classic Pigs and Chicken story:
A Pig is someone who has skin in the game. Mike Cohn aptly refers to the people in that role as, “Having their Bacon on the line.”
A Chicken is someone who has something to gain by the Pigs performing, but in the end, really do not contribute day to day to “getting things done.” Their “eggs” are a renewable resource, and many get laid (eggs that is).
Scrum Introduction
The Scrum approach was first described by Hirotaka Takeuchi and Ikujiro Nonaka . They noted that small, cross-functional teams often produce the best results and likened these high-performing teams to the scrum formation in Rugby. Jeff Sutherland and Ken Schwaber used this new process in the early 90s and are known as the first to call this new project/process management framework; Scrum. Another person I always like mention when starting a Scrum discussion is Mike Cohn who has been a driving force of Scrum for over 15 years and is definitely someone I relate to when it comes to the Scrum Process.
I assume you are here either because you are trying to learn about Scrum or can attest that many large companies are using Scrum today including yours. Every time I start to talk about Scrum I always point to the Agile Manifesto that encapsulates 12 principles.
The goal of Scrum is to manage complexity, unpredictability and change through transparency, inspection and adaptation. Scrum is also an empirical approach where teams must self-organize supported by adaptive project management. The key principle is that Scrum == Adaptive.
· Scrum is an empirical approach:
o Empirical process adjusts and adapts based on feedback from experience
· Sprint team must self organize:
o Team determines optimal organization to achieve goals
o Team acts much like a startup company
· Adaptive project management:
o Frequent deliveries, risk and mitigation plans
o Daily status discussion
o Transparency in planning ensures accountability
The Scrum promise:
· Useful product functionality is delivered with every iterate as requirements, architecture, and design emerge
· Closely synchronizes market requirements with iterative deliverables
· Causes the best possible software to be constructed given the available resources, acceptable quality, and required release dates
· Scrum naturally focuses an entire organization on building successful products
· Without major changes teams are building useful, demonstrable product functionality
· Enhances communication between team members (Scrum & Sprint)
· Reinforces a sustainable pace
· Optimized development environment
· Reduced organizational overhead
Joining the "Scrum Collective"
Well, given that this is my first posting for this blog let me take a moment to introduce myself. My name is Keith Taylor, I’ve been walking the halls of software development companies for over 19 years. Currently I’m walking (well running in case my boss reads this) the halls of Blackboard as a Senior Architect for the Transact division located in Phoenix, AZ with a current focus on implementing Scrum. Prior to this, I was the Director of Product Development at Lumension, S.A. (a wholly-owned subsidiary of Lumension, Inc.) in the small, great country of Luxembourg. Reaching even further back in time, I fulfilled multiple roles at Microsoft located in the Redmond, WA headquarters.
During my entire hall walking history, I’ve seen more project management processes come and go then I can count on both hands. They all start off with the same stated goal, produce quality software that meets the intended requirements in as short a time as possible. The vast majority of these processes go about pursuing that goal with varying levels of detailed analysis and introspection into every aspect of the overall development process (one even made me record how much time I spent in the bathroom!) - mostly with an underlying goal of controlling change to reduce impact to the stated plan of record. When I was first introduced to Scrum I became intrigued because while the goal was the same - it actually embraced change vs. trying to control it. Since then, I’ve experienced Scrum from many perspectives starting with ScrumMaster training provided by Jeff Sutherland, to rolling scrum out internationally, to training an entire division on the principals of Scrum, Agile, and Lean techniques.
The last five years of my hall walking I’ve been almost completely and solely focused on helping teams adopt Agile and Lean techniques within the framework of Scrum. I’ve worked with Scrum teams located in six geographies spread across three countries. I’ve transitioned existing organizations to Scrum as well as built new teams from scratch. I’ve lead and participated in Scrum tuning groups that were tasked with regular review of team’s adoption and utilization of Scrum in order to adapt the overall Scrum process on a global scale. I’ve been hands on with Scrum from almost every perspective; a team member, a ScrumMaster, and as senior management leading the charge.
My goal for this blog is to share my Scrum experiences and in so doing hopefully grow my own understanding of Scrum, Agile, and Lean techniques through your comments and the following discussions sure to take place.
Subscribe to:
Posts (Atom)