Time to Production: How much agility is good for software development?

Time to Production: How much agility is good for software development?

Agile methods can help to increase the productivity and quality of processes as well as of the developed software. A consideration of the success criteria.

Productivity is an important key figure in software development. It determines which software volume an organization can create with a certain amount of effort while adhering to certain quality criteria. We have already published several articles about our experiences with its measurement and optimization. However, high productivity in software development alone does not say anything about how quickly a new feature of an application can be used in production by users – the so-called Time to Production. My new series of articles deals with this topic.

Series of articles “Time to Production”:

  • How much agility is good for software development?
  • DevOps – agility in systems operation (soon on this blog)
  • DevSecOps – the deployment pipeline for secure software (soon on this blog)

What does “agile” mean?

Hardly any other buzzword has been used so misleadingly in the last 15 years as “agile”. Some wrong associations have persisted until today – for example: “Agile software development is Scrum”. This is wrong, because Scrum is one of many agile process models. In addition, due to characteristics such as time boxing (the end date of a sprint is fixed, only its scope is variable) and the lack of a project manager (there is only a Scrum Master, the moderator of a self-organizing team) it is probably rarely found in commercial order-based software development. Another myth is that agile software development is new or was invented with the Agile Manifesto. Approaches can already be found in Boehm’s spiral model described in 1986. Without doubt, however, the adjective “agile” in many sub-areas of software development stands for characteristics that are very conducive to the rapid delivery of new, functioning software.

Scrum: Just one of many agile process models

The agile organization structure

Our experience shows that agile teams with the least possible rigid roles and specializations are more productive and produce better quality. A cooperative responsibility for quality, an open approach to knowledge and a reward for team performance take the organization further than bottlenecks caused by the availability of individual experts. This is where the old wisdom that the team is more than the sum of its individual members proves true. The cooperation with the customer, client or product manager also proves to be critical for success. The closer the product owner is involved in the team’s work, the more target-oriented the fine-tuning can be: Decisions are made faster and late changes are avoided.

Automation is the key to continuous delivery

An important basic requirement for the rapid availability of a new feature are of course short development cycles – from the analysis of a requirement to the conception and the provision of the functioning code in the executable application. Many of the process steps can be easily automated with the tools available today. The keywords here are model-based development and code generation, continuous integration with automatic code analysis and automated functional tests with subsequent deployment on a near-production system. However, there are limits to automation, because only humans can decide how a technical feature is to be implemented in terms of the best user experience and how robust the implementation must be against unplanned use by a user or targeted attacks by a creative hacker.

Automation: The key to continuous delivery

Agile project management

In every development process, tasks must be derived from the requirements to be implemented, prioritized on the basis of their dependencies, risks identified and the processing of the tasks in accordance with the order must be controlled and managed. Our experience is that this is not an activity that should be left to a self-organizing team, but that it must be carried out by a project manager. Project management becomes agile through the clever use of tools. The use of a ticketing system such as Jira is particularly advantageous. Here, tasks are represented by tickets and the agents ensure the greatest possible transparency of the project progress by promptly maintaining the ticket status and the degree of completion and booking the required working time. The use of the pull principle has proven to be particularly useful, in which the processor “pulls” a new ticket from the set of open tickets (by changing the status) only when he has time to process it and the last ticket has been completed. A simple principle which – like many apparently new achievements of agile process models – is not really new: The Toyota Motor Corporation was able to significantly increase its productivity compared to its competitors from Europe and the USA with the pull principle as early as 1947 under the name Kanban.

Standardization and reuse

Agile requirements and product management includes standardization and reuse: standardization reduces the effort to implement requirements, reuse usually avoids it completely. Current measurements prove that productivity in the development of individual applications based on reused components and a high degree of standardization is increased by a factor of up to 200. On this topic I also recommend the article “Individual Standard: Mass Customization in Software Development“.

No improvement without performance review

In addition to retrospectives of the team, metrics and regular measurements are important tools to find potential for improvement and to check the effectiveness of implemented measures (on this topic, see also: “Productive Insight: Monitoring in Software Development“). Here, the direction of development and continuity of the metrics are more important than speed: many small steps in the right direction reliably lead to the goal.

All measures described are characteristic of agile software development and serve the goal of making new requirements of a product owner usable as quickly as possible, i.e. the shortest possible time to production. The problem with this approach, however, is that the development process ends when a change is handed over to the operator, and even the fastest development of new features is often slowed down by the change processes of system administrators. The next article in this series is therefore entitled “DevOps – Agile System Operation” and deals with the question of whether the process following the handover can also be agile.

Feel free to share your experiences with the use of agile methods in software development!

Photos: Shutterstock

 

Leave a reply

Your mail address will not be published. Required fields are marked with *.