Software Development Process

A new product, an inherited application and a critical repair do not begin with the same questions.

We look at what people need, what the business is trying to achieve, what already exists and what cannot be interrupted. We examine constraints without assuming that the first description of the problem is the complete one.

Design Thinking provides the broader approach to inquiry: understanding people and context, framing the problem, exploring possibilities and learning from what we make. Delivery methods help organize the work within that inquiry. They do not replace it.

Desirability, technical feasibility and viability remain connected considerations. A desirable idea may need a smaller first implementation. A technically impressive option may be difficult for the client to operate. A constrained existing system may still be the right foundation for the next stage.

We make those tradeoffs visible rather than present one method or technology as the answer before the situation has been understood.

Clarity does not require pretending that everything is already known.

Some work should deliver a usable capability. Some should investigate an uncertainty. Some should establish the conditions for a responsible release. Those are different outcomes, and confusing them makes progress difficult to judge.

We agree priorities, responsibilities and acceptance conditions at a useful level of detail. Who can clarify a business rule? Who reviews the experience? Who makes a decision when cost, timing and scope conflict? Which dependencies sit with another vendor or team?

The client retains authority over their business decisions. Abstraction brings design and technical judgment, helps surface consequences and works with the people best placed to contribute. Where specialist partners are involved, their responsibilities should be equally clear.

A shared record of decisions helps the team remember not only what was chosen, but why—and what would justify revisiting it.

When a wholesaler is preparing a customer portal for a trade show, we bring the deadline and the uncertain dependencies into the same conversation. What must the first release make possible, and what do we still need to establish before promising it?

The business wants visitors to browse products and place orders against current stock. Product information is available, but the team does not yet know whether the inventory connection can provide dependable availability under the required conditions.

We would identify that uncertainty early and test a representative exchange. Does the connection expose the right records? How current are they? What happens if the service is unavailable? Can the implementation distinguish available stock from a quantity that has already been committed?

A successful demonstration would establish something useful about the tested path. It would not, by itself, establish production readiness.

If dependable ordering cannot be responsibly delivered before the event, a bounded first release might support product exploration and clearly identified quotation requests. That is only a useful alternative if it serves the business and honestly describes the customer’s action. A request must not look like a confirmed order.

The team can then compare choices: reduce scope, change timing, use an agreed staff-assisted workflow or reconsider the dependency. The process has created a decision while there is still time to make it.

We use a combination of approaches according to the situation, rather than require every project to adopt the same ceremony.

Agile Development emphasizes learning and adaptation through working increments and collaboration. The Agile Manifesto values those qualities without declaring documentation, tools or plans worthless. In practice, adaptation still needs understandable priorities, evidence and agreements.

Scrum provides a particular framework for organizing product work. A team adopting selected practices should describe that honestly rather than claim the whole framework. Kanban helps make work visible, manage simultaneous commitments and examine how work moves through a system. It can be useful for continuing improvements and support as well as project delivery.

A Waterfall approach organizes work through sequential phases and defined handoffs. It may suit circumstances where requirements and dependencies can be established with sufficient confidence and formal review points matter. The concern is what happens when later learning changes an earlier assumption; a phase plan still needs a way to examine and manage that change.

Hybrid arrangements combine structures deliberately. A project might need a fixed external approval or migration window while the implementation within it develops iteratively. Having phases alone does not make a project Waterfall, and holding frequent meetings does not make it Agile.

The important question is whether the arrangement helps this team make sound decisions and deliver useful work.

A status report should tell the team more than how busy everyone has been.

Reviews can show working behavior, clarify a decision, reveal a limitation or make an emerging risk understandable. A prototype, technical experiment and production feature should be identified for what each actually establishes.

We test as we develop, with development, testing and production responsibilities appropriate to the project. Acceptance includes the relevant experience and operating conditions, not simply the presence of a feature. Permissions, error handling, data integrity, accessibility and recovery may all change what “ready” needs to mean.

Software Testing and Quality Assurance connects those questions to evidence. Deployment and Release Management addresses how an accepted change reaches use, how it is checked there and what options exist if the release needs intervention.

The depth of review should reflect risk. A wording correction and a change to how orders are recorded do not need identical release arrangements.

New information can improve a project. It can also affect effort, cost, timing and earlier commitments.

We distinguish a clarified requirement, a defect, a newly discovered constraint and an additional capability. Those distinctions make the next conversation fairer and more useful. They help the team understand what changes, what remains committed and what should be deferred.

Not every useful idea belongs in the current release. Deferring it should preserve the reasoning, rather than require the team to rediscover the same conversation later.

Scope control and curiosity are not opposites. Clear boundaries can make exploration more purposeful because the team knows which question it is trying to answer.

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

These are connected modes of work, not a promise that every engagement moves through identical stages once. A test can send us back to a definition. A live service can reveal a need that was invisible in discovery. Marketing may contribute to how a product is understood and adopted where the engagement calls for it.

The process should carry that learning forward. Product Intelligence brings the developing understanding of the product into future decisions. Workbooks, operating guidance and technical records help the client use and evolve what has been delivered.

A project can have a clear completion point while the product continues to develop. Ongoing Continuous Improvement and technical care are agreed relationships, not an implication that every project remains open indefinitely.

If you are planning new software, improving an existing system or trying to understand how the work could move forward, Contact Us. You do not need every answer before we begin. Part of working together is making the right questions—and the decisions they lead to—clear enough to act on.