It's Thanksgiving month! Time to show our gratitude and be thankful. Don't you think we should be thankful for the new ways of working and how they are supporting our end-to-end deliveries? The world is going through a crisis with the Covid pandemic, yet human resources across the world are working from home/makeshift offices and making occasional office visits, while delivering quality solutions and collaborating with people across borders to work as a team. This is a true example of being Agile and adapting to the new environment. Organizations that had already adopted the Agile route pre-pandemic found it easier to transition to the new normal. While those that have not yet gone the Agile way have realized the shortcomings of the traditional ways of working, that prevent them from quickly adapting to changing market scenarios and competition. It is evident that going Agile is the only way that organizations can cope with the future and ensure that business outcomes are met.
A quick overview of what is Scrum and its roles
According to the “14th Annual State of Agile Report”, Scrum stands head and shoulders above other Agile Methodologies. The reasons are obvious. Scrum is a simple and lightweight model that instills values needed to deliver solutions that work. There are multiple definitions around it but all of them narrow down to its being easy and lightweight, helping the team to work together and deliver quality products.
As stated by Scrum.org “Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value”. Scrum has been co-created by Ken Schwaber and Jeff Sutherland, who have recently launched a new version of the Scrum Guide 2020.
"Scrum is not a methodology. Scrum implements the scientific method of empiricism" – Scrum.org.
‘Scrum’ is a term often used in the sport of Rugby where teams learn through their experiences, collaboratively work on the solution, and retrospect on continuous improvement. Often, Scrum is equated to Agile, but there is a subtle difference between the two. Agile is a mindset while Scrum is a framework under the Agile umbrella.
3 Pillars of Scrum
The magic ingredients that make Scrum popular are the pillars that hold the values, pave the way for teamwork, and allow the team to check and readjust to the pace. The foundation of scrum is based on empiricism which emphasizes that knowledge comes through experience and with the decision-making capabilities of a team. The three pillars of scrum are Transparency, Inspection, and Adaption.
- Transparency - Scrum is more about making things visible to all people involved. It starts with the vision and ends with the deliverables. Each individual is responsible for making things visible loud and clear with no gap in the communication of the information or the content.
- Inspection - Everyone involved in the scrum process needs to inspect the scrum artifacts, namely, the product backlog, sprint backlog, team board, etc. to check if they are aligned with the Sprint goal, and to check whether the Sprint goal is itself in line with the vision.
- Adaption - With inspection, if the team finds any deviation in the plan, or if during the inspection they feel they need to change the way they work, they can come up with new ways to adapt. While this is usually done in the retrospective meeting, the best practice is to inspect and adapt as and when required.
- Scrum Master - The Scrum master is the servant leader for the team who shields the team from outer interferences. He or she is a go-to person who is always ready to support and guide the scrum team with best practices, supports the product owner through coaching on handling and creating a healthy backlog. Scrum Masters are the gatekeepers of the process and if required, they can suggest the best approach for better implementation of Agile.
- The development team - This is a self-organized, cross-functional team that generates the deliverables for the stakeholder, based on the requirements received and discussed with the product owner. They come up with ideas to improve the quality and keep their skills upgraded as needed by the project.
- Product Owner - The product owner is a member of an agile team responsible for creating the backlog, helping the teams with the right understanding of the requirement. He or she also ensures that a quality product gets delivered to the stakeholders.
Who attends Scrum Events?
Scrum events are an important part of the process. These events or meetings define the way forward, help the team to pause, reflect, and re-adjust the course of action. Scrum events are attended by the development team, the scrum master, and the product owner. Optionally the management and stakeholders can join as observers. In the Sprint demo/review, the management and stakeholders are active participants, and they engage in conversations and also provide clarity and feedback on the deliverables. This grid represents the participation across the roles:
|Role||Sprint Planning||Daily Scrum||Sprint Review||Sprint Retrospective|
|Scrum Master||Yes||Optional Yes(but usually always there)||Yes||Yes|
|Stakeholders (SMEs, management, clients,etc)||Optional||Optional||Yes||No|
What are the four Scrum events?
Let's drive through each scrum event and discuss every minute detail that can help in running an effective meeting. It is important to understand the purpose of each meeting, why it is done, what is the benefit, the time-frames, and the best practices around each scrum event.
The sprint planning meeting is attended by the development team, the scrum master, and the product owner. These roles are mandatory for an effective sprint planning meeting. Anyone apart from these roles can join the meeting as an observer or speak whenever asked to. It is good to have SMEs in the meeting while planning.
The sprint planning meeting is the first thing that happens at the start of a new Sprint and it is time-boxed to eight-hours for Sprints that take a month. But for many teams that do two-week sprints, two hours is sufficient. To be able to do sprint planning in a limited amount of time, it is important to organize refinement well.
Sprint planning generates the road map and the goal for the entire Sprint. Being the first activity in the Sprint, the team comes together and pulls the highest priority item from the product backlog, clarifies any doubts, and adds them to the Sprint backlog. The idea is to come up with a Sprint goal that is in agreement with the product owner and create a doable list of work items commonly known as Sprint backlog. The meeting is facilitated by the scrum master who makes sure the team focuses on the deliverables of the meeting and the intended outcome is met. If there is any disagreement among the team or with the product owner, the Scrum master can use conflict resolution techniques to resolve deadlocks. The Scrum master also keeps the time in check and helps the team to follow the time box. The Product Owner is responsible for keeping the Product Backlog ready for discussion before Sprint Planning commences. This implies adding acceptance criteria, refining requirements, and essential details for the development team to precisely estimate the effort.
- Ensure that backlog items are sufficiently refined before Sprint planning starts. Part of refinement is estimating the size of backlog items, adding details and splitting large items into smaller ones.
- Any backlog item which requires a lot of clarification and discussion, should not be a part of sprint planning. It also means the story is not ‘Ready’.
- While planning the sprint, the team should take into account any leave, holidays, or other activities that can impact the sprint commitments.
- Breakdown of tasks should be done in sprint planning.
Daily Scrum (Daily Standup)
The daily scrum is attended by the development team, the scrum master, and the product owner. For mature agile teams, the scrum master can become optional sometimes.
The daily scrum meeting occurs every day, same time, same place for no more than 15 minutes.
The daily stand-up meeting allows the scrum team to discuss the current state. It is the time to inspect if the team is moving towards a Sprint goal or if there's any need to recourse the action. As the name suggests, it is a daily meeting which is ideally done while standing to make it quick. A common way of conducting a daily Scrum is to let each member answers 3 questions:
- What I did yesterday?
- What is the plan for today?
- Are there any impediments?
The meeting is facilitated by the scrum master and is done while looking at the task board or the Sprint board for better transparency and visibility of the current state. This meeting should not be treated as a status meeting but as an opportunity to inspect and adapt on a daily basis. Everyone in the team gets a chance to talk about their deliverables and challenges while respecting the other’s view.A common agreement in teams is that only one person speaks at a time.
- Timeboxing is key to the event, the Scrum Master should keep track of the time.
- The focus should not be on finding the resolutions, any issue should be taken care of in the ‘sidebar’
- It should happen at the same time and same place.
- Focus ONLY on what is relevant to achieve the Sprint Goal as a team.
The complete Scrum Team attends the sprint review along with stakeholders such as end-users, customers, management and other associated verticals (marketing, sales, support). It is important that the most relevant stakeholders are requested to attend and give their feedback, as varied feedback is vital for producing brilliant products. The Product Owner and Scrum Master should sync up prior to the meeting to discuss who needs to be involved to ensure that everyone is informed in advance.
Sprint Review happens at the end of every sprint. In addition to sprint reviews, it is often a good idea to get more frequent feedback from stakeholders during sprints instead of only at the end. The duration of sprint reviews is at most three hours for a sprint of a month. But for many teams that do two-week sprints, one hour is sufficient.
Sprint Review is the time where the development team showcases their efforts put to convert the raw requirement into something useful for the client. Stakeholders get a demonstration of the developed requirements as requested by them; they provide their feedback after looking at the deliverables which help to improve the product. Whatever the team presents in the sprint review meeting should meet the ‘Definition of Done’ as agreed between both – the development team and the stakeholders. The focus of the sprint review should be more on value delivery rather than points delivery. This, again, gives a platform to the team to inspect and adapt to create better solutions.
- The meeting should have a clearly defined agenda as to what the stakeholders should expect.
- The most valuable feedback should be added to the product backlog and prioritized by the Product Owner.
- Timeboxing is critical while involving the stakeholders.
- A dry run before the actual sprint review helps to build confidence.
The sprint retrospective is attended only by the scrum team which consists of the scrum master, the development team, and the product owner.
This is the last event of any Sprint and happens on the last day of the Sprint. The duration of the Sprint review typically ranges between one hour or two hours for a Sprint of two weeks.
The sprint retrospective is a time to reflect and introspect/retrospect on what went well, what didn't and how it can be improved for future sprints. The focus is on inspection and creating a course of action, for better Sprints moving forward. This event helps the team voice out their concerns, their appreciations or any improvements they want to see. The scrum master creates a safe environment to help the team come up with points they like or dislike and tries to create a neutral situation. The feedback from the team is collected and the action items are derived from the owners associated with each of them. At times the team might come up with a long list, in such cases, the Scrum Master should help the team prioritize and narrow down the few high-priority actionable items. The focus of the retrospective should not be always on the product but also on the process and inter-team relationships.
- The meeting should initiate on a lighter note with some ice-breakers to help the team adjust to the temperature of the room
- Trying out theme helps as it generates new ideas and makes non-vocal people speak up their minds.
- The scrum master should try ways to callout the fact that conflicts are not always bad. Quite often, some team members hold up their opinion due to fear of conflicts.
- Starting the meeting with previous action items builds trust in the process as they are being heard.
Scrum events, if done in the right spirit, create an empirical behavior amongst teams. The Scrum master should make sure that the team understands the why, what and how of each event. These events also help to create a flow of communication and provide transparency at every level. Please share your ideas and your experiences working with agile teams around the scrum events.