Software Architecture in the agile World – Part 8: No time for improvements

These are the slides with some notes from my talk about software architecture when developing in an agile way. Contents

Max and his team can now build software in steps, adapt to new business needs and technology changes, and evolve the software architecture accordingly.

But like most teams after a while, they get the feeling that they lose speed. Development takes longer, features get completed less and less.

It’s time to improve the code base and invest in innovation. But unfortunately, there is not enough time because bug hunting, support and technical debt keeps the team busy.

Consider the following quadrants. One axis is past to future, the other axis is technical stuff to business stuff.

Business-oriented and for the future are features. Coming back at us from the past and business-oriented are support and bugs. Things we would make differently today and technical are e.g. technical debt. Technical things for the future are for example architectural innovation.

Now think about the capacity of your team. What percentage goes into which quadrant? Remember that all numbers should be positive and sum up to 100 😉

I typically get numbers like these:

  • Business-Future = 50%
  • Business-Past = 40%
  • Technical-Past = 10%
  • Technical-Future = 0% Sorry really no time for that!

So a lot of teams use about half their capacity on struggling with things creeping back at them from the past. No wonder, they feel like everything is moving in slow motion.

But how to get more time for improvements?

First, the team should invest in quality and get the number of bugs and support cases down. Ultimately, the team should follow a Zero Bug Policy.

A reduced number of bugs lead to less capacity needed in the Business-Past quadrant. The free capacity should then be spent in the Technical-Past quadrant to simplify the source code and to eliminate technical debt.

Having a simpler codebase has one mayor effect: The team starts to deliver more features with the same capacity in the Business-Future quadrant. Your stakeholders will be very happy.

Once the technical debt is mostly cleaned up, spend the time in the Technical-Future quadrant to improve the software architecture to be ready for new features.

If you like the idea of these quadrants, then please say thanks to the inventors.

Continue reading: Summary

About the author

Urs Enzler

Add comment

By Urs Enzler

Recent Posts