A Singapore Government Agency Website
Fig 1: Understanding Agile

What is Agile?

Agile is a mindset

An agile mindset focuses on “being agile” as a foundation for success in “doing agile”. The agile mindset has teams put aside ego, and focus on what is right, instead of who is right. It is synonymous with a growth mindset grounded in a culture of learning and experimentation with a deep focus on delivering value to the customer.

An agile mindset recognizes our human resources and is driven by innovation and problem-solving skills. It changes the structure of management in business to a more fluid and adaptive system, by emphasizing the following:

  • Respect
  • Accountability
  • Collaboration
  • Adaptiveness to change, learning cycles, and improvement

Based on 4 values

Individuals and interactions   >   Processes and tools

Working software           >   Comprehensive documentation

Customer collaboration      >   Contract negotiation

Responding to change        >   Following a plan

While there is value in the items on the right, we value the items on the left more

Fig 2: Understanding Agile

Described by 12 Principles

Consider building your practices with these principles in mind.

Agile is a journey and the aim is to get better at each of these principles over time.

Fig 3: The 12 Principles describing Agile

Why pursue Agile?

There are many reasons why teams choose to adopt an agile approach to deliver their projects and products, over the traditional methodology.

In this Playbook, we focus on some of the key benefits that would be relevant, regardless of the project or product that you’re working on.

Deliver Value Early

Agile methodologies focus on creating customer value early. They aim to showcase a shippable product in small increments to allow stakeholders to visualise and experience the value that’s been created.

Seeing an actual, albeit partial, working product frequently motivates the team and generates momentum. This would also lower risks, as the team will be able to identify and address issues earlier on.

Adaptable to Change

By building and delivering the product in smaller increments over a defined timeframe, which can be months or years, allows the team to have more frequent checkpoints throughout the duration. At the same time, as each increment aims to deliver a shippable product at the end, it gives the team flexibility to tweak priorities and react to changing requirements.

Greater Customer Satisfaction

Agile methodologies also advocate that the Product Owner (typically one from the business side of the organisation) works closely with the team as a whole. This increased level of participation helps with better engagement within the team and ensures the needs and requirements of the Product Owner (representing the user needs) are met.

By being so much closer to the implementation and team, the Product Owner gets a clear view of what’s happening and is able to react swiftly to changes or issues.

How to adopt Agile?

Often requires a mindset shift

Fig 3: Mindset shift

When to use Agile?


Agile is an iterative methodology that incorporates a cyclical and collaborative process.

Waterfall is a sequential methodology that can also be collaborative,. But tasks are generally handled in a more linear process.
Agile methodology

Following the agile methodology, the work moves through a series of cycles throughout the lifetime of the product development lifecycle. These are:
- the development phase
- review
- feedback
- acceptance of the work item

If accepted, implement and complete the task.

If not accepted, record the input and make changes to the task descriptions. Then decide on the prioritisation and adjust the product backlog accordingly to reflect the newly-acquired knowledge, and move onto the next most valuable task, or sprint.
Waterfall methodology

Following the waterfall methodology is a simpler process. The team moves tasks through the phases of:
- defining requirements
- designing the implementation
- implementing the work item
- verification of implementation and quality assurance
- maintenance of the feature in the end
Choosing Agile

- Scope is unclear
- Implementation method is not firm
- Need for learning and examination of the value of work as it is being produced
Choosing Waterfall

- Scope is clear
- Implementation method is straightforward (time required is known)

Different types of Agile Methodologies

Considerations of Scrum and Kanban

Considerations of Scrum and Kanban
  1. Team’s Exposure to Agility

    Scrum advocates regular agile events and having cross-functional teams, while Kanban does not. For teams new to the agile way of working, adopting Scrum may be helpful as it has defined guardrails. As the team matures, it can apply Kanban practices to improve the flow (delivery) of value and have the best of both worlds.

  2. Team Formation & Way of Working

    Kanban does not have the overhead of (re)organising into cross-functional teams. Rather, team members can work independently on tasks in the value stream, bound by the common purpose of satisfying the customer’s needs.

  3. Coping with Frequently Shifting Priorities

    Kanban equips a team to handle changing priorities and incoming items, while Scrum forces the team or organisation to adapt to sprint cadences, as a means of protecting the development team’s bandwidth.

  4. Importance of Planning

    Scrum has simple sources of information for forecasting delivery dates and variability using the burn-up chart.

    Kanban makes use of flow metrics like cycle time, aging work-in-progress, work item arrival and departure dates, and throughput, which can help highlight risks and issues. This leads to better forecasting and work management.

  5. Starting from where the team is currently at

    Kanban focuses on starting from what the team is doing now and improving in an evolutionary way, vs as a complete revamp or revolution. Scrum requires the team to adopt the set of roles, events, and artefacts.

  6. Team Size

    Scrum recommends a team size of 3-9 members.

    Kanban does not come with team size limitations.

Which approach to use - Scrum or Kanban?

For a quick sense of whether to use the Scrum or Kanban approach:

No. Considerations Yes No
1 There are more system migration and maintenance activities (bugs, patches, upgrades, minor features) than enhancement activities (new feature development).
2 The requirements are likely to change within the Sprint timebox if Scrum is practised, even with sufficient refinement.
3 Most of the tasks cannot be completed within a typical Sprint timebox (1 to 4 weeks).
4 Multiple teams have a say on the product backlog – requests are coming in from different stakeholders with no defined or clear Product Owner.
5 There is no steady flow of incoming requirements (requirements are unplanned and at an irregular rate).

If the number of “Yes” is more than “No”, consider the Kanban method. Otherwise, try Scrum.

Setting up an Agile Team

Start with a small team

  1. Start with a set of basic principles (team working agreement) and roles & expectations (rather than responsibilities, as it often leads to the “not-my-responsibility” non-collaborative thinking)
  2. Identify the current and desired patterns, then jointly define the team practices
  3. Reflect and learn
  4. Scale practices as the team grows, by sharing learnings and promoting alignment

Training and workshops

Prior to adopting Agile, all key stakeholders ( e.g. senior management, business users, Product Owner, etc.) involved and new to the Agile delivery of the system must be trained in Agile values, principles, and concepts.

  1. Agile Courses (PO, SM, Devs)
  2. Agile primer workshops

Work environment

Co-location with the Product Owner (PO) is key

  1. Direct communication results in faster and easier decision-making
  2. Facilitates osmotic communications
  3. Team bonding. Co-location increases team interaction, leading to stronger bonds.
  4. Less room for noise
Chat with me!
Bot Launcher