A Story On Agile and Scrum
This article wasn’t written Agile. Do not read this article Agile.
As per usual with my previous articles, before we discuss this topic, let’s start the story with some basics.
What is Agile?
Defined by Oxford dictionary, agile is:
- able to move quickly and easily
synonym nimble
a strong and agile athlete - able to think quickly and in an intelligent way
an agile mind/brain
Wait a minute, this doesn’t make sense! I thought all of your articles are related to software engineering, why are we talking about sports in this article?
No, silly! You just haven’t read all of the definitions yet clearly! Below is the last definition of the word Agile that we’re going to discuss in this article:
relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.
agile methods replace high-level design with frequent redesign
As we can infer from the definition above, Agile is an approach to project management and software development that helps teams deliver value to their customers faster. By dividing tasks into short phases of work, a team can work in increments with continuous evaluation and reassessment. By dividing works into small tasks, teams are more flexible for proposed changes while developing their products.
Principles of Agile
Even though Agile itself were a software development practice that is implemented on many methods such as Scrum (we will discuss this one later in this article), Extreme Programming, and others, these methods are made under the same Agile principles that are based on Agile Manifesto, founded February 2001 (yes, they are still relevant, if you are asking). The manifesto itself can be accessed under this link. Below are values shown from the manifesto:
Other than the 4 main values of Agile Manifesto, there are also 12 principles to be followed. These principles can be easily accessed under this link. Since it is quite extensive and explaining all of them would be a bit too much under this article (plus, many other articles on the internet have explained these principles and value well! you should check them instead!), I'm only going to explain the first principles from the manifesto:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This principle is made as the basis of tasks divisions and sprint cycle, by dividing tasks and following a spring cycle, developers can continuously deliver valuable software to satisfy customers.
Scrum
As explained before, Scrum is one of the frameworks that implement Agile philosophy. Scrum implements the scientific method of empiricism, which is done by interactions between 3 main roles that are Scrum Master, Product Owner, and Developer Team. By using Scrum in developing a project, a team can work together, self-organize on working their problem, and reflect on their work to continuously improve.
Scrum consists of Scrum Events and Scrum Artifacts. Below are their explanation:
Scrum Artifacts
Product Backlog
Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. Product backlog can be used to define and elaborate tasks that are need to be done by the team.
The image above shows an example of a product backlog, otherwise called ‘PBI’. A PBI has an identifier, a priority level (to know which backlog that are needed to be done first), a backlog title, a business value that explains the functionality of the backlog, and a user story. A user story is a tool that is used in Agile software development to explain the purpose of a product backlog from a user perspective. A user story describes the type of user (as), what they want (I want to), and why (so that). A user story helps in simplifying the process of the team in understanding what the user needs.
Sprint Backlog
The Sprint Backlog is a plan by and for the Developers to do during the duration of a sprint. This backlog usually consists of 4 sub-categories, which are ‘Open’, ‘To Do’, ‘Doing’, and ‘Closed’. ‘Closed’ sub-category can also be called as Increment Scrum Artifact. Sprint backlog can be updated only during the Daily Scrum meeting. Below is an example of my team Sprint Backlog, done by using Gitlab Board:
In the above example, we can see 2 boards, which are ‘To Do’, and ‘Doing’. ‘To Do’ explained a task that you haven’t done yet but are planning to by the time until before the next meeting, while ‘Doing’ explained a task that you’re currently doing during the time of the meeting.
Scrum Events
Sprint
As I have mentioned previously in this article, sprints are fixed length events of one month or less in working on a product backlog (where each sprint has a spring backlog). After a conclusion of the previous sprint, a new Sprint starts immediately. Currently, the project I'm working on has a sprint length of 2 weeks with a total number of 5 sprint iterations.
Sprint Planning
On a sprint planning, a meeting is held to plan (surprise, surprise!) which product backlog will be completed. All roles attend this meeting and each member of the developer team chose which work to be done. In my project, this meeting is held by the help of Google Meet. Here, we discuss about Product Backlog that we are planning to take at the current sprint, task divisions, and other concerns on developing the project.
Daily Scrum
Daily Scrum is a 15-minute event for the developer team to discuss their progress and updates their sprint backlog when new progress has been made or completed. In our current project, Daily scrum occurs around 30 minutes and is also attended (and led!) by our Scrum Master.
Sprint Review
At the end of a Sprint, a Sprint Review was held between the three main roles and the client to show progress (as said by the Agile value I mentioned before in this article!). In this review, participants inspect the outcome of the sprint and discuss future plans and possible adjustments for the product. In my experience, the team usually starts the event by showing a slide presentation to tell briefs explanation of the sprint, demonstrate improvements made during the sprint, and continue on with Q&A sessions with the clients.
Sprint Retrospective
After a Sprint Review, Sprint Retrospective was held to plan ways to increase the quality and effectiveness of the product and the team for the next sprint. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved. Usually, this is done by asking each member of the Developer Team to assess the Good, the Bad, Start and Stop based on their actions during the Sprint, which the team tries to solve after. On our project, we use metroretro to conduct our Sprint Retrospective. In metroretro, each person is given a set amount of time to post hidden sticky notes between categories of the board until the time has collapsed. Afterward, we revealed all sticky notes, group them based on similarities, and discuss them with each other. This gives us an opportunity to reflect on ourselves individually and as a team to improve ourselves on the next iteration.
Self-Organized Team
The Agile Manifesto includes 12 key principles that define what it means to “be Agile.” One of those principles states that “the best architectures, requirements, and designs emerge from self-organizing teams.”
Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team
From the quote given above, we can conclude that a self-organizing team is one that does not depend on or wait for a manager to assign work and instead, find their own work and manage the associated responsibilities and timelines. Self-organizing teams also take on the responsibility of choosing the most effective and efficient way to complete their work and regularly look for ways to improve through experimentation.
In Scrum, we implemented this agile principle from the start until the finish of our Sprint. In sprint planning, we split our own product backlog into tasks under our own interpretation without input from clients and divide it to each developer. Afterwards, we finish our task by implementing the best solution we could find and furthermore optimized it by discussing with each other for suggestions and improvements to be done. For example, here’s how we improve our implementation after we finished our task:
In the screenshot above, I did a peer review of our tasks and realized that we can improve and optimize our function furthermore, therefore, proving that Scrum does apply this Agile principle.
And now the article ends here. After reading this article, I hope you understand Agile Software Development and Scrum as one of Agile frameworks. Consider using them when you’re developing your own project. Wouldn’t that be great?