The Myth of No Upfront Design in Agile
Any piece of software that we write today is made up of multiple components – classes, services, layers, tiers etc.
To translate a user story in a piece of code requires a decision on how the pieces of code will get distributed among different components.
Let us say you have decided to create an application and have the broad level of features – the prioritized product backlog. What is the next step you would take?
Would you in the start the first sprint coding the first item in your backlog without thinking about what components you are going to have?
If you have done similar projects earlier you will already have a mental image of what components you are going to create. Otherwise you would spend some time discussing with your team mates on what components you need to have. You may document your thoughts, you may create a computer model or you may use a board or a piece of paper.
But, you are going to create a design though it may be in your mind and not on a piece of paper or in the computer.
The design may not be compete. It may evolve as you keep adding features. But in all cases the design is there before you write a single line of code.
Special Challenge of Enterprise Scale Problem
For bigger problem it becomes infeasible for one person to hold the complete design in his mind. More than one person would have to chip in and some form of documentation becomes mandatory.
When the number of persons needed to have a complete understanding of the design becomes larger than a single team then you are dealing with an enterprise scale problem. That is when you have to split the problem into sub-problems and assign it do different teams to solve. In such situation the project complexity increases exponentially.
How you split the problem also determines:
- The team structure
- The agile process you should to follow and (off course)
- The application architecture
For such large problem you will necessarily have to have:
- Definition phase: An initial phase where one team will look at the problem from a high level and split into multiple sub-problem.
- Scale-up phase: This is to be followed by ramping up phase where you form and organize the teams for each sub-problem.
- Steady-state phase: Then you enter into a relatively steady state where each team works on the individual subset of the problem. This phase can continue for a long time.
- Scale-down phase: But at the end you are going to have a phase where you scale down the team size reorganizing them.
Some projects may adopt agile from the very beginning. However, some others for many reasons by opt for agile somewhere down the line.
Similarly, offshoring can happen from the beginning or it can happen in any one of the subsequent phases.
It is not necessary that adoption of agile and offshoring to happen in same sequence.
The key point to remember here would be that the agile process that you adopt will depend on how you decide to split the problem and at what stage you adopt agile and offshoring.
Agile and Offshoring Handbook
- Is Offshoring A Special Case Of Agile Scaling?
- Manifesto for Agile Offshore Software Development
- The Myth of No Upfront Design in Agile