When I got the opportunity to be the Manager of IT Development for COMPFEST, I evaluated whether Agile (and Scrum) would be suitable for our development workflow then. It turns out that Agile was not suitable for us. Before I discuss the reason why, let's learn more about Agile and Scrum. Since Scrum and Agile are often misinterpreted, I would mainly quote primary sources for the reader to personally interpret.
Agile Fundamentals
To understand Agile, we must know what is Agile. For the layman, this introduction serves well:
Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a "big bang" launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly.
For the more precise definition, we need to take a look the Agile Manifesto and its 12 principles.
Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it. When you approach software development in a particular manner, it’s generally good to live by these values and principles and use them to help figure out the right things to do given your particular context.
Agile Principles
From the Agile Manifesto, there are 12 principles that guides the Agile process:
We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
What Is Scrum?
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems. Scrum co-creators Ken Schwaber and Jeff Sutherland have written The Scrum Guide to explain Scrum clearly and succinctly. This Guide contains the definition of Scrum. This definition consists of Scrum’s accountabilities, events, artifacts, and the rules that bind them together.
In a nutshell, Scrum requires a Scrum Master to foster an environment where:
- A Product Owner orders the work for a complex problem into a Product Backlog.
- The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
- The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
- Repeat
Implementation
Before we begin the scrum process, we need to divide our feature into some product backlogs. From the product backlogs that we already got, we split it again into some product backlog items (PBI). These PBI will be developed and finished in a one to four weeks phase with some events that can be called scrum events.
To finish these tasks, we need a group called the development team. The human resource in the development team consists of:
- Product owner (PO). A product owner is an owner and the evaluator of the project. They also have a task to determine the priority of the job.
- Scrum Master (SM). Scrum masters have a role as the development team leader and ensure the scrum process works well.
- Development Team. It consists of team members that got a task to create a product, in this case, software.
Many events are going to happen in a scrum process; those are:
- Sprint Planning is the event to choose some PBI to work in one of the sprints. This event produces a sprint backlog.
- Daily Standup is the event to share with the other development team members about:
- What have we done since the last meeting
- Obstacles that we encounter in recent works
- What are we going to do in the future until the next meeting
The result of these scrum processes is a part of a product or increment. After this increment is finished, there are other scrum events, that is
- Sprint Review is an event where the development team has to show their product that has already been developed and the plan for the next sprint with the product owner
- Sprint Retrospective is an event to evaluate the teamwork and process of the team while identifying things that are needed to add in the next sprint. After these events, the development process will go back to sprint planning until the software is finished.
When It's Not The Option
During the introduction, I said that Agile and Scrum was not suitable for COMPFEST then. Even with my improved knowledge of Agile and Scrum now, I stand by my decision then. While it's not really appropriate to call it unsuitable, other approaches certainly suit us better then. There are reasons why Scrum was unsuitable:
- Time commitment required for Scrum/Agile process was not feasible for volunteer student-led activity that can only commit a finite amount of hours each week
- Product requirements were pretty much set and known beforehand. In hindsight, there were also no major changes to the product during development.
Given the consideration above, we went with traditional waterfall cycle. Since we know the scope and requirements of the project beforehand, we can plan and factor in the time commitment needed beforehand too. In conclusion, I think that making Agile or Scrum process work in a non full-time position can be incredibly hard.
Ajaib DeX: When Agile is THE Option
For PPL this semester, my team and I are developing Ajaib DeX and we belive that Scrum is the perfect fit for this project. We are now going into sprint 3 (out of 4 sprint) and the benefit of Scrum and Agile process is readily apparent.
Going into this project, we do not know exactly the scope and exact requirements for this project since the crypto world is completely new to us. Therefore, during our sprint, we often do spontaneous research to delve into the featured problem. As a result, we often need to change the requirements or tasks for the project. This is not feasible with a waterfall-like process and Scrum is really suitable for this.