Why Fast Feedback Cycles Matter – by Jan Bosch

When studying software-intensive systems companies, one of the interesting observations is that they all evolve in the same way. In earlier research, we have referred to this as the “Stairway to Heaven”. In the figure below, the speed dimension of the Stairway to Heaven model is shown. This model is a descriptive model based on our research with dozens of companies and it follows a logical sequence of activities. First, starting as a classical company, the organization adopts agile practices. Subsequently, continuous integration is adopted and rolled out in the company. Once continuous integration and test have established a situation where all software is always at production quality, the company will move towards continuous deployment. Finally, it will start to use its deployed products for innovation purposes, for instance through A/B experimentation.

speed dimension
Figure: Speed dimension of the Stairway to Heaven

Although one can easily argue that companies evolve through these levels, the question one should ask is WHY this happens in the first place. Our research has shown that this is because companies benefit from shortening the duration between decision and the feedback on the outcome of the decision. In general, the shorter the feedback cycle, the more accurate the decisions can be as a shorter feedback cycle allows for a more rapid learning loop. In the case of software-intensive systems companies, we have identified six feedback cycles that are shortened when climbing the Stairway to Heaven:

Development: When adopting agile development practices, the first principle is that the team works in sprints of four weeks or less. This means that at the end of every sprint there will be working software. This leads a development cycle that is much shorter than during waterfall development as all work in progress is wrapped up into complete code every sprint.

Requirements: The second practice when adopting agile development is that teams conduct sprint planning. This means that for every sprint, there is an opportunity to reschedule requirements and to change the content for the next sprint. This is a fundamental difference from traditional release planning where release content is defined and agreed upon before freezing it until the release of the system.

Quality assurance: Continuous integration and test allows for much faster feedback on the quality of the system under development as compared to traditional testing approaches. In addition, once the company adopts continuous deployment, internal quality assurance is complemented by quality assurance from the field.

Governance: Every R&D organization has at least three types of activities, i.e. feature development, defect management and refactoring. Even with the most advanced CI system, there will be defects that slip through and that need to be managed and repaired afterwards. Similarly, the design of the system will erode over time, often referred to as technical debt, and require investment in refactoring to maintain an acceptable design quality. Operating in short cycles allows the R&D organization to dynamically reallocate resources on short notice and for short(er) periods of time.

Deployment: When adopting continuous deployment, the basic benefit is that our software is rolled out frequently, which provides feedback on the quality of the software. It also provides a solution to the problem where finished features are kept “on the shelf” for far too long without providing benefit for the customer as well as the company that built them. No modern factory would produce goods just to have these sit on the shelf for months at end because of the associated waste, whereas in many software development organizations, that is exactly what happens.

Value creation: The final cycle is concerned with confirming that the value that we predicted would be delivered by new functionality indeed is created. For instance, a new feature may improve some quality attribute or change user behavior in a desirable way. When using a traditional release model, this feedback becomes available often several quarters or years after the decision to prioritize the development of the feature has been taken. When using continuous deployment, we have access to this feedback in a small number of weeks.

In the table below, we related the stage of the Stairway to Heaven model to the feedback cycles that are shortened at that stage. The key reason why shorter feedback cycles are so important is that companies take opinion-based decisions when the feedback cycles are long as the relation between a decision and its effects is too far separate in time. When feedback cycles are short (such as one sprint), decision processes also become data-driven. In earlier articles, I stressed that for a typical software-intensive company, half of all the features built are waste in that the provided value does not justify the R&D effort that was needed to create the feature. Shorter feedback cycles provide a very powerful solution to reducing that waste.

feedback cycles

Table: feedback cycles

Concluding, shorter feedback cycles allow companies to transition from opinion-based to data-driven decision making. That allows allows for a step-function change in the quality of the decisions that are made which, in turn, improves the competitiveness of the company significantly versus competitors that are stuck in traditional ways of working and opinion-based decision making. Climbing the Stairway to Heaven is not a “nice to have” for the R&D organization but rather a critical factor for maintaining the competitiveness of the company.

Follow me on  janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).
And you might like www.software-center.se!

Transformation Agile : Des pistes pour réussir le changement – Thierry Ventadour

Avant d’aborder le sujet des transformation Agile, faisons un rapide rappel historique des transformations dans l’IT

Il faut attendre les années 1980 pour que l’industrie informatique connaisse les premiers déploiements de processus, avec des démarches basées sur l’ISO 9001 ou le CMM. Le postulat est alors que la mise en place de processus efficaces résultera nécessairement en la livraison de produits de qualité, tout en tenant délais et budgets.

