Agile Software Development: Build in Small Steps Without Losing Control

01

Agile starts with uncertainty, not meetings

That does not mean the planning was pointless. It means some software questions are difficult to answer until people can see and use something real.

Agile development is a way of dealing with that uncertainty. Instead of treating the first plan as a perfect description of the finished system, the team delivers small, usable parts, learns from them and adjusts what comes next.

The useful word is usable. Splitting a large project into hundreds of tickets is not enough. Holding a daily meeting is not enough either. Agile delivery becomes valuable when each cycle produces evidence that can improve the product or the way the team works.

The Manifesto for Agile Software Development was published in 2001. Its four values favour people working together, usable software, customer collaboration and responding to change. It also makes an important qualification: the things on the other side, including processes, tools, documentation, contracts and plans, still have value.

That qualification is often lost. Agile development does not mean building without a plan. It means accepting that a plan for complex work contains assumptions. The team needs a controlled way to test those assumptions before they become too expensive to change.

Imagine an installer services business replacing a spreadsheet, shared inbox and folders with an operations portal. The proposed system should receive a customer request, check the required information, assign the work, collect evidence, record a decision, generate a document and pass an approved charge to finance.

The business can describe that process in a workshop. Staff can list fields, statuses and reports. The team can produce wireframes and a delivery estimate. Those steps are useful, but they cannot answer every question.

Will customers understand which documents they need to provide? Can an installer complete the evidence journey on a phone? Does operations need one status called review, or are there three distinct decisions hiding behind that word? Can finance trust an approved charge without opening every attachment?

An agile approach turns those questions into a sequence of small delivery decisions. The team still keeps a goal, a budget boundary and an outline of the wider system. It simply avoids pretending that every detail is equally certain on day one.

02

One complete journey beats ten finished tasks

The first cycle should not be chosen by asking which screens are easiest to build. It should create the smallest complete journey that teaches the team something important.

For the installer portal, a useful first journey might create one customer request, check whether the required details are present, assign an owner, show the customer and staff the current status, and keep a simple history of what changed.

That journey crosses the interface, permissions, data model and workflow. A member of staff can try it with a realistic example. The team can see whether the language, ownership and status rules make sense before adding document generation, finance integration and reporting.

Compare that with completing ten disconnected tasks: build a login screen, create four database tables, add an email template, design a dashboard shell and install a chart library. Every ticket may be marked done, but nobody can complete a useful piece of work.

Scrum, one well-known agile framework, calls the usable result an increment. The Scrum Guide says an increment should be verified, work with earlier increments and be usable. It also uses a shared Definition of Done so the team knows what completed work actually includes.

For a business application, done may mean more than code merged into a repository. It may require:

• the important business rule is enforced on the server;
• permissions have been checked;
• the journey works on the devices people actually use;
• automated and manual tests cover the agreed risk;
• errors are visible and recoverable;
• data changes can be understood;
• the feature can be deployed safely;
• the person responsible has accepted the result.

The exact list will change between products. What matters is that it remains clear. If testing, accessibility, migration or deployment are always left until later, the team is not producing small finished increments. It is producing a growing pile of nearly finished work.

03

Feedback has to change a decision

Short cycles only help when somebody uses the result to make a decision.

A sprint review that consists of developers demonstrating whatever they happened to finish can become a polite status meeting. People watch, say it looks good and return two weeks later to repeat the ritual. The project has a feedback ceremony without a feedback loop.

Useful feedback is connected to the goal of the increment. For the first portal journey, the team could ask:

• Did staff know who owned the request?
• Could they tell why a request was incomplete?
• Did the customer-facing status use language a customer would understand?
• Which exception forced somebody back into email or a spreadsheet?
• What should change before this journey supports more users or volume?

The answers should affect the backlog, design, rules or release decision. If the review cannot change anything, it is reporting rather than learning.

That also explains why the right business person needs to stay involved. A developer can identify a technical edge case. They cannot decide whether finance should receive a charge at approval or after the certificate has been sent. A manager can describe the intended policy. The staff doing the work can show where the policy and daily reality disagree.

Collaboration does not require the whole company to attend every conversation. It needs one person with authority to make product decisions, access to the people who understand the work and a predictable way to answer questions before the team builds around a guess.

04

The backlog is a queue, not a promise

Once people see working software, they usually have more ideas. That is healthy. It is also where an agile project can lose control.

A backlog is an ordered list of possible work. It is not a commitment to build every item. If every request is added permanently, the list becomes a storage cupboard for old thoughts rather than a useful description of what matters next.

