PPL 2021 — Scrum Framework — Beautifully Incomplete

Software development is not a rational process. It’s a process made by people with feelings with bodies and with thinking. And by putting all those together I can be a more effective software developer. Kent Beck.

Photo by Leon on Unsplash

This article was made as a part of Individual Review of PPL 2021

When we are talking about the Software Development Life Cycle (SDLC), there are so many frameworks that we can choose. One of the famous models or methodology that is used quite a lot is the Agile Model. Agile itself has quite many frameworks in it. For this article, we will exclusively talk about Agile Software Development using Scrum Framework.

Brief Introduction to Agile Software Development

According to Oxford Dictionary, agile means the ability to move quickly and easily. In Software Development, the agile principle in software development means that the development has a quick and adaptive response to change. Like some method, agile has some principle and manifesto that make it different from prescriptive models.

Principles of agile methods:

• Customer Involvement
• Incremental Delivery
• People, not process
• Embrace changes
• Maintain simplicity.

Manifesto for Agile Software Development:

• Individuals and interaction over processes and tools: In Agile developments communication between the developer team and stakeholder is more important than the processes and tools used in the development stage.
• Working software over comprehensive documentation: When using agile working software that can be used is far more important than any documentation that we may usually find on prescriptive methods.
• Customer collaboration over contract negotiation: Just like the name suggests, the agile method encourages the customer (or stakeholder) to collaborate more with the developer team rather than a long negotiation over the contract at the beginning.
• Responding to change over following a plan: Agile processes prioritize a change in the middle of the development cycle rather than rigidly follow a plan from the beginning.

Now that we know what agile is, we can start our journey to understanding how the scrum framework implemented using principles and manifesto that can be found on agile methodology.

Brief Introduction to Scrum

Much like a rugby team (where it gets its name) training for the big game, scrum encourages teams to learn through experiences, self-organize while working on a problem, and reflect on their wins and losses to continuously improve.

Scrum is a simple framework in which the process and step are ever-evolving. According to Scrum Guide, the scrum framework is purposefully incomplete as scrum methodology will vary and ever-evolving between the team that uses it. But there is indeed some guide or ‘rules’ to follow to ensure that Scrum can have the maximum result that the team expected.

Scrum Team

Scrum team is a fundamental unit of scrum that consist of a small team of people. A scrum team must be small enough to be agile and large enough to get the job done on that Sprint (will be explained later). Usually, a scrum team is no smaller than three people and larger than ten people. According to Scrum Guide, if the team is too large, it is recommended to breakdown that team into two or more separate teams working on the same product. Each scrum team member is held responsible for their work and must have good communication to maintain a reasonable and clear understanding of Sprint Backlog.

Scrum team is divided into three roles, and there are Scrum Master, Product Owner, and Developer team. Below we will discuss each role responsibility.

Developer Team

When we heard about a developer, usually, what we were thinking about is the software engineer. But as the Scrum Framework is not tied to Information Technology, developer means that every team member that committed to any aspect of a usable increment each sprint. The developer team has primary three responsibilities and there are:

• Creating a plan for the Sprint, or the Sprint Backlog (each features increment that needs to be done each Sprint)
• Make a product that meets all the requirement in the Definition of Done.
• Plan their daily activity to reach the Sprint Goal each Sprint.

Product Owner

Product Owner has almost the same role as the Product Management we found on so many corporations. The slight difference is that ideally, the product owner only handles a small number of a team rather than a division which usually Product Management handle. Product Owner also has some responsibilities, and there are :

• Making and designing each Product Backlog Item (in short PBI, or increment that need to be done each sprint)
• Make sure that the Product Backlog Item is apparent all team member understood
• Make sure that all the Product Backlog Item for that sprint is feasible to be done within the sprint period.

Scrum Master

Scrum Master are a true leader who serves the ScrumTeam and organisation. Ideally, the Scrum Master should server the Product Owner, Developer Team, and the Stakeholder or Organization.

Scrum Master serves the Developer Team as follows:

• Coaching each member in self-management and cross-functionality.
• Helping the team to meet high-value increments in the Definition of Done(in which the feature is called done if fulfil each requirement in Definition of Done)
• Ensuring each team member have no obstacle and can work as efficiently as possible so that each sprint can be made successfully.

Scrum Master serves the Product Owner as follow:

• Helping the product owner to find effective planning for every Product Backlog Items each Sprint.
• Facilitating the stakeholder for any requirements change to the Scrum Team.

Scrum Master serves the Organisation as follow:

• Help the organisation to understand and implement an exemplary Scrum implementation.
• Ensuring that there is no barrier between the Scrum Team and the Organisation.

Scrum Activities

Sprint

In the previous section, I’ve mentioned a lot of time about the sprint. As promised, I will talk about sprint in this section as best as I could.

According to Scrum Guide, Sprint is the heartbeat of every Scrum Team. A sprint is a fixed-length event usually less than one month when in this period, the Scrum team must turn ideas into value or working product. Sprint is a repetitive activity, where every time the current sprint ends, it continues to the next sprint until every product desired by the Stakeholder or Organisation is wholly fulfilled. There are some adhered rules during Sprint to make sure that the Sprint Goal will be fulfilled:

• There must be no change that would endanger the Sprint Goal, even though Agile is not a fixed methodology like a waterfall, but during Sprint Product Owner and Scrum Master need to make sure that there would be no significant change in Product Backlog Item that can make the team failed to reach the Sprint Goal.
• Product Backlog Item can be refined as needed.
• The scope of the project may be negotiated as the team learn more.

Sprint Planning

Before the sprint start, every team should do sprint planning, where the Product Owner will make a new Product Backlog Item along with the Scrum Master, where then the developer team will fulfil.

According to the Scrum Guide, three questions need to be addressed every Sprint Planning:

• Why is this Sprint Valuable?
• What can be done in this Sprint?
• How will the chosen work get done?

Daily Scrum

Daily Scrum is a meeting that held every workday with a duration of about ten to fifteen minutes. To ensure that the Daily Scrum can be performed efficiently, it is advisable to schedule the Daily Scrum in the same place and place every day. The main thing that needs to communicate during Daily Scrum are:

• What has each team done?
• Is there any blocker to perform the Sprint?
• What will each member do next?

Sprint Review

Sprint review usually performed once every sprint. In the Sprint Review, the Scrum Team will show the increment done during the sprint to the stakeholder. The purpose of the Sprint Review usually will help the stakeholder know if there is something that could be improved in the next sprint, or if the Product Backlog Item for the next sprint need some adjustment, as we know that it is advised that there should be no significant change during the sprint that could shift the Sprint Goal.

Sprint Restropective

Sprint retrospective usually also performed once every sprint, after the Sprint Review. Usually, only the Scrum Team will do the Sprint retro. As we know that scrum is a flexible framework that will be improved and refined after each sprint. In Sprint retro, each member will share something that can be improved for the next sprint and will be discussed what went well during the previous sprint so the same method could be applied for the next sprint.

In my personal opinion, Scrum is a beautiful framework if done correctly (even though there are no specific rule about it). Scrum will accelerate new feature to be added to the working product. It also helps the developer to be more relaxed and also enjoy what they have done. Sprint retro is also a nice touch because each member can evaluate the previous sprint so that the next sprint won’t have the same hiccup and can be done more efficiently. As my article title, Scrum is a beautifully imperfect framework and just like us human with our flaws.