Agile: Agile Vs Design
Waterfall projects usually landed up with heaps of documents, plans and designs but no working software. These heaps of plans can be quite expensive to produce and comes with this promise that the end product will be perfect because everything was thought out (which it rarely worked out according to plan). Agile software development addresses these problems by motivating teams to focus on completing working software and responding to changes as they come. But the concepts of continuous delivery, YAGNI and responding to change has been misunderstood as "the architecture will form itself over time".
The below debate between Jim Coplien and Robert C. Martin around TDD also touches on the place of architecture in agile software development. As an example, take note of Robert's comment at 5:16 that some devs think architecture is irrelevant in agile development. Although this is an old video I have experienced this mindset as late as 2018.
The belief: "No design in agile"
What happens with some so called "agile" teams is that they tend to do little to no planning/design for the following the reasons:
- They believe that, they can't plan or design because they don't know what future changes are coming their way. "Code for the current problem only".
- They believe that, they can't spend the time planning or designing because they must deliver working software fast.
- They believe that, they shouldn't plan or design because as they develop the software, then the architecture will naturally form.
These beliefs come from a few key points in the agile manifesto:
- "Responding to change over following a plan". - Poorly interpreted as "planning is not needed."
- "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." - Poorly interpreted as "deliver software as fast as possible, and cut out anything which is not coding, such as design."
- "Working software is the primary measure of progress". - Poorly interpreted as "What the customer sees is important, not the code or design."
- "Simplicity--the art of maximizing the amount of work not done--is essential" - Poorly interpreted as "Skipping planning and design means, work not done".
- "The best architectures, requirements, and designs emerge from self-organizing teams". - Poorly interpreted as "Architectures, requirements, and designs emerge without effort or intention."
The belief: "Design in agile is essential"
Agile manifesto clearly states the importance of design and planning:
- "Responding to change over following a plan". This doesn't mean NO plan, it means be able to change the plan. This is further clarified by "while there is value in the items on the right, we value the items on the left more"
- "Continuous attention to technical excellence and good design enhances agility". This means that if you design your system well you do not have to know all the future changes. A clean readable maintainable system is able to adapt to new changes much faster than a messy fragile system.
- "Simplicity--the art of maximizing the amount of work not done--is essential". Spending the time designing and planning, can create a clear path for development and help cut out unnecessary coding.
- "The best architectures, requirements, and designs emerge from self-organizing teams". This means that members jump into the position which best suits them. Having the most skilled and motivated person in each position allows a team to make the best design decisions.
But keep in mind that agile design and planning looks different to how it was done in waterfall. You should not be designing and planning everything upfront because as the project progresses the team will learn more and more. The orginal design should be flexible enough for the design/plans/models/etc to change.
"you can improve a design by refactoring, and that you will do this often and rapidly. But past design choices make refactoring itself either easier or harder."
-Domain Driven Design By Eric Evans