Agile

Introduction

Most organisations that build software now describe their approach as agile, but few exhibit genuine agility. It is common to find teams with sprints, stand-ups, story points, and a backlog tool that still deliver in large, infrequent batches, discover problems late, and struggle to change direction when priorities shift. They have adopted the terminology without the underlying discipline, and the result is often overhead without benefit.

These organisations usually lack an understanding of what each practice is for, so the practices are followed as rituals that do not produce their intended outcomes. A Tech Lead is well placed to close that gap: close enough to the work to see where it is going wrong, and senior enough to change how the team operates.

This section gives an opinionated view, based on practical experience, of what good looks like and what to avoid. It does not attempt to survey the full field of agile practices or consider all options, but focuses on a set of recommendations that are a good default.

What agility actually means

Agile frameworks aim to create a small set of properties in a team.

• Short feedback loops. Work is completed in small iterations and checked against reality (stakeholders, users, production) as soon as possible, so that mistakes are cheap to correct.
• Working software as the measure of progress. The team judges itself on what is done, integrated, and usable, not on what is in progress, estimated, or planned.
• The ability to change direction cheaply. Priorities can be reordered with minimal waste, because the team has not committed excessive effort to a fixed plan.
• A team that owns its process. The people doing the work understand why each practice exists and adjust it when it stops serving its purpose.

These are the properties that produce the business outcomes agile was meant to deliver: earlier value, lower risk, and less rework.