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.
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.
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.
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|
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.
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:
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.
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 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.
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.
Your email address will not be published. Required fields are marked *