Struggling with impedance mismatch, obstacles and technical debt in Scrum projects
Lean processes such as Scrum has no requirements regarding specific software design methodology, but on the other hand an agile software process requires an agile code base!
When planning one sprint, we don’t really know what the next sprint will bring. The backlog might change radically before the next sprint, and if the code base and architecture becomes a big obstacle for the product owner to do major changes to the product backlog, we end up with the never ending problem of obstacles and impedance mismatch trying to control an agile-resistant code base with an agile process.
So, why do we end up here? For many reasons of course, but from my own experience it’s often very closely related to the technical debt! Wrong architectural decisions, quick fixes, lack of long term management plans, too much focus on short term gain, too few sr. resources +++
And the conclusion: As the technical debt of a code base grows, its agility drastically reduced! It’s always possible use an agile process on an code base with low agility, but the value is of course drastically reduced, and requires to some degree a less agile product backlog!
1



