Agile software development: developers and controllers belong around the table

By: MRT Desk

Published on:

Agile software development: developers and controllers belong around the table

Classic controlling and agile development methods come from different worlds, but basically pursue the same goal: plan software development projects in detail and manage them flexibly. In practice, however, the interaction often proves to be difficult due to the different approaches. Too often, effort and costs get out of hand, even though the coding takes place in small, agile steps and, thanks to regular meetings, apparently every problem is discussed. What is going wrong and how can this be prevented?

Both project managers and developers know that projects of any type and size benefit from solid planning. However, the respective approach is quite different. The requirements come from different directions, and last but not least, opinions differ as to when a result can be rated as good. This often leads to a confusing situation – a look at the details reveals why.

Agile development methods have significantly changed the way software is developed in recent years. Even if Scrum Masters and Agile Coaches are not solely responsible for structuring development projects in every company, software development driven by major releases is rarely found in business practice. And there are good reasons for this: Agile methods are more efficient, more transparent and lead to usable results more quickly.

Essentially, it is about using iterative steps, code reviews and tests to identify potential sources of error earlier and to take appropriate countermeasures. At the beginning, project visions are clearly formulated, requirements are cataloged and tasks are prioritized. In regular meetings, the team discusses as many details as possible of the projects broken down into smaller pieces – from acceptance criteria and integration requirements to implementation difficulties.

Why does it still happen that those responsible often only recognize budget and time bottlenecks late in the course of the project? The problem is usually not with the development, but rather with its insufficient integration into the overall project. Because while DevOps initiatives try to closely interlink development and operation at an early stage in order to incorporate later operational requirements into the development process from the beginning, corresponding initiatives on the business side are rarely found. In other words: Today, developers usually design software with a clearly defined scope, tailored to customer requirements. However, they rarely sit at the planning table right from the start – although that would make sense, because their assessments and preferred approaches can have a decisive influence on both time and cost plans. Too often, the desired feedback is limited to the number of sprints required. However, this does not go far enough, because software development is a creative process that is difficult to plan or press into tight specifications – at least not if the demands on the quality of the software are high.

It is inevitable that software projects will pile up technical debt over time. Due to the project goal and speed, full test coverage, automated testing, fully automated main deployments and a clever architecture as well as the smooth orchestration of updates of all components cannot always be guaranteed in the process despite convincing advantages. In order to stabilize a rapidly growing project later, such tasks inevitably have to be made up for.

Since technical debts cannot be avoided, it is important for controlling to price them in and take them into account in regular and medium-term planning. Ideally, those responsible for the project should give developers regular sprints to clear the mountain of debt. If you don’t do this, you risk an increasingly unstable system that is more difficult to change and expand. The more consistently and more liberally the controlling handles technical debts, the more efficiently the development team acts in the long-term course of the project. Problems that arise can be eliminated without throwing the entire project off track.

Developers have long been responsible for ensuring that customers get the features they want in the form they want. The agile approach includes the early and continuous delivery of software, openness to change requests in every project phase – if these are advantageous for the customer – constant consultation with all those involved, such as the specialist departments that commissioned the software as customers.

In practice, however, development teams are usually only involved later in the process, so that they often get the feeling that the planning is done from above and that the customers can ask for what they want – because, after all, they pay for it. Under such conditions, developers who are committed to agile methods tend to only do their job according to the regulations and to work through all tasks bluntly. This usually leads to frustration and unsatisfactory results.

The most important consequence of these considerations is to fully involve the development team from the start. If those who are supposed to implement the project are already jointly responsible for time and budget planning, the framework conditions for the implementation phase are clearer. In this way, the findings of the agile meetings of the dev team can also flow back into the overall planning. If, for example, the challenge arises of adding further sprints or code reviews or having to resolve unforeseen incompatibilities, the entire project can be delayed. However, if the feedback from the development team takes place directly with those responsible for business, adjustments can be made immediately or at least rescheduled in good time.

Article Source