Anti Pattern #2

Over Architecture

Over architecture is one of the most common mistakes made when a team first start an Agile implementation. For some reason it seems that some teams totally omit architecture as a part of the incremental delivery of a feature, and little thought is given to it in an Agile sense.

Greenfields is the primary example

“OK, so we’ve got this new product we have deliver”

“We’re going to use Agile”

After this some effort would usually be put into creating a product backlog and getting the features created in vertical slices.

“But this application needs to be scalable, and needs to be resilient, and we’ll need a database, and caching, and a spanky new front-end technology, and we should use X architecture and we’ll need federated security, etc…”

This is the point where the development team spend two months learning, and building an architecture to support all of these things, while no features get developed….

Why this can be a problem

Essentially, what the team are doing is building a fixed scope architecture which will support an Agile style development effort… it’s very easy to fall into this trap, I’ve been guilty of this myself.

In Agile, we create something of value in EVERY increment, which means we usually do not have the time to create the ideal world architecture (or even a basic full architecture).

What we’re doing here is totally ignoring Principle 11 : The best architectures, requirements, and designs emerge from self-organizing teams.

In our first increment it is pretty unlikely we’re have the time to develop a feature which will need caching, a database, a front end, service layers, redundant servers, load balancing, etc…

The first feature ‘may’ require all these things, but it is feasible to get all this done and able to be released before the end of the Sprint? We have to think simplicity initially, and embrace principle 11 : Simplicity–the art of maximizing the amount of work not done–is essential.

No more, no less, but always deliver some value

in sprint 1 we’re going to need to get a few features developed, maybe even just one. What architecture do we need to serve that feature only? In this sprint you’re going to have your work cut out, getting some minimum testing in the system, developing some code, getting a production or production like system up, we don’t need to load up on architecture which we aren’t using this sprint, even if we believe it will be required in the future. Doing this should be thought of as waste, as based on what we’re doing now, we do not know we will need it in the future (i.e. what if the project is canned before we use all that stuff?).

Now I’m not saying don’t consider the future of the product, but modern coding techniques, technologies and architectures lend themselves brilliantly to extension. So, use separation of concerns and SOLID principles, proper version control, cloud-based systems, build and deployment pipeline, self-seeding persistence layers and all that. But focus on what is critical to be delivered this iteration.

Over architecture often has more negative impacts than just taking a long time to setup initially. It can make the application more difficult to deploy and more difficult to test and as you’re fixing an architecture now based what you think it should be, you’re assuming the direction of the development. In Agile we must embrace change, thus the development may change in ways we have no idea about at the start of a project.

How to avoid it?

This anti-pattern is easy to avoid, just ensure that something is delivered in the time-box given. Something that is production ready, but only create the architecture which serves whatever is delivered, not more, no less.