Agile Development

Planning is how we make intentions understandable: what we are trying to accomplish, what we can afford, who needs to contribute and which dependencies may shape the result. Learning gives us a reason to revisit parts of that plan.

The Agile Manifesto gives greater weight to people, working software, collaboration and responsiveness without discarding tools, documentation, agreements or planning. It describes values, not a single prescribed project routine.

For us, the practical question is what should happen when new information makes the original plan less useful.

Software Development Process explains the wider working arrangement: priorities, decisions, review, change and release. Agile describes how useful working changes and learning can inform that arrangement, not a reason to leave commitments undefined.

We could discover that an elaborate comparison feature is less important than explaining delivery. We could find that employees need a clearer exception-handling process before a new customer feature can work well. We could learn that the existing system is more adaptable than anticipated and preserve it rather than rebuild.

Those are design and business decisions as much as development decisions. They deserve a conversation about the evidence, alternatives and consequences—not an automatic yes to every request or a refusal to reconsider anything already agreed.

A useful increment adds a coherent piece of capability. Iteration revisits and improves something. A project can need both: introduce an account-management function, then refine it after observing how people understand their permissions.

The distinction helps us avoid mistaking small tasks for meaningful progress. A finished database table may be necessary, but it does not by itself show a client how a customer will accomplish something. We need to make the connection between the underlying work and the experience it supports.

Sometimes the next useful thing is a prototype or technical experiment. Sometimes it is a working feature. We name the difference so nobody mistakes a demonstration with simulated information for software ready to carry real transactions.

The Agile principles connect regular working delivery with technical care, reflection and a sustainable pace. Reducing the size of a release should not mean quietly reducing the quality people depend on.

We can defer an optional comparison view. We cannot treat permissions, essential accessibility, transaction integrity or an honest explanation of what happened as decorative extras simply because the first release is small.

With a retailer extending its physical shop into online sales, we work together to find the first complete purchase journey worth releasing. Delivery, collection, gift messages, loyalty, subscriptions and recommendations can all have a place; they do not all need to arrive at once.

Before building all of it, we ask what would make the first online purchase genuinely useful. Customers need to understand a representative product, know how and when they can receive it, pay through an appropriate arrangement and receive a clear confirmation. Staff need the order information necessary to fulfill what was promised.

A bounded first version might offer collection for a selected group of products. The payment, stock and confirmation behavior would still need appropriate testing. Staff would need a workable way to handle unavailable items and contact the customer. A narrower offer is not the same as an incomplete transaction.

During review, someone on the shop team raises a concern: customers regularly misunderstand when an order is ready. That changes the next conversation. Rather than immediately adding loyalty rewards, we might give more attention to collection windows, preparation status and the wording of the confirmation.

The business can then weigh the choices. Does this resolve a more important problem? What does it displace? Does it affect the launch date or require further work outside the agreed scope? We make the tradeoff visible before treating it as an instruction to proceed.

After a suitably prepared release, we could examine customer questions, collection difficulties and the staff's experience. A handful of encouraging comments would not prove that every customer understands the journey. They would contribute to the next question, alongside other available evidence.

The first purchase journey gives the team something useful to learn from. What it reveals can change which feature deserves attention next.

“We can adapt” should be reassuring, not financially mysterious.

We need to distinguish refining an agreed requirement, exchanging priorities within available capacity, addressing a defect and introducing additional scope. They can all lead to development work, but they do not necessarily have the same effect on cost, responsibility or completion.

A useful change discussion explains what we learned, what we recommend and what would change if we act on it. If a date is fixed, we examine which outcomes can responsibly fit. If a particular capability is essential, we examine its dependencies and the investment it requires. Where neither can move, an honest limitation is more helpful than an optimistic promise.

Not every uncertainty belongs inside the implementation budget. A focused investigation can help establish whether an integration is feasible before a larger commitment. Equally, we should not repeat discovery that your team has already done well.

The client retains authority over business priorities and investment. We bring design and technical judgment, including the responsibility to explain when a proposed shortcut creates a consequence someone will inherit later.

You should know what you are being invited to consider when we show work. Are we reviewing the language? Testing whether a task makes sense? Examining a technical behavior? Deciding between two operational approaches?

That context makes participation easier for both business and technical readers. A developer may notice an integration assumption; a customer-service colleague may recognize a question that the current wording leaves unanswered. Neither needs to evaluate every detail of the other person's specialty to contribute something valuable.

We also consider who is missing. Stakeholder agreement does not automatically tell us how customers will experience the result. Research with intended users may be needed, with an appropriate scope and a clear account of what it can establish.

Reviews work better when questions are welcome before they become objections. If something feels wrong but you cannot yet explain why, that is still useful material to investigate together.

Abstraction works with combinations of planned cycles, continuously prioritized work and defined project phases. The arrangement should be understandable to the people participating, including those who already have an established way of working.

Scrum offers a particular framework around goals, responsibilities and repeated inspection. It is one way to organize development, not another name for Agile. Its page explains the difference between joining a formal Scrum team and drawing on selected practices elsewhere.

Kanban focuses attention on the movement of work, capacity and the conditions preventing completion. It can help illuminate ongoing work across content, design and development, including work within an existing framework.

Defined phases can also be useful when a project has external commitments, procurement decisions or release dependencies. A launch milestone does not prevent an earlier experiment, and a short development cycle does not remove the need to coordinate with the rest of the business.

We would discuss the choice through practical questions: how frequently can useful work be reviewed, who can make decisions, which uncertainties matter most and what happens when something urgent interrupts? A method's name is only the beginning of that explanation.

At Abstraction, Design Thinking is the broader practice through which we understand needs, explore possibilities and learn from the results. Agile approaches help us organize development within that practice; this is how we connect them, not a claim that one universally contains the other.

Discover → Define → Explore → Design / Develop / Market → Learn → Advance → Discover

The cycle can turn at different scales. An early interview may reshape the overall product. A working review may reveal a small but consequential interaction. Learning after release may send us back to an operational question that no interface change can resolve alone.

MVP Development considers the first useful version of a product. Agile Development concerns how we can continue making and learning, including on a mature system. An inherited product deserves the same attention to existing users, accumulated knowledge and the risks of changing something already in use.

Working software should come with the knowledge needed to operate and evolve it. Decisions, limitations, test findings and relevant instructions help the next person understand more than the final screen.

Living workbooks can explain changing workflows and editorial responsibilities. A decision record can show why a feature was deferred or a particular integration was chosen. Those records need a realistic place in the scope, with ownership for keeping them current.

Continuous Improvement carries learning beyond a completed phase. Ongoing collaboration can support that work, but it does not turn an agreed delivery into an indefinite project or make every new request part of a monthly fee.

If you are making something new—or trying to improve a product without losing what already works—we can help establish a way to move forward together. Bring the intention, the constraints and the questions. We can make the next step clear enough to take, and keep learning as it becomes real.

Contact Us