Agile Scrum — Fail Fast, Iterate Fast
“Whereas Agile is a philosophy, Scrum is a specific methodology for how one manages a project. It provides a process for how to identify the work, who will do the work, how it will be done, and when it will be completed.” — Joseph Griffin
Agile as Philosophy
Agile means “able to move quickly and easily”. Agile in a project development is a project philosophy or framework that takes an iterative approach towards the completion of a project. There are many different project management methodologies and some of the most common are Kanban, Extreme Programming (XP), and Scrum.
In early 2001, 17 people gathered and shared their frustrations related to work. The problem was that companies were so focused on excessively planning and documenting their software development cycles that they lost sight of what really mattered — pleasing their customers.
From the meeting, a document is made and the snippet is as follows:
“Manifesto of Agile Software Development”
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Based on the above values known as the four agile values, 12 agile principles are further developed to concretize the framework.
1. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Our team realization:
- We release features every week — quick. This means that features are shipped, not necessarily done. We’ll fix it based on customer feedback in the next increment.
- At the end of every sprint (2 weeks), we deploy the site to staging — walkiddie.netlify.app . In a real project scenario, users can directly use it and developers can gather feedback from them. This is why the product is called MVP.
2. “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
Our team realization:
- There are two sources where unexpected changes happen: from the client or from the developers.
- From the client-side, the client often comes with new features in mind. This can be tricky because not all requests shall be catered with a limited time and task priorities waiting ahead.
- From the developer's side, where we discover edge cases that need to be catered by the website during the development phase. This is usually acceptable. What we do is put that in the issue board to be solved during that sprint or if the unexpected task is heavy — we’ll discuss it during the sprint planning and add them to the backlog.
3. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
Our team realization:
- We release features every two weeks and evaluate them with stakeholders. The event is called sprint review. The benefits: we can verify customers’ needs, assess whether the sprint goal is achieved, and collect feedback to improve the current features.
4. “Business people and developers must work together daily throughout the project.”
Our team realization:
- A successful product requires insight from the business and technical sides. Thus, our team has two product guys as the scrum master and product owner.
- Communicate frequently during standup meetings to keep every party-aligned.
5. “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
Our team realization:
- Product people ensure that engineering people understand the strategy and requirements before development starts. Make things clear during sprint planning, sprint review so that developers are not only working on user stories but also understand the bigger picture outlined in the product roadmap.
- Product must explain ‘how’ the features should be built. In our team, this is encompassed in the PBI spreadsheet (attached). Product people have to provide support as needed by developers and don’t micromanage. This has worked well in my team.
6. “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Our team realization:
- Nowadays, digital platforms are common communication tools to hold scrum events/meetings.
- Scrum meetings can be done daily or based on team decisions.
- Collaborative backlog grooming sessions
- Sprint planning meetings
- Sprint review ( demos )
7. “Working software is the primary measure of progress.”
Our team realization:
- Ship software often: a useful product now is better than a perfect one later.
- A fail-fast mentality means moving forward even in times of uncertainty and testing ideas rapidly.
- Designing and releasing “Minimum Viable Features” rather than fully-developed features; the smallest things we can ship to start getting customer feedback and validate as we continue to build software.
8. “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
Our team realization:
- Everyone agrees on what will get done during a sprint. Once a sprint has begun, no additional tasks are to be added.
- Before every sprint, careful consideration of the amount of work that can be committed to is made. Development teams don’t over-promise.
- Product managers should act as gatekeepers to reduce the noise from other stakeholders and to avoid squeezing in additional unplanned work during an ongoing sprint.
- Product people should promote a sense of psychological safety that encourages open communication and free-flowing feedback.
9. “Continuous attention to technical excellence and good design enhances agility.”
Our team realization:
- The team needs to be cognizant of technical debt and the technical debt implications
- Refactoring cannot be an afterthought, it needs to be an ongoing consideration.
10. “Simplicity — the art of maximizing the amount of work not done — is essential.”
Our team realization:
- Agile principles discourage building merely for the sake of building by emphasizing the importance of being strategic and building with purpose.
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.”
Our team realization:
- We conduct a sprint retrospective at the end of every sprint.
Scrum Methodology
Scrum project management is one of the most popular Agile methodologies used by project managers.
- Agile vs. Waterfall: While Agile is an iterative and adaptive approach to project management, Waterfall is linear in nature and doesn’t allow for revisiting previous steps and phases.
2. Scrum vs Kanban
How Our Team Implemented Agile Scrum
Roles in Scrum
Scrum team has 3 pivotal roles:
- Product Owner: They communicate with stakeholders and end-users to maximize the product’s values, the one who is responsible for creating the product backlog, and they must know when things can and should be released.
- Scrum Master: The servant-leader of the scrum team. The scrum master serves the product owner in sprint planning and sprint reviews, ensuring that value is clearly being described and direction set. They serve the development team in the daily scrum by ensuring that work is happening and that blockers are being removed.
- The Dev team consists of the people who build the product, usually composed of many software developers. Ideally, the dev team must also consist of UI/UX designers, QA, software developers.
Scrum Artifacts
The three Scrum artifacts are the Product Backlog, Sprint Backlog, Product Increment.
- The product backlog is a list of new features, enhancements, bug fixes, tasks, or work requirements of a product. It’s compiled from input sources like customer support, competitor analysis, market demands, and general business analysis.
- The sprint backlog is a set of product backlog tasks that have been chucked into more detailed and actionable items. They are created by scrum master along with the dev team. In the to-do section below are listed the sprint backlog for the next two weeks.
- The Product Increment is the sum of all the Product Backlog items completed during a Sprint and previous Sprints. At the end of a Sprint, the new Increment must be “Done,” by the Scrum Team’s definition of “Done”.
Scum Events
a) Sprint Planning
- Attendees: Development team, scrum master, product owner
- When: At the beginning of a sprint.
- Duration: Usually up to two hours per week of iteration. e.g. a two-week sprint kicks off with a four-hour planning meeting.
- Purpose: Sprint planning sets up the entire team for success throughout the sprint. Coming into the meeting, the product owner will have a prioritized product backlog. They discuss each item with the development team, and the group collectively estimates the effort involved.
b) Daily Scrum Meeting
- Attendees: Development team, scrum master
- When: Usually daily, but depends on the consensus and needs. (Our team is twice every week.)
- Duration: 15 minutes. ( Our team is 20–30minutes )
- Purpose: Stand-up is designed to quickly inform everyone of what’s going on across the team. It’s not a detailed status meeting. The tone should be light and fun, but informative. Have each team member answers the following questions:
- What did I complete yesterday?
- What will I work on today?
- Am I blocked by anything?
c) Sprint Review
- Required: Development team, scrum master, product owner, Project stakeholders (client)
- When: At the end of a sprint
- Duration: Typically 60 minutes per week of iteration. (Our team is 60–120 minutes in every 2 weeks)
- Purpose: Iteration review is a time to showcase the work of the team. They can be in a casual format like “demo Fridays”, or in a more formal meeting structure. This is the time for the team to celebrate their accomplishments, demonstrate work finished within the iteration, and get immediate feedback from project stakeholders.
d) Sprint Retrospective
- Attendees: Development team, scrum master
- When: At the end of an iteration.
- Duration: Typically 45 minutes per week of iteration.
- Purpose: Agile is about getting rapid feedback to make the product and development culture better. Retrospectives help the team understand what worked well–and what didn’t. I usually complain about the team’s behavior and find actionable solutions to avoid the same pains in the next sprint.
The Scrum Life Cycle in Our Project
The Scrum Lifecycle is a repeated cycle of sprints that involves each of Sprint Events, Members, and Artifacts described earlier. The Scrum Lifecycle is implemented on my group project as follows:
Pra-sprint
- The project was decided by our lecturer. I’m working on an arcade game procurement platform along with 5 other developers, 1 PO (Product Owner), and 1 SM (Scrum Master).
- PO met with stakeholders and keeps maintaining communication throughout the project. PO discussed PBI, features that will be prioritized, and product agreement.
- PO and Scrum master met the dev team for the first time discussing the project overview, business understanding, and the hint of the product backlog.
During the sprint
- Every two weeks, the scrum master meets the dev team to decide the sprint backlog. This is called sprint planning. After detailing the actionable tasks, each of the developers picks their task and assigns the weight of each task.
- Our sprint lasts for 2 weeks. During that period, the dev team worked on their task: coding and testing.
- Every Tuesday and Thursday, we held a standup meeting consisting of the dev team and the scrum master. We share our progress, obstacles, confirm details, and so on.
- By the end of the sprint, we held a sprint review with stakeholders, lecturers, PO, SM, and dev team. We display our deployed progress and verify whether we have met stakeholders’ expectations, collect their feedback, and fix it in the next iteration.
The Sprint cycle continues 5 times until the end of the semester.
My Thoughts
Agile Scrum is a very helpful methodology that makes software project delivery fast and progressive. Every party is required to be adaptable to changes coming from the business side that are also rapidly evolving in this digital era. From unicorn companies’ products to school projects implement agile values, even me in my day-to-day life. Beyond software development, agile has taught me to fail fast and iterate fast, to become a quick learner, and to keep progressing even if it’s small.
