Continuous attention to technical excellence and good design enhances agility.
So your team has been practicing agile for a while now. It started off so well; your team delivered nice increments of working software consistently, kept retrospectively looking for room to improve, and in general made business stakeholders happy with visible progress. Perfect!
Well, almost perfect. Overtime you have accumulated a growing number of software defects, which never seems to beat those cool new features in pecking order to implement/fix. You introduced unit testing and refactoring but gradually those best practices find their place in a “guilt list” – things you know you should do but never quite get enough time to do it. Oh.. not to mention task estimation seems to be so wrong no matter how much “buffer” time you allocated. Your team’s velocity is getting unpredictable and you start to hear whispering over the wall whether agile works in your organization.
An excuse one often hears is that as the software gets bigger and bigger, so does its complexity and, thus, the required effort to add new feature or to make changes. However intuitive this logic sounds, the truth is complexity is a sign of technical immaturity; and the purpose of software engineering is to control complexity, not to create it (Pamela Zave).
If your project shares similar symptoms as above, maybe it’s time to call for rather dramatic actions: halt the whole new features development, go back to fix your code base, refactor your architecture, and eliminate the bugs. The next step is to commit to zero bug tolerance and enforced engineering best practices, unless you want to fall into the trap again.
If you fail to maintain technical excellence, you fail agile!
But it’s never too late.
