The Importance of Being Agile

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. This is the first of 12 Agile Manifesto principles published by an eminent group of software developers in 2001. Over the span of 20 years, these Agile principles have led a progressive shift in the way modern software is designed, developed and delivered.

The importance of Post-it notes in Agile!

Today’s business software solutions are expected to support an ever-evolving range of operational imperatives and user features such as AI-powered interfaces, big data analytics, digital identity authentication, secure payment processing and transaction signing.

The traditional model of software development (commonly referred to as the Waterfall method) requires segmenting the project into a linear sequence of distinct phases, beginning with the detailed documentation of functional and technical specifications before moving sequentially through the coding, integration, testing and deployment phases. Given its dependency on having well-defined specifications, the Waterfall method can work well for projects which primarily use commercial off-the-shelf products and where the underlying business requirements are stable and not susceptible to frequent changes.

However, this is not always the case since businesses are operating in increasingly complex and competitive marketplaces where their abilities to adapt and innovate constantly are important factors to continued market success. Correspondingly, when acquiring bespoke software solutions for their customer-facing and internal operations, businesses can find it difficult as well as risky to rigidly define and stick to a fixed set of specifications.

This is where the Agile method demonstrates its advantages by shifting towards an adaptive model of incremental software development cycles. Instead of the Waterfall method’s sequential series of specification-centric phases, which may take many months to complete, the Agile method can start with an overall product goal or vision without the need for detailed specifications and can swiftly proceed to deliver regular product increments through short cycles of planning, coding, testing and integration activities known as Sprints.

Each Sprint typically takes 2 to 4 weeks to complete, and its activities are performed by a Scrum Team comprising of a Product Owner, a Scrum Master and a group of Developers. As the representative of the business commissioning the software project, the Product Owner is responsible for defining the product vision and prioritising the product features in order of their business value within the allocated project budget and schedule.

This ordered list is known as a Product Backlog, and its items are subject to continuous refinements throughout the Sprints to ensure the most valuable parts of the product are developed, tested and delivered early by the Scrum Team.

At the start of a Sprint, the Developers would take the top-ranked Product Backlog items and break them down into specific tasks, which can be done by 1 to 2 Developers within 3 to 4 days. In the course of every Sprint, the Developers would also meet each day in Daily Scrums.

Facilitated by the Scrum Master, these Daily Scrums are 15-minute standup meetings where each Developer updates the other Developers on the work done the previous day, the work he or she plans to do that day as well as any impediments encountered. If there are impediments, such as inadequate hardware resources, it is the Scrum Master’s responsibility to resolve them in order to boost the Developers’ productivity.

As the Scrum Team is committed to the goal of releasing fully tested and defect-free product increments, functional, integration and regression testing are continuously performed on the coding by the Developers. At the Sprint’s conclusion, an inspection of the product increment is jointly carried out by the Scrum Team and stakeholders from the business.

This joint inspection process is known as the Sprint Review, which seeks to ensure the project remains on course with the product vision and business requirements. It also presents an opportunity to make product improvements by adding, altering or re-prioritising items on the Product Backlog. Following the Sprint Review, the Scrum Team will conduct a Sprint Retrospective on ways to improve the development processes which they can adopt for subsequent Sprints. This iterative cycle of Sprints continues until the project is done with the final integration of the last increment and the release of the completed product.

Collectively, these Agile practices foster close collaboration and interaction between all parties, which in turn motivates the Scrum Team to deliver quality and valuable software within much shorter timeframes. For example, consider the possible advantages of being able to market or implement a new business product in 18 weeks using the Agile method versus 18 months with traditional methodologies.

Attainment of these potential efficiency and productivity gains should be supported by the underlying software development contract between the parties through the express incorporation of the agreed Agile practices. However, parties should note that most software development contracts are normally crafted for use in Waterfall projects.

Although they may include various standard clauses such as those on dispute resolution, intellectual property rights, indemnities and warranties, which are equally applicable for Agile projects, parties should nevertheless strive to ensure their contracts reflect the unique features of the Agile method.

To this end, an Agile software development contract can be expected to include clear definitions of key terms such as Product Backlog, Sprint Review and Sprint Retrospective, descriptions of the required expertise, roles and responsibilities of Scrum Team members, details on the planning process for Sprints and the refinement of Product Backlog items, as well as the overall completion criteria for product increments.

By investing a little effort and forethought in crafting Agile-ready project contracts, businesses can position themselves to stay nimble and innovative and to realise the full value and importance of being Agile.

This opinion piece was contributed by the General Counsel of the Government Technology Agency, Vincent Kor, where he advises and works on technology law matters.