How We Use the Agile Software Development Methodology
Two decades ago, 17 software developers published a manifesto for Agile Software Development. The goal: reveal a better way of developing software by doing it and helping others to do it.
Agile adds more value to the software development process than the traditional waterfall method by reducing and simplifying the heavy documentation.
The Agile Manifesto describes the below 4 values and 12 principles.
Individuals and interactions over process and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.
Agile has fundamentally changed the way we develop software. It introduced a promising way to build software with an iterative approach that helps development teams deliver releases to customers faster. Agile is an umbrella term for a set of frameworks and practices like Scrum, Kanban, Extreme Programming (XP), Crystal, etc.
We at Zco use these Agile frameworks and methodologies to maximize the value of deliverables and the satisfaction of both our customers and the development team. We believe in customer collaboration, and the deliverables in short intervals help reduce the rework and focus on the essentials.
Our cross-functional and high-performing team works with knowledge built from years of experience and makes decisions based on their observations.
The Scrum Team
This cross-functional, self-organized team commits to achieving its goals and supports one other. Our scrum team works with the following key principles in mind.
Transparency: Everyone involved in the project knows what’s going on.
Inspection: The incremental iterations are regularly inspected and approved.
Adaptation: The ability to adapt and improve based on the result of the inspection.
The scrum team consists of a Product Owner, Scrum Master, and Development team.
At Zco, the Project Manager acts as Product Owner of our scrum team who is accountable for maximizing the value of deliverables. The Product Owner closely works with the customer and other stakeholders of the project to gather the requirements and add them to the product backlog.
The Product Owner ensures the Product backlog items are transparent, visible, and understood. They are responsible for prioritizing backlog items with customer communication.
In other words, the Product Owner represents the business needs of the customer.
The Scrum Master establishes the scrum process. They act as servant leaders who serve the team and organization by removing impediments that help avoid distraction and focus on creating high-value sprint goals.
The Scrum Master ensures all the scrum events are productive and kept within the timebox (allocating a fixed unit of time to an activity).
Developers are a multi-talented team of professionals who work together with a commitment to creating a usable release for each sprint. The team is a mix of business analysts, architects, coders, testers, graphic designers, and others. Based on the project’s domain, various skills are included in the team.
The development team creates the plan for the Sprints, Sprint backlogs, defines quality measures, and adapts the plan each day towards the sprint goal.
The Scrum Events
The sprint is a container of all the scrum events, and each event in the sprint is for inspecting and adapting Scrum Artifacts (Product Backlogs, Sprint Backlogs, and Increments/Releases).
We usually execute the projects in two weeks sprints to enable product increment deliveries every other week, which helps adapt to changes and reduce rework. The sprints enable predictability by ensuring the inspection and adaptation of progress towards the product goal.
During each sprint, the product backlog refinement happens in preparation for the next sprint. The development team works with the Product Owner for product backlog refinement, which helps make Sprint Planning easier and fit within the timebox. The development team will gain a clear understanding of the product backlog items for the upcoming sprint.
The Sprint Planning initiates the sprint. The Product Owner ensures the development team selects the most priority backlog items for the sprint. Architects and other subject matter experts from outside the scrum team might have also been present in the Sprint Planning meeting based on the team’s request.
The Product Owner proposes how this sprint increment adds value to the product to help the development team to prepare the sprint backlog items and plan them accordingly. The Sprint goal will be finalized by the end of the Sprint Planning meeting.
The Scrum Master ensures the meeting ends within a timebox of 4 hours.
The development team conducts the daily scrum meeting to inspect the progress towards the Scrum goal and adjust the upcoming tasks. It improves communication, identifies impediments, and allows quick decision-making that leads to transparency.
The daily scrum also eliminates the need for other meetings. The team dismisses the meeting within the timebox of 15 minutes. If there are any technical challenges, the corresponding team members discuss and resolve them after the daily scrum.
We conduct the Sprint Review to inspect the product increment and determine future adaptation. The Scrum team, the customer, and other key stakeholders will be present in the meeting. The team will present the outcome of the sprint before the attendees and gather their feedback. The product backlog may also be adjusted based on the discussion in the Sprint Review meeting to incorporate new opportunities.
Scrum Master ensures the discussion never goes beyond the boxes and keeps the meeting in a timebox of 2 hours.
We discuss what went well during this sprint, and how to improve on upcoming sprints, in the Sprint Retrospective meeting. This meeting allows us to plan methods that will improve on our quality and effectiveness. The continuous observations of the team and self-refining will lead to better quality on product iterations.
A Sprint Retrospective is a timeboxed event of 45 minutes, and the Sprint concludes with this.
Scrum of Scrums
We use the Scrum of Scrums for larger projects that work with multiple scrum teams in a single product backlog and achieve the same product goal. The typical size of our scrum team is less than 10. So multiple scrum teams will be working on complex projects to deliver solutions. The Scrum of Scrum is a time-boxed session to meet representatives of each scrum team to share high-level updates of the respective team and discuss integration challenges.
Ultimately, why Agile?
We adopt Agile culture because it allows us to collaborate, learn, and stay flexible so we can achieve high-quality results together as a team. These results in turn benefit our customers as they receive the highest quality product on-time and on-budget.