News

Agile Software Development: Process and Limits

29 October 2026 · DigifyNow

Auf Deutsch lesen

In agile software development you don't fix the full scope up front. You keep a prioritized list of requirements called the backlog. In short, fixed cycles, the team builds the most important items as working software. It then demos the result to the people who will use it and plans the next cycle. You steer through the backlog order. Time and budget per cycle stay fixed, and scope is what moves.

What is agile software development?

Agile software development is an umbrella term for ways of working where software gets built in short, repeating cycles. At the end of every cycle you have a piece that actually runs. It isn't one single method. It's a mindset, and several methods grew out of it, such as Scrum, Kanban and Extreme Programming. The opposite approach is the classic waterfall model, where you start with a complete requirements specification and nothing gets built until that spec has been signed off.

The real difference is when you learn something. With waterfall you only see the software at the end, which is when a wrong assumption from the planning phase costs the most to fix. With agile you see something working after every cycle and can change direction before much has been built on top of it. Here's an example. A trades business wants a digital job management system. Done the agile way, the team first builds only the ability to create a job with a customer and a date, and two dispatchers try it out in their daily work. Only once that holds up do material lists, job site photos and the handoff to invoicing follow. If the dispatchers notice along the way that they mostly create jobs while on the phone, the input screen gets reworked before anyone has written the invoicing integration.

What are the values and 12 principles of the Agile Manifesto?

It all goes back to the Manifesto for Agile Software Development, published in 2001 and available at agilemanifesto.org. It lists four values, each one a matter of weighting: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The manifesto says explicitly that the items on the right still have value. So documentation and contracts aren't thrown out. They just carry less weight. On top of that come twelve principles, summarized here in plain terms:

1. Satisfy the customer early and continuously with software they can use.
2. Welcome changing requirements, even late in the project.
3. Deliver working software at short intervals.
4. Business people and developers work together daily throughout the project.
5. Build projects around motivated people and trust them.
6. Face-to-face conversation is the best way to share information.
7. Working software is the primary measure of progress.
8. Keep a pace the team can sustain indefinitely.
9. Pay continuous attention to technical quality and good design.
10. Simplicity: maximize the amount of work not done.
11. The best solutions come from self-organizing teams.
12. The team regularly reflects on how to get better and adjusts accordingly.

How does an agile development cycle actually work?

The methods use different names, but a cycle is almost always structured the same way. In Scrum a cycle is called a sprint. Its length is set up front and doesn't change after that.

1. Fill the backlog: collect requirements as short descriptions from the user's point of view, for example: As a dispatcher, I want to assign a job to a technician so he can see it on his phone.
2. Prioritize: one person on your side decides the order. In Scrum this role is called the Product Owner. Without that person, nobody decides what comes first.
3. Plan the cycle: the team takes only as many items from the top as it can finish within the cycle. Finished means tested and working, not just coded.
4. Build and sync daily: a short daily meeting surfaces whatever is blocking an item right now.
5. Review: the result is demoed in real software, not on slides. Your feedback goes into the backlog as a new or changed item.
6. Retrospective: the team looks at how it works and commits to one concrete change for the next cycle.

As the client, step 2 is your main lever. Whoever sets the order of the backlog also decides what's finished at the end when the budget is limited. How a commissioned project runs from first inquiry to final acceptance is covered in the article Custom software development: how a project runs.

What's the difference between Agile and Scrum?

Agile is the mindset from the manifesto. Scrum is a specific framework that puts that mindset into practice with fixed rules: three roles (Product Owner, Scrum Master, Development Team), sprints of a fixed length, and set events like planning, review and retrospective. Every Scrum project is agile, but not every agile project uses Scrum. Kanban, for example, has no sprints at all and instead limits how many tasks can be in progress at the same time.

What are the 5 phases of software development, and what does agile do with them?

Software development, meaning the planning, coding, testing and running of software, is often split into five phases: requirements gathering, design, implementation, testing, and operations and maintenance. In waterfall these phases run once, one after the other, and each ends with a document that releases the next. In agile software development the phases don't disappear. They run in miniature in every cycle: for the top three backlog items, the team clarifies, designs, builds, tests and ships. That leads to a technical requirement people often underestimate. If every cycle is supposed to deliver something working, testing and deployment have to be largely automated. Without automated tests, the testing effort grows with every cycle, because everything built so far has to be retested by hand. AI tools now speed up the coding, but they don't replace the testing. What they really do for code is covered in the article AI software development: what AI actually does for code.

When does agile software development not work?

Agile doesn't run itself. Most problems have a clear, recognizable cause:

• Nobody on the client side has time: without someone who prioritizes and shows up for reviews, the team builds based on its own assumptions. At that point it's waterfall without a spec.
• The requirements are fixed: with a legally mandated reporting interface, or when rebuilding an existing form, there's little to learn. A clear plan is often the shorter route there.
• Agile as an excuse for not planning: agile still needs a goal, a rough architecture and an idea of the overall scope. Otherwise the backlog grows faster than the team can work it down.
• Done isn't really done: if items count as finished before they're tested, bugs pile up and later cycles get eaten by rework.
• Rituals without results: daily meetings and retrospectives that lead to nothing cost time and change nothing.
• Dependencies on third parties: if access to the ERP system or sign-off from IT takes weeks, even the shortest cycle won't help.

Can you do agile development on a fixed price?

Yes, but not the way people usually expect. A fixed price for a fixed scope contradicts the whole idea of changing scope during the project. Two patterns do work. The first is a fixed budget with flexible scope: through the backlog order, you decide what gets built within the budget, and whatever no longer fits is dropped on purpose. The second is small, self-contained packages, such as an MVP with a clearly defined core function, where a fixed frame is agreed before the next package is planned. With both patterns, what matters is acceptance against written criteria for each package. Whether that's legally closer to a contract for work or a service contract is best clarified with your legal counsel. What actually drives the effort, namely scope, integrations, data migration and operations, is broken down in the article Software development cost: what drives it.

Software development agency in the Westerwald: what to look for

If you're looking for a software development partner in the Westerwald region, pay less attention to the word agile in the proposal and more to how the work actually gets done. Questions you can check in the first meeting: Will I see working software in a test environment after every cycle? Who maintains the backlog, and can I look at it any time? How is done defined? Who owns the source code? Who looks after the system after launch? Being close by helps with workshops at the start and with reviews involving employees who rarely sit at a screen, for example in the workshop or the warehouse.

DigifyNow is based in Unnau in the Westerwald region of Germany and works nationwide, with a focus on the Westerwald, Koblenz and Siegerland. The team builds custom apps, web apps and software for small and mid-sized businesses. It starts with an MVP that contains only the core function, which is then developed step by step into a running system. One example is the custom back office with CRM for Mundo Marketing. For an overview, see DigifyNow's services, and the page on software development in the Westerwald describes the regional work.

When outside help makes sense

Outside help makes sense if you need software that doesn't exist as an off-the-shelf product and you don't have an in-house development team. It also makes sense if a running project hasn't produced anything usable after several cycles. It doesn't make sense if existing software already covers most of your process. Bring these to the conversation: the process the software should support, the systems it needs to exchange data with, a person who's allowed to set priorities, and a rough budget range. In a free, no-obligation assessment of your project, DigifyNow works out whether custom development is a good fit, and in what shape.

Request a free assessment of your project