5 ways to shorten development cycles

To get straight to the point: The waterfall no longer exists. Today, development takes place iteratively, in cycles. There are major differences in the length of development cycles: a cycle can be many months long, or a week or less.

The scope of the cycle can also vary considerably: In some developments, only a few cycles include a functioning product at the end, while in others there is already a minimal functioning product (MVP, Minimal Viable Product) at the end of the first iteration.

This article analyzes why short development times are desirable and how we can shorten them.

Why short development cycles are desirable

Long development cycles have a number of disadvantages:

• System development as a whole takes longer
• Long response times for changes
• Problems found during development delay development
• Improvements and requirements discovered during development are implemented late or not at all due to time constraints

These disadvantages can result in a competitor simply overtaking you and can therefore threaten your existence.

Shorten development cycles

Unfortunately, it is often not possible to simply shorten development cycles. Besides cultural problems (which I will come to in a moment), there are the following two problems:

• Dealing with changes: Even with simple products, there are many dependencies during development that need to be managed properly: The implementation depends on the system requirements, which in turn depend on the user requirements. There are also dependencies on tests, and test results can be out of date. In a waterfall, this problem is supposedly avoided by going through each stage only once. Without proper requirements management, the team will try to go through as few iterations as possible.
• Compliance: In developments with functional safety, proof of compliance must be provided with regard to risks and safety. This cannot be done at the end, as the risks must be taken into account from the outset. As the effort required for verification is generally high, attempts are made to carry it out as infrequently as possible through long cycles.

Cultural and human aspects

From the above, we can already guess what one of the big problems for people is: people want to do productive work - or rather: they want to develop products, not maintain changes or repeatedly carry out analyses. Although it is recognized that this work is important, it is still not fun.

People want to do productive work! [tweetthis]People want to do productive work![/tweetthis]

And this brings us to the answer to the question: in order to shorten the cycles, the effort for the "boring" work must be minimized (it would not be fair to describe this work as "non-productive"). This is a good compass - here are the concrete approaches on how this can be realized:

In order to be able to react competently to changes fine granular be worked with. This means that each element (requirement, design element, test, etc.) must be independent. These elements can then be linked together in a meaningful way, as described above. These structures make it possible to react to changes to individual elements in the first place. A professional tool is used for this purpose. Such a tool must be able to draw and compare baselines, analyze the effects of changes (impact analysis) and much more.

It is important not to overestimate a tool; there must be appropriate methods and processes. However, without appropriate tool support, these can hardly be implemented efficiently.

One problem with iterative work is when copies are created for each iteration: It must always be clear what "the truth" is. Important: truth does not necessarily mean "current status". This is precisely the problem with the waterfall: it is often only practiced because it allows the current state and the truth to be the same thing. Only if we allow ourselves to work with potentially outdated data can we continue to work without waiting. Thanks to a fine-grained data model, only individual elements may need to be updated. However, it becomes dangerous if work is carried out on outdated data without being aware of it.

In order to be able to work in short iterations, it is important to understand the development. To do this, we must communicate. There is a reason for changes, and nothing is more frustrating than not understanding that reason. So if, for example, a decision is made to reduce the capacity of the battery, then it must be clear why this is the case: was the running time too short, or has a large consumer been added? The answer to this question should not be buried in an email. Incidentally, this would also be a problem for compliance, as the documentation of decisions is often required. Instead, the decision should be part of the data storage ("single source of truth").

The data model must as simple as possible and only as complicated as necessary. As a consultant in requirements management, I have seen systems where requirements had dozens of attributes. This is a real problem if they are not maintained. Because outdated (incorrect) information can be more dangerous than non-existent information. Incidentally, this applies not only to attributes, but also to the number of element types and the relationships between them.

Information that is not maintained is worse than missing information [tweetthis]Information that is not maintained is worse than missing information[/tweetthis]

If the data model is too complicated, the fear quickly arises (and rightly so!) of not understanding the effects of changes. And then we shy away from short development cycles.

As already mentioned, we don't like doing tasks that have nothing to do with our "actual" work. We have already described ways of making these as painless as possible. But it is even better to avoid them completely.

The pioneer in automation is software development, which has been working with "build automation" for many years. But also in the A lot of system development can be automatedand this in turn shortens the duration of development cycles and increases the acceptance of shortening them.

What this looks like in practice depends on the specific project (and industry). It is also important not to go overboard: The benefits of automation must be clearly recognizable. Transparency in development must not be lost as a result.

Conclusion

The five tactics described here can be used in many situations. And what is almost more important: if a sensible tool is already in use, they can be applied in small steps to accelerate system development step by step.

Image source: Michael Jastram