Wednesday May 24th 2023

For some, Agile working seems synonymous with “hacking” or sloppy engineering where corners are cut. With complex software systems, we see that it frequently causes problems: software that is delivered late, without the desired quality. Internal and external clients no longer understand what they receive. Recognizable? In this article we address these issues and explain what can help well when developing complex systems in an Agile way.

Why work Agile

Many companies have embraced Agile working these days. We see that in larger organizations the use of the Scaled Agile Framework (SAFe) is popular. Inspired by the Manifesto (see below for more information), an Agile way of working and structuring the organization has emerged. For example, in SAFe the work over the year is divided into four so-called increments, which in turn are divided into so-called sprints of typically 2-3 weeks. The goal is ideally to deliver working production-ready software after each sprint, integrated across all Agile teams.

To be clear in advance, we are fans of Agile and we do it ourselves. There are several good reasons for companies to make this Agile transition:

  1. The organization wants to improve collaboration between different departments. The aspects of Agile bring different disciplines closer together.
  2. The need for insight into status and progress so that adjustments can be made earlier. By working in sprints, there are interim moments where adjustments can be made.
  3. The desire to deliver faster. More and more often to production because the market asks for it. By introducing a cadence, more frequent releases are possible.

Practice often proves more unruly than theory. Regularly, aspects of development do not fit into sprints or increments. A classic example are the special sprints for testing, integration or acceptance.


A common complaint is that Agile cuts corners in the development process just to fit everything into sprints and increments. The statement, “Agile is hacking” is an example of this. To see where that comes from, let's go back to the original Manifesto that Agile once started with in 2001(!):

At the time, the Manifesto was a reaction to the waterfall method of software development that emphasized precisely the things on the right in the above Manifesto. In the desire and Agile drive to fit the work into the sprints anyway, we now see just the opposite: the things on the right are not being filled in adequately. In particular we see cuts in documentation like requirements and specifications, but also in contract matters, like agreements with clients, and in global planning. We think this is a bad development. Agile changes the way of working, but the complexity of the product and IT solution does not change. In addition, the right-hand side is there for a reason. Something the makers of the Manifesto acknowledge: “there is value in the items on the right.”

Importance of documentation

Agile or not, it is important that the delivered software does what it is supposed to do. Structured and good documentation of requirements helps enormously. This way, requirements and specifications are readable and reusable for others during development and, equally importantly, also during maintenance. When you can document them unambiguously, you make it easier for those who have to develop, test and verify the product. This allows you to be transparent to internal and external clients: you show that you understand each other, and you can have a conversation about the content (do they receive what was promised).

We often hear “But this is what we do with Agile, right? We document everything on a Kanban board during sprints. And documentation is outdated, it is not read anyway!” Documentation during sprints, however, is volatile project administration and really below par for product administration (not up to date, consistent and unambiguous). After the end of the sprint, it is difficult, if not impossible, to regain an integral view of the product.

And yes, documenting well is indeed difficult. Unambiguous documentation is not all-encompassing, but just right and enough. Too little, then you leave too much to interpretation. Too much takes unnecessary time and may make it too complex.

What works?

One method that works and fits very well with the Agile way of working is model-based working. SAFe also recommends this under the name MBSE (Model-Based System Engineering). A similar approach is MDD (Model Driven Design).

In this case, the documentation of requirements and specifications takes place iteratively in a model (examples are UML or SysML). This is a design artifact of the product that persists beyond the project. Based on this model, the developer builds the software, and the tester devises the tests. By creating this Single Source of Truth, changes can be made quickly, which can then be easily processed by the developers and testers.

The Axini platform supports MDD/MBSE (including Behavior Driven Design). An important benefit is that our platform generates and executes test cases automatically. Test cases are generated from the model and using an adapter they are executed fully automated and very thoroughly against the system under test. Test cases and results are recorded and clearly displayed, and thus suitable as an audit trail. Coverage and version management are excellent to use as evidence to release to production with confidence.

Want to know more about how to work fully MBSE supported Agile with the Axini approach? Contact us or follow us on LinkedIn.