Each item should compete against the current product goal. For the installer portal, improving missing-document feedback may remove daily chasing. Adding six dashboard themes probably will not. Both may be valid ideas, but they do not have equal value now.

When a new request appears, ask:

• Which user or business problem does it solve?
• What evidence says the problem is worth solving now?
• Does it support the current goal or interrupt it?
• What work should move down if this moves up?
• What is the smallest change that could test the idea?

The fourth question protects the budget. Agile does not create infinite capacity. Changing the priority is reasonable. Pretending it has no effect on time or cost is not.

For fixed commercial work, I prefer explicit boundaries. The project can have an agreed first outcome, budget and decision points while the detail inside those boundaries is refined. If learning reveals a genuinely new need, the customer can replace lower-value scope, approve another phase or stop with a useful result.

That is more honest than calling every new idea agile and quietly moving the finish line.

05

Agile does not remove technical discipline

Frequent delivery exposes weak engineering quickly. That is a benefit only if the team responds to what it sees.

Automated tests make it safer to change a workflow that already has users. Continuous integration can check each change before it joins the main codebase. Repeatable deployments reduce the number of launch steps living in one developer's memory. Monitoring and useful logs show whether a released increment behaves as expected.

Architecture still matters too. A team should avoid designing five years of hypothetical scale, but it must protect the data, permissions and boundaries the current product depends on. A quick first release that mixes customer records, internal notes and finance rules without clear ownership will not become safe merely because it arrived in a two-week sprint.

Documentation also remains useful. The right amount may include:

• the product goal and important business terms;
• decisions that would otherwise be argued again;
• external API behaviour and data ownership;
• deployment, backup and recovery instructions;
• important security and privacy rules;
• enough context for another capable developer to continue the work.

Agile values working software more than comprehensive documentation. It does not value mysterious software that only its original developer can operate.

The same applies to design. Prototypes can test uncertain journeys before production code. A simple architecture note can expose a dangerous integration assumption. A short discovery phase can show that an existing product solves the problem without a custom build. These activities reduce waste when they answer a real question.

06

Choose a rhythm that fits the work

Agile is a broad set of values and principles. Scrum is one framework for applying them. Kanban is another approach that helps teams see work, limit the amount in progress and improve flow. Neither label should be chosen because a board template happens to exist in the project tool.

Scrum can fit a product team able to work towards a clear goal in fixed cycles and review a usable result regularly. Its defined accountabilities and events create a rhythm for planning, inspection and improvement.

Kanban can fit support, maintenance or mixed incoming work where priorities change more continuously. Limiting work in progress is particularly useful when a team starts many tasks but waits on reviews, information or deployment before finishing them.

Some small projects need less ceremony. One developer and one business decision-maker may work well with a prioritised list, weekly demonstration, clear acceptance checks and regular releases. Calling every conversation a formal event would add theatre without adding control.

There are also projects with fixed compliance evidence, contractual milestones or physical dependencies. They can still learn iteratively, but the team must keep the required governance and documentation. Agile should make risk visible earlier. It should not be used to wave away obligations.

The GOV.UK Service Manual treats agile delivery as more than a development board. Its guidance covers user stories, priorities, roadmaps, governance, progress and the complete service lifecycle. That wider view is useful for commercial systems too. Software has to be planned, built, operated, improved and eventually replaced or retired.

07

What a business should expect from agile delivery

The business does not need to become an expert in agile terminology. It should be able to see how the approach makes the investment easier to understand and steer.

A healthy project should provide:

• one clear product or phase goal;
• a visible, ordered list of possible work;
• small usable increments rather than disconnected activity;
• regular access to working software;
• decisions based on real feedback and evidence;
• a shared meaning of done that includes quality;
• transparent effects when scope or priority changes;
• technical ownership beyond the first release;
• clear points where the business can continue, change direction or stop.

Return to the installer portal. The business began with a large idea covering requests, evidence, approvals, documents, finance and reporting. Agile delivery does not make that complexity disappear. It gives the team a safer order in which to learn about it.

The first useful journey proves whether requests can enter the operation clearly. The next increment can add evidence collection. Another can test approval and certificate generation. Finance integration follows when the charge and ownership rules are understood. At each stage, the business sees working software and chooses what deserves investment next.

That is the real value of agile development. It replaces one large moment of hope at the end with a series of smaller, better informed decisions.

If you are planning a new portal, workflow or business application, bring me one complete journey your users need to perform. I can help clarify the goal, prototype the uncertain parts and shape a delivery plan that produces useful software without losing control of scope, quality or ownership.