Photo by Kristopher Roller on Unsplash
During a recent conversation with a journalist, the downsides of agile came up in the interview. The questions were centered around stress levels of team members, the frustration with not being able to do a proper design before building features, the perceived reduction in innovation and other factors. During the discussion I realized that there still are many people that seem to have missed an important aspect of agile: the transition of tasks from being implicitly performed to explicitly scheduled.
When companies employ more traditional, waterfall style approaches, there typically is a certain amount of slack in the weeks after a release. Of course, there are issues from the field that need to be resolved and some are busy with that, but a significant number of people has time for activities that we didn’t get around to when pushing out the release. These activities include managing technical debt, experimenting with new, innovative ways of doing things in the system, becoming familiar with potentially relevant new technologies, trying out new product or feature ideas, etc.
The interesting thing is that these activities occur organically and provide a valuable source for innovation, both customer- and technology-driven, as well as a natural way to manage maintainability of the system by paying off technical debt. However, as these activities occur organically, are implicit and consequently not actively managed, the company learns to rely on these activities taking place.
When adopting agile, the structure of sprints causes a situation where teams are constantly driving for feature development. Well functioning teams want to do right by the company, which means that if teams are asked to build features prioritized in a seemingly infinite backlog then teams will do so. The process of sprint planning provides a much higher degree of transparency in resource allocation and, as a consequence, there is no slack in the system. As soon as the sprint is over, the next one starts.
The consequence of the lack of slack is that the company needs to explicitly allocate resources to activities that used to take place implicitly and organically before the adoption of agile. This means that if you want to have a maintainable system over time, resources need to be explicitly allocated to managing technical debt. If the company is relying on a constant flow of bottom-up innovations from its R&D staff, then time for innovation activities needs to be explicitly scheduled.
Once leaders in the company realize the need to explicitly schedule time for results that used to come “for free”, this typically leads to a situation where the relationship between R&D and the rest of the company is made explicit. In those organizations that view R&D just as a supplier from which you order features, the willingness to provide time for managing technical debt or for innovation is typically non-existent. In those companies where there is a true partnership between R&D and the rest of the company, this leads a situation where explicit resourcing decisions are taken not just concerning feature and product development, but also around quality, technical debt and innovation activities.
Concluding, agile does not kill innovation, but as with many other aspects of software intensive businesses, agile makes the problems so blatantly visible and explicit that the organization has no choice but to address these concerns. There is no such thing as a free lunch! Quality, maintainability and innovation all require resources and not allocating these resources will give you exactly what you asked for.
