Scrum, what it is? how’s it work? and why it's awesome?
Currently, I am a penultimate Computer Science student from the University of Indonesia. One of the mandatory courses is called Software Development Project. In this course, we are partnered with a real client and are required to develop production-ready software.
The development length is about 4 months and we are mandated to use agile methodology and scrum process.
Actually, this is the first time I experiencing the whole software development lifecycle including gathering requirements, design planning and sprint planning. Before this, I already did some internships but in those internship I just did task without involving in gathering requirements.
Without further ado, lets dive in to Agile and Scrum.
Agile Manifesto
The Agile Manifesto is values for software development that declared by software developers for intention to agile development. These developers are tired of waterfall process that so much documentation. Proponents of Agile methodologies say the four values outlined in the Agile Manifesto promote a software development process that focuses on quality by creating products that meet consumers’ needs and expectations.
Individuals and interactions over processes and tools
Starting from the problems that exist in the Waterfall Model, the first value contained in the Agile Manifesto is the emphasis that individuals and their interactions are in full control of the “steering wheel” of a project. As a result, the level of interaction and the quality of the team’s communication with the situation in the project increased. Where, this will not happen if the main “steering wheel” is still delegated to standard process tools. This value also directly makes one developer not “ignorant” with the work of other developers.
Working software over comprehensive documentation
Still processing data physically and not integrated? Imagine how much time and resources are wasted while still implementing this method. Try choosing these two options: Submit a thick pile of data for reporting to the client, or Provide a simple Infographic that already includes the entire project information. Of course the second is not it?
If you choose the first option, then you must be prepared to deal with a lengthy and lengthy process of approval and response to events. In Agile, product specifications, requirements, interface designs, and other project data can be presented in a more concise and integrated manner.
Customer collaboration over contract negotiation
Ever been stuck in a project situation that got out of hand and far from the initial contract with the client? This is called scoop creep, and it’s also what Agile wants to keep away from. Compared to running projects that stick to a standard initial contract, Agile Manifesto values flexibility and collaboration between developers and clients.
In this way, both parties will collaborate and both benefit. On the one hand, the client will achieve the realization of the project in accordance with his wishes, on the other hand the developer will be greatly helped through more detailed and clear product specifications. So, all forms of unexpected changes during the project can be discussed together.
Responding to change over following a plan
As previously mentioned. The Waterfall Model tends to be rigid and fixed in the details of the process that has been made. So, this method can be called less flexible on changes.
Meanwhile, Agile offers developers flexibility to make changes in the project. However, this does not mean that this method overrides the value of initial planning on the project. However, Agile Manifesto values more speed in responding to change. Technically, Agile uses short iterations that are responsive to changes in order to allow for adding new features to later iterations.
Agile Principle
Based on the above values known as the four agile values, 12 agile principles are further developed to concretize the framework.
The general theme is:
- Value communication and collaboration among teams.
- Focus on developing software.
- Keep delivering working software in increments.
- Keep the team motivation alive.
Scrum Process
Scrum project management is one of the most popular Agile methodologies used by project managers. In scrum, there are three actors:
- Product Owner:
Assigned to divide the product to be worked on into small parts called PBI. In addition, for each sprint the Product Owner can also determine what PBI will be carried out and if a sprint has been completed, the Product Owner will assess whether the product worked on in that sprint has passed or not. - Scrum Master:
In charge of monitoring the Development Team so that they can implement the Scrum process model properly during the working period of a product. In addition, the Scrum Master is also tasked with bridging the coordination between the Product Owner and the Development Team. - Development Team:
Tasked with implementing the product to be made in accordance with the requirements given by the Product Owner. The product submitted by the product owner must be finished in the hands of the Development team.
Scrum has a couple of artifacts:
- Product Backlog: the list of features/requirements needed to develop the complete software.
- Sprint backlog: the list of features/requirements needed to be developed in a certain sprint. In sprint backlog, we determine the story points or weight of each task.
- How do we determine the number?
Well, we determine the number based on how long the estimation of this task will be done. We gave its weight based on Fibonacci numbers 1–2–3–5–8–13. 1 point means it is easy and can be done in 1/2 man-days. 2 point mean is 1 man-day. 3 points are 2 man-days. 5 points are hard and need 4–5 man-days. 8 need about 7 man-days. Finally, 13 need more than 7 man-days. Each man-day is 8 hours work.
- Increment: a concrete stepping stone towards the goal. For example a new feature. At the end of a Sprint, the new Increment must be “Done,” by the Scrum Team’s definition of “Done”.
Scrum Pillars and Values
Scrum Pillar
- Transparency, the development process must be clearly visible to all stakeholders
- Inspection, an inspection of the whole process to existing problems
- Adaptation, to keep the development process on track according to the time and expected results
Scrum Pillar is used to building trust in all team members along with implementing the values that all team members need to uphold.
Scrum Value
- Commitment
This involves each member of the team personally committing to achieving the goals of the Scrum Team. Our team defines the team’s Sprint goals, and within this, we outline each member’s own goals and responsibilities which we are beholden to by our own self-management to complete within the time period. - Courage
In our team, each member must have the courage to do the right thing and work on difficult problems. Sometimes being transparent in your work also takes a strong dose of courage, especially when inspections often reveal mistakes or misunderstandings. - Focus
If any endeavor big or small is to succeed, then applying strong focus to each element of work is paramount. In our team, we allow members to focus on important elements in smaller portions, meaning more focus can be given to each item in the process. - Openness
When Scrum Teams and stakeholders adopt full transparency regarding the project and its associated challenges, it means everyone is literally on the same page and can progress as a single, cohesive unit. Transparency requires openness and honesty, especially when team members face work challenges in their work. In my team, we are very transparent about each other work and struggles. - Respect
Look, if we have to tell you about the importance of respect as a concept, then you have bigger issues on your hands. But within a Scrum framework, the concept of respect becomes crucial in ensuring the overall success of the project. Our members need to be able to trust and respect each other to be capable, independent people.
Scrum Events
In scrum, there is scrum events and I also explain what my team and I do in each event.
Sprint Planning
This is the event that kick starts each Sprint and is where the Product Owner and Developers discuss which Product Backlog Items (PBI’s) will be included in Sprint. Sprint planning involves the entire Scrum team: the development team, Product Owner, and Scrum Master.
In my team, we do sprint planning every Monday night every 2 week. This is where most of us, college students, have their time free from other assignment or internship activities. We did sprint using JIRA and for communication we use Discord.
Daily Scrum
Scrum seeks to efficiently use your time and resources and the Daily Scrum event is no exception. The Daily Scrum is timeboxed to 15 minutes.
In my team, we do daily scrum but not daily. We often called it “standup” that happens every 3 days. Not everyday we can update our progress because some of us need to do internship at day or doing some assignments for other class/subject.
Sprint Review
Sprint reviews focus on the product being developed, specifically on the potentially shippable product increment created during the sprint. During a sprint review, the scrum team invites stakeholders to discuss what was completed during the sprint.
In this part, my team and I present our overall progress to client from the previous sprint. The meeting should feature a live demonstration, not a report. Product Owners can verify stories meet their acceptance criteria.
Sprint Retrospective
The final event in the Sprint is the Sprint Retrospective. This is when the Scrum Team reviews what could be improved for future Sprints and how they should do it. In this part, we gather with the scrum master to review the current sprint. What will be discussed:
- What went well on this sprint
- What went wrong
- Possible improvements for the next sprint.
Whereas sprint planning focuses on product, sprint retrospective focuses on the people developing the product. This is exciting way to get to know about the projects and my teams perspective. I got to see what my teams problems and we discussed how to encounter them. We got a lot of improvement from this review that needed for the next sprint.
My team and I use easyretro for retro.
Finale
Scrum in a company/startup is a bit different when done in a course. Here, we do not work on the project every day so we adapted a bit. I know that this agile method is not easy to use but we got to try.
