For any Scrum Team to succeed with Scrum implementation, Scrum Master is accountable, because the Product Owner and the Developers within the Scrum Team may not be aware of Scrum or may not have prior experience. So, the Scrum Master has a responsibility of teaching them Scrum and also helping them in implementing Scrum in the right way. This article helps the Scrum Masters to know some important information about Scrum Implementation.
Setting up the players:
Scrum is a team based approach just like any sport, so you first need a Scrum Team to start implementing Scrum for any project/product similar to having all the required players to play the sport. So, when you are assigned as a Scrum Master, ensure you also have a Product Owner and the Developers in the team. If you do not find them, then work with the respective person/leader to get them allocated to the team. Make sure the team is not too large and not too small, as per Scrum guidelines, up to 10 including Product Owner and Scrum Master is a decent team size. Also make sure the team is cross-functional, which means as a team all the skills are available within the team.
Team’s Scrum knowledge (Game Rules):
You may be a Scrum expert but the other team members may not be aware of Scrum. So if you start Scrum implementation without knowing Scrum, it is as simple as playing any sport without knowing the rules of the sport. So, first check what level of Scrum knowledge the Developers and Product Owner has about Scrum. You can do this in multiple ways. You can give a brief questionnaire about Scrum framework to everyone individually, collect their responses and understand their level of knowledge. Alternately, you can call all of them into a meeting and ask some questions related to Scrum and check how many are answered correctly and whether only one or two members are giving correct answers or majority people are answering. Based on that understanding, plan a Scrum Training session for 4 to 8 hours. Make the training interactive based learning.
The Play starts (Sprinting):
Sprint Planning: Every Sprint starts with the Planning on the First working day. Make sure everyone is aware of the time and the location of the Sprint Planning meeting ahead. Have a word with the Product Owner to ensure enough items are already available in the Product Backlog to be pulled into the Sprint Backlog. During the Sprint Planning ensure the following things:
- Help the Product Owner and the Developers to create a Sprint Goal (outcome based)
- Encourage the Developers to check for any clarifications or queries on the Product Backlog Items
- If any of the Product Backlog Items are not estimated, ask the Developers to estimate them
- Help the Developers to find their current Sprint capacity (by removing holidays, personal time-offs, or any other people’s unavailability during the Sprint due to organizational activities etc)
- Help the Developers to check how much work (how many Product Backlog Items) can be pulled into Sprint Backlog based on the last Sprint performance (velocity) and the current Sprint capacity.
- If it is the First Sprint, then they do not have the last Sprint velocity so let them pull based on their gut feeling
- Once the Product Backlog Items are selected for the Sprint, let the Developers decompose them into smaller tasks of 4 to 6 hours each. They can take Definition of Done as reference to come up with the tasks
- You may ask the Developers to decide on their own who will work on which task for the first one or two items and NOT for all items. This helps the Developers to have a plan of action for the next 2 to 3 days into the Sprint.
- By the end of the Sprint Planning, a Sprint Backlog should be created with the following:
- A Sprint Goal (Outcome to be achieved)
- Selected Product BAcklog Items (Output selected to achieve the Outcome)
- A plan (The tasks for the Product Backlog Items selected)
- At the end of the Sprint Planning, ask the Developers how confident they are to achieve the Sprint Goal. You can use fist of five technique for checking (if you do not know fist of five, google it)
During the Play (After the Sprint Planning and before Sprint Review):
- While the items are being implemented, make sure the Developers work on 1 or 2 items at a time so that they can focus more
- When a Sprint Backlog Item is “Done”, let the Developers do the following activities:
- Check the Definition of Done for the item that is completed
- Show the item to the Product Owner to get his/her sign off
- Update the Sprint Progress (Burndown/Burnup or any other tool you use)
- Encourage the Developers to work as a team on the Sprint Backlog Items instead of individual Developer work on one item individually. For example, if an item “REgistration” is being implemented, let one Programmer, Tester, Database and UI person work together on that item. This will improve the collaboration, accountability and knowledge
- Encourage the Developers to automate the Unit test cases, Functional/Regression/Integration test cases so that they can save considerable amount of time and effort instead of doing them manually
- Let the Developers follow the coding standards for each item they build
- Let there be a peer code review done so that the code is reviewed by some other Developer
- Let the Developers following continuous integration throughout the Sprint
Daily Scrum: Daily Scrum is a daily inspect and adapt opportunity for the Developers. Initial few days help the Developers in the Daily Scrum so that they know how to conduct it, what to discuss, what not to discuss. If they do not know the Structure, try to help them with some structure like the “Round Robin” structure. Your objective is not to be there as a supervisor for the Developers in the Daily Scrum but to make sure they become self-managing. Some Dos and Don’ts for the Daily Scrum are below:
- All the Developers join the Daily Scrum on time
- Timebox of 15 minutes is followed
- Impediments are just highlighted but not resolution
- Everyone speaks about their contribution towards the progress
- You do not ask one by one the Developers for their update, it becomes status update
- Let one Developer start giving update and then call the other person name
- They have a plan for next 24 hours by the end of the Daily Scrum (if you recollect above in the Sprint Planning, they had a plan for first 2 to 3 days in the Sprint Planning, but every day they inspect and adapt their plan during Daily Scrum)
- They do not discuss the in depth technical details like code logic, implementation details of Product Backlog items
- Encourage the Developers to update the impediments in the “Impediment management” board (we have discussed this in our CSM class)
- You are not the owner of the Daily Scrum, it is the Developers’ meeting
- Use effective format/structure such as round robin with one person starting and then he/she calls randomly any other name in the circle. If you go clockwise or anticlockwise it will make the last person “mind absent body present”. So if you call random names everyone will be attentive.
Product Backlog Refinement:
Somewhere during the Sprint, you have to facilitate the Product Backlog Refinement meeting having Product Owner and Developers. There is no prescribed occurrence or timebox for Product Backlog Refinement as per Scrum. However, if you have towards the early second half of the Sprint that will be suitable. For example, if your Sprint is 2 weeks (10 working days) then schedule the Product Backlog Refinement on the 6th or 7th day. Make sure you take care of the following for the Product Backlog Refinement:
- Every Sprint, before the Sprint Planning closing, you get confirmation from all the Developers and Product Owner for their availability during the Sprint for Product Backlog Refinement
- Whichever day all the Developers and Product Owner are available during the second week of the Sprint, that day can be decided for the Product Backlog Refinement
- Product owner sends a meeting invite for the Product Backlog Refinement as per agreed date and time
- During the Refinement, let Product Owner clearly explain each Product Backlog item to the Developers
- Encourage the Developers to ask queries, doubts or clarifications to the Product Owner related to that Product Backlog Item
- Once the Product Owner answers the Developers’ queries, let Developers discuss any dependencies for that item with any other item in the Product Backlog.
- After the dependencies are identified, let the Developers discuss high level architecture/database/API etc changes to he done for that Product Backlog Item
- Here the Developers should share all their collective knowledge and experience to identify the design/architecture changes required for that item
- Once they have the details, let the Developers estimate the Product Backlog Item.
- All the Developers should contribute for the estimation and it should be consensus based estimate
- Update the estimate for that Product Backlog Item in the Product Backlog
- Within the agreed time for the Product Backlog Refinement, ensure at least 5 to 6 items are refined, discussed, clarified, understood, estimated and ordered
- If any item cannot be estimated because of information missing or pending clarifications, then keep that item aside and move on
- Let the Product Owner consolidate all pending queries and he/she can plan to get them answered by Stakeholders before coming to the Sprint Planning of next Sprint
- I recommend having a short second Product Backlog Refinement after 2 to 3 days to check the clarifications from the Product Owner and estimate the items. This helps to save time in the next Sprint Planning
- Make sure to have at least 1 to 2 future Sprints of Product Backlog Items are always ready in the Product Backlog. Accordingly work with Product Owner and Developers to have Product Backlog Refinement
Sprint Review: The Sprint Review is to Inspect the Outcome of the Sprint which is the increment with the Stakeholders and get their feedback to improve it further. The Product Backlog will be adapted to reflect this feedback with: New Product Backlog Items, Removal of Product Backlog Items that are no longer required, Modification to the existing Product Backlog Items, Reordering of the existing Product Backlog Items. Product Owner will make sure the feedback is reflected into the Product Backlog.
As a Scrum Master, make sure the following points are taken care:
- Remind Product Owner a couple of days prior to the Review to invite the important Stakeholders
- All the participants understand the purpose of the Sprint Review
- Developers have done the increment which is meeting the Definition of Done
- Required environment (Development/Testing/Staging/PRe-production) on which the Demo happens is up and running
- Let the Developers decide who is going to give the Demo to the Stakeholders
- Run a quick demo before the Sprint Review to ensure everything works fine
- Let one person (Preferably the Product Owner) take responsibility of collecting all the feedback
- Let the discussions focus around Product increment, customer needs and their feedback
- Ensure the participants create a shared understanding among themselves about the Problem, product and value
- Let the Product Owner show the overall progress about Timelines, Budget and Risks to the Stakeholders to enhance Transparency
- At the end of the Sprint Review gently remind the Product Owner to update the Product Backlog with the feedback before the next Sprint Planning
Sprint Retrospective: The Sprint Retrospective is for the Scrum Team to inspect the processes, practices, tools, communication, collaboration, Definition of Done and find improvements in them. Retrospective is only for the Scrum Team and no outsiders will be allowed even as silent observers.
As a Scrum Master, take care of the following activities for the Retrospective to make it effective, positive and productive:
- Never miss Retrospectives
- Retrospective should be focused on “What” is the problem but not “Who” is the problem
- That means maintain high degree of psychological safety in Retrospective
- Collect the information of the Sprint such as: Sprint Goal, What items were selected into the Sprint Backlog, Out of those items which are done, Which are not done, What impediments raised during the Sprint, when they were raised, when they were closed, what was available capacity of the Developers, what was utilized capacity, a copy of Definition of Done
- Prepare a small infographic using the above information in a one or two slides of PowerPoint presentation
- Display that presentation to the Developers and Product Owner and then ask them to come up with what went well, what went wrong, what could have been done better
- Do not use the same facilitation technique to run Retrospectives. It leads to boring, ineffective and lack of involvement and make the Retrospectives very mechanical
- Use different Techniques such as 4L (Learned, Lacked, Liked, Long For), Speed Boat, Hot Air Balloon etc Techniques
- Make sure at least one or two actionable improvements are identified from the Retrospective and take the team’s commitment on implementing them
- If there are more improvements identified then use DOT voting technique (Google it if you do not know this technique) to help the Developers and Product Owner to prioritize a few of them
You will have to do all the above in a Sprint, once a Sprint is done you will have to repeat the same for the next Sprint. Keep the below points in to consideration to become a Great Scrum Master:
- Do not ever judge the people
- Do not ever criticize the capabilities of the people
- Always focus on continuous learning and improvement
- Focus on creating awareness to the Developers and Product owner
- Do not focus on just the solution but focus on root cause of the Problem
- Help people to be self managing rather than hand holding them
- Keep improving your skills through reading, conferences, meet ups and webinars
- You do not own the process, rather let the process be defined by the team and just help them to improve
- Always focus on Agile values and principles and help team to understand and practice them
- Challenge the status-quo to bring real capabilities of your team
- Understand the Scrum-antipatterns and help team understand too the consequences and encourage the team to avoid those anti-patterns
- Let your team fail occasionally and make them learn from their failure
- Instead of you take the ownership, let the team feel and take that
- Instead of solving the conflicts, help the team how to solve within themselves, when they cannot solve then facilitate the resolution
- Coach the team instead of being a consultant
Recent Posts
- Essential Metrics to Measure Scrum Team Performance 17/04/2024
- How to influence without Authority? 17/04/2024
- Impact Mapping Example 08/04/2024
- Business Agility Vs Organizational Agility Vs Enterprise Agility 08/04/2024
- Agile Vs agile vs Agility 28/03/2024
