Agile Software Development & Scrum

What is Agile in Software Development?

  • 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

  • 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

  1. 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.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. 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.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. 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.
  8. 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.
  9. Continuous attention to technical excellence and good design.
  10. 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.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile vs No Agile

Image Source:


No Agile

Summary of Agile vs No Agile


  • 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.

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.
Example of the product backlog consisting of the product backlog ID, priority level, product backlog title, business value, the specification of the product backlog, and the acceptance criteria.
  • 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

  • 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.
Example of the board to make Sprint Planning easier
  • 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.
Each member of the development team speaks up about: 1) what has been good so far. 2) what’s still not good. 3) what we should start doing/stop doing on the next sprint. The image is blurred for better confidentiality 😀

How can Scrum help us adapt to change?

  1. 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.
  2. 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.





Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kezia Sulami

Kezia Sulami

Computer Science Student at University of Indonesia