TRINIDAT-WIKI
Agile software development in practice
Staying on track when requirements change
A software project can be meticulously planned and still fail in practice. Acceptance testing goes smoothly, the deadline is met, and the features are delivered. Then, in operation, reality sets in: a process runs differently than anticipated, a user interface doesn’t fit the workflow, or an interface creates extra work. From that moment on, every correction becomes costly because it requires deep changes to data, business logic and processes.
Agile software development comes into play precisely here. It often seems slower at the start because it demands clarification, acceptance and quality early on. Later on, it saves time and reduces risk because misconceptions are spotted sooner and changes remain easier to implement.
In the past, many projects fitted into a phased model. Requirements were gathered, then implemented, then tested, then handed over to operations. With more interfaces, more dependencies and more frequent changes, this pattern became less reliable. An iterative approach became more important because it tests assumptions earlier and makes course corrections more cost-effective.
trinidat has a clear stance on this: hybrid, where it makes sense. A stable framework ensures reliability. The parts requiring learning are developed incrementally, with early feedback and clear acceptance.
What does agile software development mean in the day-to-day running of a business?
Agile software development describes a way of working in which a product is created in small, usable increments. Each increment produces a result that can be tested, used or realistically assessed. Planning remains central to this process; it is carried out in stages and is guided by benefits and risks.
Agile software development means: delivering in short increments, jointly accepting the work after each increment, and managing priorities based on benefits and risks.
Three characteristics feature in almost all reputable agile approaches:
- Short delivery phases: Work is divided up so that usable parts are completed on a regular basis.
- Regular feedback: Business stakeholders and development teams jointly assess whether the result meets requirements.
- Close collaboration: Questions are clarified early on, and decisions are made transparently.
Why does agile development feel slower at the start?
Many teams start by ‘building’. Agile teams start by ‘understanding’. This approach takes a noticeable amount of time at the start, but it pays off later.
Typical reasons for the perceived slow start:
- Terms and rules are clarified: What do “customer”, “order”, “approval” and “credit note” mean in the specific process?
- Acceptance is defined precisely: What counts as completed, and how can this be clearly identified?
- Quality is built in: Tests, clean interfaces, traceable data flows.
The results become apparent later on. Fewer rollbacks, fewer discussions about misunderstandings, fewer surprises just before deployment.
Which misunderstandings cause the most problems?
Agile working rarely fails because of a lack of tools. It often fails because of unrealistic expectations.
“Agile = chaotic”
Chaos arises when decisions are not made. Agile working requires clear roles, fixed deadlines for coordination and a visible sequence of tasks.
“Agile = no planning”
Without planning, there is a lack of direction. Agile planning works with phases, clear priorities and traceable commitments for each step.
“Agile = faster at any cost”
Speed without quality takes its toll in practice. This leads to an increase in errors, rework and downtime due to disruptions.
How can an agile project remain on track in terms of budget and deadlines?
In agile projects, predictability is achieved through transparency and clear acceptance criteria for each sprint. Each sprint delivers a result that can be evaluated. This allows decisions regarding scope, sequence and budget to be based on facts.
In day-to-day practice, predictability is demonstrated by three things: a clear commitment to the next sprint, visible risks, and acceptance criteria based on verifiable criteria.
Five building blocks help in day-to-day work:
- Product goal and value proposition: What should be measurably better in the end?
- Prioritisation by value and risk: What delivers benefits quickly, what reduces risks early on?
- Short acceptance cycles: Every delivery undergoes a clear review by the business side and operations.
- Definition of Done: A completed step includes testing, documentation and operational readiness.
- Making open issues visible: Blockages, risks and outstanding decisions are clearly laid out on the table.
What are the benefits of bespoke business software?
Custom business software has a long lifespan. It evolves alongside business logic, interfaces and changing processes. Its true value unfolds over the years. The go-live marks the start of further development.
Agile development supports precisely this reality:
- Better prioritisation: Business benefits and risks determine the order.
- Earlier feedback: Useful interim results show whether we are on the right track.
- Fewer costly missteps: Assumptions are tested early on, before they become entrenched.
- Greater adaptability: A clean structure and tests reduce the cost of every enhancement.
- More stable operation: Quality is built in continuously, rather than being hastily added at the end.
Find out more about the benefits of bespoke software development.
What conditions need to be met for agile to work?
Agile working requires clarity and discipline. It requires fewer slides and more commitment in day-to-day work.
Key prerequisites:
- Clear goals: A shared understanding of the software’s purpose.
- Responsibility that applies in day-to-day work: Who decides, who prioritises, who signs off?
- Shared understanding of the business logic: Terms, data, rules, exceptions.
- Definition of Done: Done means checked, testable, documented and operational.
- Tests as standard: Tests run with every delivery, rather than only at the end.
- Rhythmic communication: Fixed deadlines, clear results, clear decisions.
Scrum or Kanban: Which model is best suited to which situation?
Both models can work effectively provided that objectives, acceptance criteria and quality standards are clearly defined. Hybrid forms are common in practice once development and operations run in parallel.
Scrum often works well when a team delivers in fixed increments and requires regular acceptance checks. This supports product development and major enhancements where a clear cadence is helpful.
Kanban often works well when work is organised as a flow. This supports ongoing development, maintenance and situations with frequently changing priorities.
The choice depends less on the name and more on the reality of the work: delivery phases with acceptance checks or a continuous flow with clear rules.
When does a hybrid approach offer greater security?
A hybrid approach is suitable when one part of the project appears stable and easily definable, whilst another part remains a learning process. In practice, this is often the case with enterprise software.
A hybrid framework might look like this:
- Stable part: Architecture, security requirements, data model fundamentals, interface framework, operational requirements.
- Flexible part: Business logic, user interfaces, process variants, exceptions, priorities derived from user feedback.
This creates reliability for the foundation and agility where genuine insights emerge during the process. This is precisely where the benefit of ‘hybrid, when it makes sense’ often lies.
In hybrid projects, we deliberately separate three levels: a stable framework for architecture, security and operations; clear interface rules for teams and systems; and a step-by-step implementation of business logic with short acceptance cycles.
Practical example: ERP extension for quotations and costing
Fictitious example for illustrative purposes.
A medium-sized trading company wishes to expand its ERP system with a quotation and costing module. The requirements seem familiar at first glance, but differences become apparent when examined in detail:
- Sales processes vary by location and team.
- Several departments provide data and rules.
- Pricing logic depends on discounts, promotions, seasonality and special cases.
- User feedback should be incorporated early on, as the module is used daily.
An agile approach starts with a core: a few, frequent quotation scenarios, clearly definable, with a stable data foundation and interfaces. This is followed by extensions based on usage, risk and feedback from operations. In this way, what delivers value and reduces risks is delivered first. Special cases come later, once the foundation is proven in day-to-day use.
In parallel, monitoring, support roles and a clear procedure for queries are defined to ensure operations remain stable from the very first version.
When does agile development fail, and what can be done about it?
Agile approaches come under pressure when there is a lack of structure and accountability. They also come under pressure when a project requires a stable scope with fixed acceptance criteria.
Typical situations in which a traditional or hybrid framework provides greater stability:
- The scope and requirements are very clearly defined.
- The contract and acceptance depend on detailed evidence that must be established at an early stage.
- Time and budget are tight, and changes need to be formally managed.
Even then, it is worth considering agile elements such as early prototypes, short testing phases and clear acceptance criteria. These elements reduce the risk of a result only being assessed against requirements at the very end.
Conclusion: Agile development manages risk and benefits throughout the product lifecycle
Agile software development is a disciplined approach to making decisions earlier and testing results sooner. It takes time at the start, but saves on rework, disputes and operational issues later on. Those who build enterprise software benefit above all from flexibility, quality and clear acceptance criteria. A hybrid approach works well when a stable framework provides security and the learning components are developed step by step.
FAQ on agile software development
What is meant by agility in software development?
Agility refers to the ability to deliver in small increments and respond to new insights. Planning remains a key element in this process; it is carried out in stages and is based on facts.
What is agile software development?
Agile software development is a methodology in which usable results are produced in short iterations. After each iteration, the team reviews the work together to ensure that the benefits, quality and direction are on track.
What are agile values, and how do they apply in everyday life?
The Agile Manifesto sets out four values that sharpen the focus on collaboration and results. Scrum describes five values that underpin teamwork in day-to-day practice (commitment, focus, openness, respect, courage). In projects, both serve primarily as guiding principles for decision-making once objectives, responsibilities and acceptance criteria have been clearly defined.
What is agile programming from the perspective of quality and operations?
Agile development relies on small, verifiable steps involving testing and proper acceptance. This improves stability and reduces the cost of subsequent changes.
When is a hybrid approach more suitable?
A hybrid approach is suitable as soon as one part of the project appears to be firmly established, whilst technical logic, user interfaces or process variants only become clear during the course of the project. A stable framework safeguards the architecture, security and operations.