(I originally posted this on my MSDN blog.)
I’ve had several discussions recently with coworkers about Agile project management processes, and one point I’ve found myself making repeatedly is that agility in your process tends to demand agility in your code base. If you can’t rapidly evolve the design of your code base to respond to an ever-changing understanding of your goals, then you’re not going to be able to change your goals. You just have to pick some and drive in that direction for better or worse.
Agile project management processes such as Scrum are careful to not require any particular software design methodology. Scrum is supposed to be agnostic about your coding style. That’s true to some extent, but if your project management style says you’re supposed to be able to take your code base in new directions at will, and you’re not able to do that effectively, then you’re just setting yourself up for a world of frustration. It simply won’t work. I suspect that a lot of the apparent failures of Scrum are actually due to an impedance mismatch between the project management methodology and the code base.
Practices such as continuous integration (CI), test driven development (TDD), pair programming, S.O.L.I.D. design principles, and other coding practices are probably not the only way to create an flexible code base, but they’re a well-known and proven way to do so. If you’re an architect or manager thinking of adopting Scrum for the first time on your team, be sure to include your developers in that conversation, and make sure they understand that it will require changes not only in how they plan and track their work, but also in how they actually do their work.
SaintGimp 