Introduction
In my opinion, Agile is not a methodology, Scrum is, and people often interchangeably use these two.
What I mean is Agile isn't a modular framework that magically solves all the problems of software development.
It's a collection of frameworks designed to be focused on the preparation of the development activities. It was also good news for HRs around the world because Agile is kind of a team-building activity.
Genesis
In the year 2001, 17 individuals drafted a Manifesto known as the Agile Manifesto. After brainstorming they established the term Agile to represent all frameworks such as Scrum, Test Driven Development, Extreme Programming, etc. Out of all these frameworks Scrum was highly efficient and quickly adapted by the software industry and now it’s the most famous framework of the entire Agile family.
The Team
The team is built upon 3 roles.
- The Scrum Master
- Product Owner (PO for short)
- The Development Team
The Scrum Master
First thing first, "SCRUM MASTER IS NOT A PROJECT MANAGER." Scrum Master is responsible for managing the scrum process not the team nor the product.
- Scrum Master work with the Product Owner to supervise the backlog
- Scrum Master ensures that the development team is not overwhelmed but also makes sure the development team perform to their best while maintaining the quality
- Scrum Master know which backlog item team is working on, he follows the progress of their work ensuring the team is focused on the task at hand
- The rule of thumb is "DO NOT OVER-COMMIT", it against the laws of Agile.
Product Owner
PO is the person who knows the business requirements. PO knows the product in and out. What is the purpose of the product, why the business is choosing the product, what are its shortcomings/feasibilities, what is our future growth, and what is market value/ competition for the product?
- The development team communicates with PO to solve their doubts.
- The features or bug fixes the development team is going to work on is set by PO in the form of PBI (Product Backlog Item)
- The Product Owner is responsible for managing the backlog. If PO doesn't understand any technical work, he can delegate the responsibility for such PBIs to the development team. But still, be accountable for PBI.
- The Product Owner's decision related to the product is final.
- PO can terminate the sprint, which rarely happens but cannot deny the possibility. If management decides to shut down the product and ask the team to work on a new product to attack new customers, then PO can take the decision to terminate the sprint.
The Development Team
Development Team is a broader term, it is not only consisting of software developers, but it is a group of individuals who has the right skillset to work on backlog. So, QA, Technical writers, developers all can work collaboratively on the product.
- Team Size must be between 3 - 9. Less than 3 team members have been proven to be ineffective, that’s why it is recommended to have at least 3 people on a development team.
- The development team can communicate with each other and assist each other with technical work.
- Every member of the team can bring something to the table, and they should be flexible enough to do whatever it takes to finish the assigned backlog. And take the product to its next successful increment.
The Scrum
Remember these 2 names "Jeff Sutherland" and "Ken Schwaber".
Jeff Sutherland originated the first-ever scrum project in 1993 and later in 1995, with Ken Schwaber, they developed a Scrum as a formal process.
Scrum consists of 5 activities,
- Sprint Planning
- Daily Scrum
- Product Backlog Refinement
- Sprint Review
- Sprint Retrospective
These 5 activities are designed to support Transparency, Inspection, and Adaption.
Transparency
Everyone who is part of the scrum must know the progress of software increment, what are impediments, challenges, etc. Another side of transparency is the concept of DOD: Definition of Done.
- Definition of Done. (DoD)
- For developers finishing the development of a feature is a definition of done. Let's throw Unit testing in there for sake of testing.
- For QA making sure the feature is working and has no regression is the definition of done. (Regression testing, Integration, performance testing)
- For Product Owner checking whether the feature is ready for market is the definition of done.
Now when you combine all these three aspects and take sentiments of all the 3 roles into account you get the Definition of Done for the feature.
Inspection
Making sure the team is keeping up with the progress to deliver successful software increment.
Adaption
The backlogs or processes might have to change to meet the expectations. The team should be ready to adapt to the changes.
The Sprint
- Sprint should only last for a month or less.
- 2 weeks sprints are very common in the industry.
- With every sprint, the team is expected to produce the next shipment of product improvement.
1. Sprint Planning
- There should be at least one sprint planning meeting per sprint.
- The duration of each sprint planning meeting could be anywhere between 1 - 8 hours. Depends on the length of the sprint.
- The Purpose of Sprint Planning?
- Prioritize backlog items.
- The Backlog is the number of tasks created by the Product Owner which will be assigned to the development team. There could be hundreds of tasks in the list of backlogs but the team can prioritize the tasks as per business needs.
- Let's understand this with the following scenario, Consider there are 2 backlogs.
- Migrating project from .NET framework 4.7.1 to .NET 5 (this has no direct impact on the customer)
- Adding Pie chart to the dashboard which customer is asking.
- Tip: In such a scenario always take the feature first, because we never know it might need redoing after migration to .NET 5, so always avoid a rework.
- Selecting PBIs (Product Backlog Items) to work on in this sprint and defining the goal of the sprint.
- The development team and product owner brainstorm on the backlog items. Then they select few items from the list of PBIs to work on for the current sprint.
- Defining Velocity.
- It is a unit to measure the efforts of the task. Each story will be assigned with a velocity number and this number varies from story to story depends on the complexity of the underlying task.
- Breaking down big and complex tasks into subtasks. Making sure each task should take a day or 2 to finish.
2. Daily Scrum
In the name it says daily scrum, you might have figured out its frequency. Yes, Scrum takes place every working day. Every day for 15 mins max. It is also known as a stand-up, as the name suggests STAND-UP means the team is not allowed to sit and be comfortable. The team has to give updates by attending the meeting standing up. (You can always sit and relax lol, Get your own chair if they don't provide one.)
- Each team member has to share their status on the tasks/story they're working on.
- The Purpose of Sprint Planning?
- Each team member has to answer the following 3 questions with respect to Sprint Goal.
- What did I do yesterday?
- What will I do today?
- What impediments do I have that are blocking me?
3. Backlog Refinement
The Product Owner knows the product and he conducts this meeting once per Sprint, usually, this meeting takes place somewhere in the mid of the sprint to track the team's progress with respect to the product requirements. Duration for this meeting can vary from 1- 5 hours depends on the sprint's duration and velocity.
- The Purpose of Sprint Planning?
- Product Owner maintains their backlogs and in this meeting development team and Product Owner brainstorm to pick PBIs for the next sprint.
- Let's understand one of the situations of such meetings.
- Product Owner has a business requirement and creates a story that is quite extensive in nature, can easily take up to a week to finish. The week to finish one backlog is the problem here, as we discussed earlier it is against the laws of agile to have such big stories. Here, the Product Owner starts the discussion by explaining the business needs then the development teams add the technical angle to it. The development team is suggesting dividing the one task into sub-tasks where each task could take a day or two to finish. For example: If the PBI is to add 4 new charts to the existing sales report dashboard. Let's say we have a donut, column, line, and trend chart that needs to be added to the dashboard. If you look from the technical perspective there are UI changes that come under the Presentation layer then fetching, filtering, and modifying the data so dealing with the Data Access Layer, then there's testing for both data and UI ensuring existing system, performance and data is intact. Then there's the documentation for users. Now all this work will take up to 5 days as per the dev team considering the complexity of the story. Hereafter a healthy brainstorming team can suggest the following subtasks.
- Sale Report Dashboard: UI Changes (6 hrs.)
- Sale Report Dashboard: DB activities (6 hrs.)
- Sale Report Dashboard: Testing (6 hrs.)
- Sale Report Dashboard: Documentation (2 hrs.)
4. Sprint Review
One of the most important events of the scrum is Sprint Review.
In this meeting, the team usually discusses the overall progress on the product increment. The team discusses the different story points, sub-tasks, challenges, extra efforts, etc.
- Everybody who was affected by the sprint could join the meeting including stakeholders. A stakeholder might raise the questions with their concerns and suggestions.
- For example. If the team has achieved the goal, then the team can demonstrate the same with a demo or presentation. If a team has failed to achieve the estimated goal for the sprint, then stakeholders could ask for an explanation.
- After concluding the current sprint, the Product Owner could show the next set of backlogs that the team is going to work on in the next sprint.
- The advantage of this meeting is getting insights from the business side, such as what customers are asking? What stories do we need to prioritize? What new stories do we need to add to the backlog? How the budget is concerned with the number of backlogs? Do we need more resources? etc.
- Duration of Sprint Review could vary from product to product, the duration of such meetings could be between 1 - 4 hours.
- The product owner finally orders the backlog based on the discussion with the development team and stakeholders.
5. last but not least: The Retrospective
We are pretty much done with scrum by now. This event is focused on tracking the progress of the team than the product. The Scrum Master, Product Owner, and the development team analyze the performance of the scrum by learning different charts.
- Burndown chart - used to Track Sprint's Progress, Velocity, etc.
- Burnup chart - This shows how the team is progressing through overall sprints. This chart helps to forecast the goals for the team.
The Retrospective can give a broader perspective on the following points.
- What changes can be done to make the sprint's outcome more efficient?
- To understand if the team is not overwhelmed. Understanding teamwork.
- Do we need extra resources?
- Was the sprint successful then how to keep up the same speed?
- Was sprint goal not achieved then understanding the root cause for the same.
Bonus Point
One last thing I would love to cover is the sitting arrangement of the development team. It is important because It's crucial for a team to collaborate and communicate and this shouldn't be affected by putting walls in between them.
Having open, relaxing office space for the development team to work is highly recommended. All top tech companies follow the idea of open working space for the development team for a reason.
If the team have BAs and technical writers whose job is to communicate with client and customers plus their role does not need to be involved in every technical discussion, then such team members can be collocated in an isolated environment where they can focus. Allowing team members to choose their own workspace which is ideal for their personality will result in their own and eventually team's success. Even though the team is isolated they can still be connected via daily standups, shared projects, shared documents, workspace, etc. And it is indeed possible, ever since the pandemic in 2020 we have seen how companies have molded their teams to work with this distributed working model and it turns out to be more productive as the study reveals.
Conclusion
Following all these practices can take you closer to the goal of delivering a successful product in the market. And helps an organization to shape the team.
If I have missed anything, be sure to add it. If I have mistaken anything do mention it in the comments. Critics are welcomed.
Thank you all for taking the time out to read the article, I hope this article finds you well and gives you some understanding of the Agile Methodology.
Cheers!