When you work on a project, teams would typically follow the common template for product or service creation. First, requirements are gathered—who will need the product, what needs to be included, etc. Next, the product design is created. After the design is approved, implementation starts. Once the necessary parts are completed, it is tested for defects. Once all tests are passed, the product is finally deployed. Maintenance would usually follow.
For small project the above process would work out fine. However, majority of applications being developed at the moment are far from small. It is not uncommon that along the way, problems arise. For example, after months of development and during the testing phase, a critical issue appears that affects a large part of the product. Thus, a design overhaul and further requirements are needed. Thus, the process is back to step one and after some month, a product is yet to be delivered.
It is due to similar issues that alternative approaches to project management are being established. In one of these approaches, a deliverable is expected at short intervals. Instead of waiting for months until the whole product is deployed, deliverable components undergo the whole process, from design to testing, in just a short period. This gives some room for flexibility when changes, whether expected or unexpected, occur. For example, there is room for changes in requirements for features that are yet to be developed. All these are being handled by self-organizing and cross-functional teams. This is the agile way of handling product development. Agile development itself has multiple variants. One of these is the Scrum methodology. Rugby enthusiasts may know scrum as a play where strong players work together at the start of the play to get the ball. In a similar manner, under scrum, team members work together to achieve the team goals.
There are a few roles to take up in Scrum. People who are interested in the product being developed are referred to as the stakeholders. A Scrum Master would ensure the values, practices, and rules of scrum are being followed. A Product Owner is the primary person who communicates with the stakeholders and takes care of documenting their needs. Finally, the scrum team, which would be composed of 5 to 9 members, would be given full authority to do whatever it thinks will help them succeed in completing the product.
Among the characteristics of scrum is transparency which is demonstrated in several activities and documents being made throughout the process. The Product owner takes care of the Product backlog which contains the desired features or functions that the stakeholders want. The product backlog is dynamic in that it is regularly updated depending on the requirements for the product. The product backlog is made visible to the scrum team for them to pick up items that can be included in the sprint.
A sprint is essentially a time period for a product iteration to be delivered. Scrum coaches suggests a sprint lasting for one to two weeks. The team agrees on a list of criteria to be fulfilled for the planned deliverable to be considered as done. This called a definition of done.
The items taken up during this period are documented in the Sprint Backlog, which are selected items in the Product Backlog that are broken down to smaller tasks. During a sprint planning meeting, the team gives an estimate on how much time or effort each tasks need before they are completed. Throughout the sprint, estimates are plotted against the actual effort on a burndown chart to gauge the velocity of the team in completing the product increment.
Every day during the sprint a Daily Scrum is conducted which is essentially a short meeting, usually lasting for 15 minutes where members of the team indicate what they are able to do in the previous day and what they intend to do for the day. Furthermore, it is in this meeting that they raise any impediments they encounter in their tasks. The Scrum Master assists in eliminating these impediments.
It should be noted that under scrum, the team is shielded away from the external influences. Any propositions from the stakeholders do not have to go directly to a member of the team but instead should reach only the product owner who in turn updates the product backlog to accommodate this requests.
At the end of the sprint, a sprint review is conducted where the team conducts a meeting with the stakeholders. The product increment is presented to the stakeholders who in turn assess it. In this meeting the team informs the stakeholders its experience in creating the product increment. The stakeholders then make a decision on the next steps to do.
Aside from having the sprint review, the team also makes an internal meeting to discuss among themselves ways on how to improve the processes. Called a sprint retrospective, this meeting should expose the things that the team should stop doing, those that they should continue, and processes that they think can improve their way of work. Scrum is characterized by inspection and adaptations. Through activities in the sprint such as daily scrum and sprint retrospective, information can be gathered and based on it, the team makes necessary adaptations, such as adjustments or improvements to the processes.
Like any other project management methodologies, Scrum can be applied in various situations, not just in software development. However, it also has its share of drawbacks. Inaccurate estimates during planning can lead to fewer items delivered than expected. Too much flexibility can cause uncontrollable changes in the agreed-on scope of the project.
It may take time, perhaps a few sprints, for a team to fully reap the benefits of scrum. While scrum may not be perfect, its advantages over traditional methods far outweighs its disadvantages.