Skip to content

Ways of working

Introduction#

Most organisations that build software now describe their approach as agile, but many do not exhibit genuine agility. It is common to find teams with sprints, stand-ups, and story points 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 necessary discipline, and the result is often overhead without benefit.

These organisations usually lack an understanding of what each ceremony and technique is for, so they follow them as rituals that do not produce the 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 work well as a default.

What agility actually means#

Agile frameworks aim to create a small set of properties in a team. The Agile Manifesto ↗ and its Twelve Principles ↗ are still highly relevant references. The key properties are summarised below, with links to the relevant pages.

  • Short feedback loops. Work is completed in small iterations and validated at each step to check whether it addresses user needs, satisfies stakeholders, and is technically feasible, so that mistakes are cheap to correct. Feature slicing keeps each iteration small enough to learn from, and a walking skeleton directs early effort at whatever will generate the most learning.
  • 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 Definition of Done makes “done” explicit at every stage.
  • 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. Small, independent slices can be reprioritised freely, and story points support forecasting without locking the team into a detailed plan.
  • A team that owns its process. The people doing the work understand why each ceremony and technique exists and adjust it when it stops serving its purpose. The daily meeting belongs to the team rather than the lead, and retrospectives are where the team decides what to change.

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

The Tech Lead’s role#

The Tech Lead usually has significant influence on team process and sometimes primary responsibility for ensuring it is effective. This varies between organisations, and some Tech Leads focus on the more technical aspects, such as branching and code review policies, while a Scrum Master or Delivery Lead leads the rest. Others lead all of it. What is a Tech Lead? describes how this varies.

In any case, the aim is a team that understands and owns how it works, rather than one following a process handed down to it. When introducing a change:

  • Start from a problem the team recognises. Changes should be driven by solving specific problems, usually ones identified by the team in retrospectives.
  • Explain what it is for. A technique whose purpose is understood can be adapted sensibly. One whose purpose isn’t understood soon becomes a ritual.
  • Change one thing at a time. That way the team can absorb it, and everyone can see what made the difference.
  • Review it in the retrospective. Treat each change as an experiment, then keep it, adapt it, or drop it based on how it worked in practice.

How the pages fit together#

The pages in this section follow a work item through its life, from shaping it to flowing it into production, then turn to improving how the team works.

Shaping the work#

  • Feature slicing explains how to split features into vertical slices of functionality rather than horizontal technology layers, so each piece delivers value users can see.
  • Walking skeleton describes starting a new product or feature with the thinnest possible end-to-end implementation, built, deployed, and tested in a live environment.
  • Acceptance criteria covers writing a shared, testable statement of what “working” means for each item, and how it maps to tests.
  • Story points explains how to estimate the relative size of items as a team, why this is valuable, and how to use those estimates for planning and forecasting.

Flowing the work#

  • SDLC explores the flow of work: the stages work items pass through from idea to production.
  • Definition of Done sets out the criteria an item must meet to leave each stage of that workflow.
  • Daily meeting describes a short daily checkpoint where the team plans its day and raises anything blocking progress.

Improving how you work#

  • Retrospectives explains how to run a regular session where the team reflects on how it works and turns the discussion into real change.