Agile Software Development & Scrum
Agile means “having a quick resourceful and adaptable character” according to Merriam-webster. In other words, someone who is agile would have the ability to adapt quickly to things that happen around them. When we develop software, requirements might change due to business needs. That’s why being agile becomes a standard in the software development process nowadays.
What is Agile in Software Development?
Agile is a methodology for developing software in a way that can accommodate and respond to change well. It is by doing the agile things explained below that we can produce high-quality software quickly.
- Effective communication
Every stakeholder really should communicate effectively. It’s the key so that everyone can be aware of any requirement change and adjust to it. - Involve the customer in every phase
The customer would be someone who makes use of the product. That’s why we have to involve and discuss with them during the development. - The team must be in control
By having a strong and responsible team, we would be able to adapt to changes better. Members must demonstrate ownership of the product. - Rapid, incremental delivery
Deliver small parts of the software quickly. It’s quicker to deliver small parts rather than enormous parts. But these small parts should be usable.
Agile Software Development Manifesto
https://www.agilealliance.org/agile101/the-agile-manifesto/
OK, Agile sounds good. What are the differences before and after being Agile?
- Individuals and interactions over processes and tools
Interaction between the individuals involved holds a key part in agile software development. Processes and tools become less important in agile, as long as everyone has the same understanding by interacting adequately. - Working software over comprehensive documentation
Documentation can be simple, just enough to be understood. It doesn’t have to be super thorough and long. But the software should be working. By implementing clean code, the code can be self-documenting as well. - Customer collaboration over contract negotiation
Contracts are less important, as long as the customer is willing to communicate with the development team so they can notice any updates. - Responding to change over following a plan
When doing agile, we still make plans. But the plans are short-term (for example, every 2 weeks). Agile emphasizes more in responding to change.
Agility Principles
https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/
Below are the principles that the team must comply with if they choose agile.
- Satisfy the customer through early and continuous delivery of valuable software.
When developers build software, obviously they hope the customers will use it, otherwise, what they built is a waste. How would they know whether the customers like it? It’s by asking the customers’ feedback. Our software is like an experiment from our hypothesis of what the customers want, and their feedback will decide whether our hypothesis is correct. Therefore, it’s important to provide our software early because the developers want to receive the feedback early as well. As developers improve their understanding of what the customer wants, they can build better software, which should better suit the customers’ needs. - 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 for the shorter timescale.
Aligning with the first point, this point reinforces the importance of rapid iteration. Don’t over plan. We don’t have to build software completely, right now. What the user wants might change, we might interpret them incorrectly, and the organization’s priorities might change. Break down the work that needs to be done, and start building as soon as possible. Then, ask the customers for feedback. This will keep them engaged, too. - 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.
Before, and after developers build software, usually there are kinds of documentation that goes along with it, like a design document, another document for users, yet another document for maintainers, and maybe more documents for other stakeholders as well. However, the software developers need to remember that what they deliver is the software that they build. Even if they’ve done a tremendous job with the docs, when the software itself doesn’t satisfy the customers, the docs will be of no use. - Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace.
The first and the third points discuss continuous and frequent delivery of value, through software. We want to be able to deliver the software quickly, not only for the first version but also for the future ones. Therefore, it’s important to have some rules that improve development sustainability in place, including rules for testing and documentation. - Continuous attention to technical excellence and good design.
- Simplicity — the art of maximizing the amount of work not done — is essential.
Each line of code that we write, and each functionality that we build would increase maintenance cost in the long run. Therefore, we should assess the things that we need to create, to keep maintenance costs minimal. This should reduce the creation of waste as well as free up our time so we can continue to work productively. - 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.
Agile vs No Agile
Above are some of the software development methodologies. In general (common), we have to define product requirements, deliver value, and collaborate. However, each software development methodology offers different underlying steps when being applied in developing software.
Agile
Scrum
In summary, it consists of three roles: Product Owner, Development Team, and Scrum master. It partitions development work as product backlogs and work occurs in sprints.
Extreme Programming (XP)
Famous because it encourages pair programming where two developers work on one computer. Hopefully, they can ask each other when programming so there will be less confusion.
No Agile
Waterfall
A sequential approach to software development. It would be less adaptive to changes because every step is very structured. It is ideal to use when requirements are really fixed and well-defined in the beginning.
Unified Process
A process model that consists of the inception, elaboration, construction, and transition phase. It is better to be used when requirements are well-defined in the beginning as well. But it’s less rigid than waterfall because, for example, planning doesn’t have to be done only in the first (inception) phase but it can still be continued in the elaboration phase.
Summary of Agile vs No Agile
In summary, just like in the Agile Manifesto above, Agile focuses on interactions between the individuals in the development team and pays less attention to documentations. It encourages collaboration and being adaptive when responding to changes, whereas No Agile is the opposite of these.
Scrum
Scrum is a kind of Agile Software Development that was proposed by Schwaber and Beedle. Hence, Agile is a general term while Scrum is a more specific term. Please find below the specialties of Scrum:
- Development work is partitioned into “packets” called product backlogs. These product backlog packets are equivalent to requirements/features.
- Testing and documentation are ongoing as the product is constructed
- Work occurs in “sprints” and is derived from the aforementioned “backlog” of existing requirements that are not yet completed.
- Meetings are short but expected to be effective & keep everyone aligned.
- “Demos” are delivered to the customer with the time-box allocated.
Scrum is gaining popularity these days because it is effective. Meetings are short so the development team can be more productive in doing the backlogs. The product is delivered frequently and if there are requirement changes, scrum is more adaptive compared to traditional processes such as waterfall. To use scrum or not to use scrum depends on the requirements of the project itself. Generally, use scrum when you want to be adaptive to changes.
Role in Scrum
- Product Owner. Someone who defines the product backlog, a representative that gathers inputs from Customers and communicates them to the development team. In a business environment, the Product Owner also has to consider the business aspects of the product.
- Development / Scrum Team. The team that is responsible for developing the software. The members are working together by taking the product backlogs that they want to do. They communicate any issue that arises.
- Scrum Master. He organizes the scrum team and manages scrum events such as standup meetings, sprint planning, and sprint retrospective.
Scrum Events
Scrum events are happening during a sprint, which is a short period (like two weeks) where the development team works and tries to complete the tasks.
- Sprint Planning at the beginning of each sprint. Each development team member chooses the sprint backlog that they want to do on that sprint from the product backlog. We can utilize a board to track the works that are not started yet, in progress, blocked, complete, or needs review.
My project in the Software Engineering Project course is Liwat.ID about travel planning. Until sprint 2, the product backlogs that I have chosen to do are: crawling travel destination data with selenium, search travel destination by keyword on Liwat, filter travel destination by location, category, and price, and remove travel destination from the bucket list (it is like a wishlist).
- During Sprint: Work together to finish the sprint backlog.
- Standup: Meeting between the development team and the Scrum Master that is usually conducted daily, but can be adjusted according to the availability of everyone. For example, we can do it twice a week. The purpose is to give an informal update about progress and any blockers. For the Product Owner, this is not mandatory but they may join if they want. The informal update can be formatted into the following questions:
(1) What did you do since the last scrum meeting?
(2) Do you have any obstacles?
(3) What will you do next? - Sprint Review: Product demo where everyone can try part of the product that has been completed so far, and basically review and discuss that completed work of the sprint and any improvement ideas. This is the sneak peek of what our team delivered from the 1st until the 4th sprint review.
- Sprint Retrospective: An event to evaluate the recently completed sprint, whether the development team is solid, whether they can deliver the expected results, and what are the action items to improve the next sprint.
How can Scrum help us adapt to change?
You are in the middle of the sprint and have been developing your backlog. Suddenly the Product Owner says that there is a change. What should you do?
- Communicate, communicate, communicate.
How urgent is this improvement? How busy is your schedule at the moment? All of this can be understood only through communication. That’s why first and foremost, communicate about it with the Product Owner to understand this change better in the first place. - Decide
I will explain this part with an example. I had been developing my backlog and it has been completed. The backlog was an itinerary recommendation algorithm. At first, it didn’t consider user preferences of the travel destination category. Now my Product Owner wants it to consider the user preferences. After communicating in the first step, I understand clearly what I need to do to apply this improvement. Therefore, I can measure the effort compared to the benefit. After thinking about it, I agree to apply this improvement during that sprint because the effort is not very large and I think the benefit that she desires makes sense to me. Therefore, I can apply this change and it seems that she is happy with the result, yay.
In the event where you think that the desired improvement is not feasible to be applied on that sprint, I think that you should really communicate until you reach a consensus. People are usually understanding when you explain.
Conclusion
In conclusion, Agile is a great software development methodology that allows us to respond to change better and deliver software quicker. We can achieve this not just by doing everything quickly without a thinking framework, but we actually have guidelines and principles of Agile that we must follow in order to apply Agile correctly and effectively.
Scrum as part of Agile methodology has its specialties and terms, such as the work are being done in sprints, and features are said to be product backlogs. Scrum consists of 3 roles and 5 events as mentioned above. Agile and Scrum are suitable for projects that expect to deliver quickly and adapt to change.
References
- Software Engineering Project Course, Computer Science University of Indonesia 2021: Scrum Guideline
- Software Engineering Course, Computer Science University of Indonesia 2020: Scrum and Agile
- https://number8.com/10-agile-project-management-terms-you-should-know/
