Agile and Scrum are the new buzz words these days. What’s so special about them that it has been adopted not only in the IT industry but also in other industries? Scrum focuses on making teams cross-functional and self-organized. It empowers them to deliver their best by following an iterative approach.
Let’s get to know about this framework in detail. The design of the course is such that it will help you clear Professional Scrum Master I (PSM I) and Certified Scrum Master (CSM) exams. It will also help in giving you a solid foundation if you are preparing for the Professional Scrum Developer or Professional Scrum Product Owner exams.
We will discuss the below topics in this article.
- What is Scrum?
- It’s History
- Uses of Scrum
- Scrum Theory
- Transparency
- Inspection
- Adaption
What is Scrum?
It is an Agile framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Well, that’s the official definition of Scrum! Let’s break it down into simple terms.
Scrum is an agile framework. We have other frameworks like Extreme Programming, Kanban, etc., but Scrum remains by far the most popular framework. It works on the philosophy that no matter how complex the problem you got, it can always be broken down into easily manageable smaller chunks. When we manage smaller pieces of work, we have better control, and we can deliver products incrementally with better quality. The essence of the Scrum has a smaller team that is highly flexible and adaptive.
The three qualities of Scrum are :
- Lightweight: A lightweight methodology is a software development method that has only a few rules and practices, or only ones that are easy to follow. The official guide that details out Scrum is only 19 pages !! There are very few terms and concepts outlined, and rest can be adapted based on the industry and needs of the project.
- Simple: Scrum is not a process, technique, or definitive method. It is only a framework that gives you broad guidelines, and you are free to use techniques that work best for your project/industry. The guidelines that Scrum prescribes are few and easy to follow. If you have heard of other project management methodologies like PMP, you will realize that it takes months to know all the terminology.
- Difficult to Master: Well, if the Scrum is lightweight and simple, how come it’s difficult to master? The best analogy is a chess game. If you have ever played that, you will realize that there are only six types of pieces (King, Queen, Rooks, Bishop, Knight, and Pawn). If you spend a day, you will quickly learn how these pieces work. However, people spend years mastering chess. Similarly, if you study the Scrum guide for a day, you will get all the concepts. However, it takes years and experience to master it.
History:
It was born out of the manufacturing industry in the 1980s and subsequently extended by the software development industry as an agile methodology that can replace the waterfall method. Ken Schwaber and Jeff Sutherland formally came up with Scrum in 1995. In 2001 Ken, Jeff, and other leaders got together and came up with an Agile Manifesto that outlined broad guidelines for Agile methodology. Ken and Jeff published the first Scrum Guide in 2010.
Uses of Scrum:
Initially, the development of Scrum happened for managing and developing products. Later, it was used to achieve “Any Complex work” that required completion. At a high-level, it is used for
- Research and identify viable markets, technologies, and product capabilities. If we need to develop a large e-commerce website, the first step is always to identify the product features, perform market research, and identify the right technologies. This work can also execute in the Scrum framework.
- Develop Products and Enhancements. It is the most common usage of Scrum. A lot of companies are using it for their development process, and Scrum, by far, remains the popular choice.
- Release products and enhancements, as frequently as many times per day. It’s a recent addition to the latest Scrum guide. Earlier, it prescribed that a shippable product’s deployment can only happen after the iteration ends. However, with the advent of Cloud and continuous integration, you are free to release an increment as frequently as you want.
- Develop and sustain Cloud and other environments for product use. We use it for any infrastructure requirement needed for developing a product.
- Sustain and renew products. Identification & development of a product that requires a new strategy to stay relevant in the market can also happen using Scrum.
We use the Scrum framework to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations, and almost everything we use in our daily lives as individuals and societies.
Scrum Theory:
Scrum works on empirical process control theory or empiricism. What is Empirical? The dictionary meaning of empirical is something that has a basis on experience rather than theory or pure logic. So how does Scrum ensures empiricism? Its foundation is three pillars – Transparency, Inspection, and Adaptation. Let’s discuss these in detail.
Transparency:
What is transparency? We often see in projects that some issues are not shared with the client and kept internal until they resolve. The perception is that this helps in keeping the “noise” down and let the development team focus on work. Scrum doesn’t believe in that. It advocates that we need to be transparent with Scrum teams, and all the stakeholders who are impacted by the outcome (E.g., CEO, Business Stakeholders, etc.)
So how do we ensure we are transparent? Well, transparency needs to be in everything we do in Scrum – Let’s discuss it.
Transparency with Team:
Scrum advocates that we need to have clarity within and outside the team. It helps all the stakeholders to be on the same page. How do we achieve this?
- Frequent Feedback – Scrum teams should be transparent to take regular feedback about their work. It could be done via Sprint demo so if there are any gaps it can be addressed quickly with product owners and business stakeholders
- Work Progress Visibility – The Scrum team should be transparent on their work progress. One can soon achieve this via burn down charts and other reports. It helps all the stakeholders to have a clear idea of the growth and any expected delays.
- Common Definition of Done – We will discuss “Done” definition in later articles, but at a high level, the scrum team should be clear on when they can call a piece of work as complete. This definition and understanding should be standard across all the stakeholders. E.g., A developer created a login page and detected two minor defects in testing. Is the work complete as there are no significant defects, or is it considered complete when these two minor defects also get fixed? This clarity helps everyone to be on the same page on progress.
Transparency in Events:
Scrum prescribes some events as part of a Sprint. We will discuss these concepts in later articles. But at a high level, there is a Sprint planning meeting at the start of Sprint where the team plans what story needs to be done in a Sprint. There is a daily 15 min Scrum meeting with a team where the team discusses progress. At the end of Sprint, there is a Retrospective meeting where the team discusses what went well and what are the improvement areas.
We need to have transparency in these events. So the team needs to be transparent and bring any issues immediately in Scrum meetings so that there is no impact on the work. The team should also be transparent to document retrospective meetings, so any improvement areas are documented and implemented.
Transparency in Artifacts:
Scrum defines some artifacts like Product Backlog, Sprint backlog, etc. We will study these in detail in later articles – but let’s discuss the concept here. As we know that Scrum is iterative; therefore, we take a large chunk of work and break it down to smaller pieces. The work we are going to do in the next three weeks (Sprint) is called Sprint backlog. It needs to be visible to everyone, so all the stakeholders know what they can expect once the Sprint is over.
Inspection
The success of Scrum depends on how successfully we complete the Sprint goals. It requires that we inspect our Sprint artifacts and ensure that anything which can impact the Sprint goals is addressed. While anybody can do the inspection, usually Scrum Master, Product Owner, or a senior member of the Scrum team performs the inspection.
Inspections can be done by using Scrum board – E.g., A story that was estimated to be done in 2 days is taking more time. Inspection can also be done by product owners to ensure that the stories are delivered as per his/her expectations/requirements. A senior member of the team can review the code to ensure that the developed product is robust.
How often should we do the Inspection? Frequent enough to ensure that any issue is caught quickly, but also ensure that it doesn’t hamper day to day productivity of team members.
Adaptation
Once we finish the inspection, what do we do with the inspection outcome? Well, we need to adapt and make adjustments to ensure that our Sprint goals are not impacted.
How soon we need to adapt? As soon as possible. It could be the next day, within Sprint, or even next Sprint. It depends on the problem we are trying to solve. E.g., If a team member has inspected the code and commented that best practices are not being followed, it could be taken within the Same Sprint (assuming enough time left). Otherwise, it can also execute in the next Sprint. If a Product owner has found a defect in a story, then one can fix it as soon as the next day itself.
Scrum provides four formal events for inspection and adaptation.
- Sprint Planning – Meeting to plan what needs to be done in a Sprint
- Daily Scrum – Meeting to check the progress and find if there are any issues
- Sprint Review – Meeting at the end of Sprint to make any adjustments to the next Sprint objectives
- Sprint Retrospective – Meeting to find out what went well and what can be improved in the next Sprints.
We will discuss these events in detail in later topics, but remember that Inspection and Adaptation go hand in hand. Moreover, this ensures that the recognition of these issues happens soon enough, and we take steps to address them.