Les années 2000 voient alors l’arrivée des méthodes et principes Agile, notamment avec la publication du manifeste Agile en 2001 : Si les processus sont nécessaires, ils seront vains sans prendre en compte la dimension humaine des équipes de développement. Il apparait alors nécessaire de motiver et responsabiliser les équipes afin que celles-ci délivrent des produits de qualité.

L’Agilité est orientée utilisateur. Vu de l’utilisateur, l’important est le produit livré, et non pas la manière dont le projet a été mené. Les organisations IT, orientées projets, se transforment donc en organisations orientées produits : les Chefs de Projets font place à des « Product Owners », les plans projet à des Product Backlog.

Quelques conditions pour une transformation Agile réussie

La première condition est d’avoir un objectif de transformation précis, partagé et orienté business, supporté par un sponsor fort : Pour quelles raisons l’organisation doit-elle évoluer ?

Donnons un exemple : vouloir développer un produit modulaire afin d’être en capacité de répondre plus rapidement aux besoins des clients. L’objectif est alors précis, concret, vérifiable et orienté clients. A contrario avoir comme objectifs de se transformer pour supprimer les silos dans l’entreprise ou améliorer la satisfaction des employés est certes louable, mais vagues et peu tourné vers les utilisateurs. Quel sponsor investirai durablement pour une démarche non liée au business de l’entreprise ?

La deuxième condition a été formalisée par Kotter : il faut un sentiment d’urgence : Sans urgence, il y aura toujours quelque-chose de plus prioritaire à faire ! Il ne s’agit pas la de l’urgence réelle, mais de l’urgence ressentie par les membres de l’organisation.

Il faut ensuite reconnaitre l’importance des différents axes de la transformation Agile :

  1. L’axe organisationnel : Agile nécessite une transformation des organisations au niveau équipe, par exemple avec Scrum, et au niveau organisation, avec la mise en place de frameworks comme SAFe ou LeSS. Sans changement d’organisation, pas de transformation Agile.
  2. L’axe humain : Agile nécessite un changement des valeurs et des comportements à tous les niveaux de l’organisation : mise en place d’un management plus bottom-up, responsabilisation et confiance dans les équipes, transparence, décentralisation des décisions. Sans changement de valeurs, pas de transformation réelle des comportements, et pas de transformation Agile.
  3. L’axe technique : pour livrer fréquemment, il est nécessaire de mettre en place de nouvelles méthodes de développement, comme l’intégration continue et les tests automatiques. Pour cela, il est nécessaire de « refactorer » les produits pour les rendre plus modulaire et testables, d’en revoir l’architecture. Sans transformation des méthodes de développement et de l’architecture des produits, pas de transformation Agile.

Comment s’assurer que la transformation Agile progresse ?

Un premier signe est d’observer que l’organisation IT orientée projet disparait au profit d’une organisation orientée produit : Les équipes projet se restructurent autours de composants pour former des « component teams », ou de fonctionnalités utilisateurs pour former des « feature teams ». Les budgets ne sont plus gérés par projet mais par produit.

Dans le même temps, les anciens rôles associés aux projets (Program Managers, Project Managers) font place à des rôles associés aux produits (Business Owners, Product Managers, …). Il ne s’agit pas uniquement d’un changement de nom, mais d’un changement de rôle, cette évolution s’accompagne d’une montée en compétence autours de la gestion de produit.

Les méthodes de développement, historiquement souvent définies par des équipes transverses sont prises en charge par des membres des équipes concernées, organisées en communautés. Le rôle des équipes transverses est alors de faciliter et s’assurer que les décisions prises sont alignées avec les objectifs de l’entreprise.

Enfin, une transformation Agile n’est jamais confortable : Managers et membres d’équipes doivent faire évoluer leurs valeurs, comportements. Une transformation facile est le signe d’une transformation de façade ou qui ne progresse pas.

Conclusion

Les transformations Agile s’accompagnent d’une revalorisation du rôle de développeur, pris au sens large, incluant les activités de conception et de test. Elle favorise également l’émergence de leaders, c’est-à-dire de personnes indiquant la direction à prendre et entrainant les équipes vers cette cible. Des leaders apparaissent à tous les niveaux de l’organisation : développement, architecture, management.

Enfin, une transformation Agile prend du temps, la mise en place de frameworks type Scrum ou SAFe n’est que la face immergée de l’iceberg. L’évolution des comportements des équipes et managers, de même que la mise en place de nouvelles techniques de développement ne se fait pas en quelques mois.