Steps to start implementing Scrum

#scrum #scrumteam #implementingscrum

Not a very uncommon scenario, as Agile Practitioners we understand a requirement and wanted to execute the work related to product development with an end to end team, component team, or any other combination which is suitable in the context. Many a times we do have the scenario of an already existing team working in a waterfall/adhoc model, and target is to have quicker feedback, work closer with business due to dynamism of the work, reduction in time to market etc. etc.

Assuming that we have done due diligence of Scrum is a correct execution framework (Scrum for it's effectivity is suitable when you can pull things for an iteration at start ("Batch Pull")). Now what are logical steps. I am very sure most of people do know about development team, PO, SM, backlog.

Idea of this article is put this into a sequence of steps (some steps will go parallel also, not that it's a linear sequence always with Finish to Start Dependency)

These are the high level process steps to get started on the implementing scrum

1)???Pick a Product Owner: First step is to pick a product owner who is knowledgeable to create a correct vision of product and what you are going to do, make, or accomplish. Product owner will take into account risks and rewards, what is possible, what can be done, and what they are passionate about.

2)???Pick a Team: This team needs to have all the skills needed to take the product owner’s vision and make it a reality. Teams should be small ranging from 3 to 9 people (thumb rule). This team size is debatable, but let's move ahead.

3)???Pick a Scrum Master: Scrum master will coach the rest of the team thru the scrum framework, and help team eliminate anything that is slowing them down. At start particularly when you are forming a new team completely or moving from waterfall to scrum, it's important to have a mature scrum master to ensure people understand framework well and get required guidance

4) Create and prioritize a Product Backlog: This is a list at a high level of everything that needs to be built or done to make product vision a reality. This evolves over the lifetime of product and turns into a product roadmap. Product owner is responsible for maintaining a healthy backlog and is required to make prioritization decisions across the entire spectrum in consultation with all the stakeholders and the team to make sure they are representing what people want and what can be built.

5) Refine and Estimate the Product Backlog: This is a continuous activity to ensure that more and more details are added into the product backlog items and items in product backlog are estimated. Team looks at whether enough information is available in backlog item and see if it’s actually doable and create a visible value. Don’t estimate the backlog in hours, as people are terrible at doing that. Estimate in relative sizing using fibonacci sequence (1,2,3,5,8,13,21 etc.)

6) Sprint Planning: This is first of the Scrum meetings. The team, the Scrum Master, and the Product Owner sit down to plan the Sprint. The team looks at the top of the backlog and forecasts how much of it can be completed in the sprint. If team has been going for a few sprints, they should take in account the velocity delivered as input for the planning process. Scrum master and team should be trying to increase that number every sprint. In this meeting emphasis is on to ensure that everyone understands exactly how these items are going to fulfill the vision. During this meeting everyone should agree on a Sprint Goal, what everyone wants to accomplish with this sprint. At the start some teams do create subtasks to track things are more granular level and assign time estimates to the sub-tasks which roll up to estimate of the work item. This is not a mandatory practice but sometimes situation may demand to take this approach

7) Make Work Visible: The most common way to do this in Scrum is to create a Scrum Board which depicts various states in the workflow in which user story moved from various stages to done state. Another way to make work visible is to create a Burndown Chart. Teams might use combination of both also.

8) Daily Stand-up or Daily Scrum: This meeting is heartbeat of the scrum, where all team members and scrum master meets every day at same time and same place for note more than 15 minutes and answer the 3 basic questions of i) What did you do yesterday to help the team finish the Sprint ? ?ii) What will you do today to help the team finish the Sprint ? iii) Is there any obstacle blocking you or team from achieving the Sprint goal ?. This meeting needs to be time-boxed to 15 minutes, and this is just a sync up meeting and not a status update/reporting meeting. Intent is to quickly make any changes as needed to achieve sprint goals by taking a quick stock of what everybody is doing.

Any items needing detailed discussions between specific team members or a group of members should go into "Parking Lot" after the Daily Sync is over. Idea is to ensure that we follow the dail sync agenda and then take up additional things post that

9) Sprint Review or Sprint Demo: In this meeting team demonstrates what they have developed in the sprint. Anyone can come from stakeholders, management, customers. Complete team, product owner, scrum master has to be part of this meeting. Team demos what meets definition of done, and takes a formal sign off on the stories being demoed. Feedback is also collected as part of this meeting, which often result into changes into the backlog in terms of addition of new items into the product backlog and/or change in prioritization.

10) Sprint Retrospective: After team has demonstrated what they have accomplished during the last sprint and takes feedback on product from stakeholders, team sit down and discusses n what could have gone better, what went right, and what can be made better in next sprint. What is improvement in process that they, as a team, can implement right away?.?For this meeting to be fruitful, it requires a certain amount of emotional maturity and trust. Focus in meeting is not blame game, but to improve collectively as team and focus on providing the solution for the problems. Team should have the maturity to listen to the feedback, take it in, and look for a solution rather than getting defensive.?By the end of meeting, there is an agreement on process improvement that will be implemented in next sprint. This process improvement sometimes called Kaizen, is put into next sprint’s backlog with acceptance criteria

11) Immediately start the next Sprint cycle, taking the Team’s experience with impediments and process improvements into account