When Agile becomes Fragile

In the rush to deliver there seems to be an increasing tendency to neglect basic design artefacts. This may be due to pressure to build new features, or could be down to the inexperience of the people leading the software delivery.

It doesn’t have to be like this. It really doesn’t.

By including design practices as a core part of your delivery cycle, you can gain developer confidence, improve estimating and ensure you deliver quality software.

How many times have you heard “we don’t do documentation, we’re agile”? Usually, this is used as an excuse to explain why software design documentation isn’t being produced. And we have to hope that all the developers committed to the sprint understand what it is they are actually building.

Where this causes the most problems is when a new design pattern is being implemented. Perhaps a new micro-service interaction pattern, or a new type of data needs to be captured.

To compensate for this failure to complete even the most rudimentary level of documentation, we end up in a cycle of meetings where the design is verbally discussed and agreed. And when, in a few months time the application needs to change, the same developers need to resort to code reviews to carry out an impact analysis to size the new work.

This is clearly not “agile”. This is “fragile”.

1 Comment

  1. The diagram is reminiscent of many a code review undertaken by one team (I won’t mention which) that I worked within, haha. Great article, looking forward to more.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s