How do you eat an elephant? Simple – cut it into small pieces at eat one piece at a time.

BUT…

…is it really that simple?

When you have a large software project it is too simplistic to assume that all you need to do is to decompose the problem to individual manageable chunk which can be handled by one scrum team and then continuously keep integrating the code produced by the teams. Keep doing this and your software would be ready.

Four Assumptions you make while splitting a problem
In agile we call each chunk a user story. There is an underlying belief that it is possible to take one story at a time and code it into the application. The design of the application would emerge and the architecture of the application would evolve. But for that to happen the following assumptions must be valid:

Granularity of the decomposition: Each story is not too large – one person code it within a couple of weeks.

Loose coupling: Each story in not too interconnected with the rest of the already developed application – the code can be tested without too much complication.

Ability to iterate: Every story can be plugged in easily – it does not necessitate too much change in the existing code base – it does not create too many regression error.

Minimum emergent behavior: The impact of adding a story is predictable – when a new story is added then there is no unpredictable change in the behavior of the application.

There is no guarantee that this can be achieved for every problem. There is no scientific method which can be applied.

However, experience teaches us that a good architecture can enable this process.

The best way to arrive at a good architecture is to find an expert who has solved a similar problem and has learned the hard way what not to do!

Such a person can make the problem as simple as possible but not simpler.

What if you cannot find such a person?

Then you will need to go through architectural cycles to arrive at the right architecture before user stories can be taken up.

You also need to keep in mind that any architectural decision once taken cannot be changed easily. It would involve too much rework. So, you should defer some of the architectural decision to the last responsible time.

Related Articles:

Simplicity: A New Model

Simplicity Is Highly Overrated