TL;DR Decomposition of functional requirements into atomic User Stories doesn't mean that activity of elaborate design is redundant - there's always a need of shaping the system's conceptual model: usually at various levels of detail (for different reader categories) & taking into account both static and dynamic perspective. Modern design is not sequential, but continuous and likely more flexible in terms of form, but letting it "just emerge" from context-less User Story implementations is a grave mistake.
On several occasions I've criticized the way "lowly conscious" applying of Agile methods (w/o truly embracing Agile values) cripples the organization. Introducing Scrum as a recipe that frees you from the duty of thinking is one the surest path to failure - sadly, so commonly embraced these days. But I think that (until now) I've haven't explicitly mentioned some of its less known effects, that may be very detrimental in the long term for the whole Industry:
The way the concept of User Story strangles the Design (process)
It all starts with the flawed understanding of what User Story is - originally it was an attempt to provide some proper structure (for the low level requirements) to make sure that each piece of functionality implemented has its goal, acceptance criteria & defined value provided. But this somehow got twisted on they way & nowadays User Story is treated as a "template" to write specifications with.
To put it more bluntly - "As ... I want to ... So that ..." is supposed to be barely a header - a title - & doesn't have to cover all the conditions / details / specifics of the functional need - this are clarified during side-by-side collaboration of Business & IT people. But in the reality, past-era functional specifications / requirement documents have got chopped & flattened to linear sets of User Stories that follow this specific format.
Yay, now we're Agile! Hell you are ...
Design isn't optional
Is that so wrong? Traditional design has all those connotations with condemned, waterfall process (as an intermediate step between analysis & development) - wasn't the whole point of Agile to get rid of the lengthy & boring "paperwork"? Hell-no, it's not the design (neither as a process nor an artifact) you're suppose to fight off - but to clarify it properly, we need to clarify few important points regarding design ...
Design (model of solution) is supposed to be multi-level:
- from a "helicopter overview" (perspective of the whole system, but with low level of detail) - used to get proper understanding of system context, how high-level components are supposed to interact, what they are composed of (& what are the grouping criteria) ...
- ... to a conceptual sketch of particular atomic component (class, module, package, function) - used to depict the actual, precise difference in expected behavior
Of course it doesn't have to be just these two - intermediate steps can be applied, as many as needed. E.g. one of standarization attempts in that area is Simon Brown's C4 model - it features following conceptual levels in total:
- system context
- container
- component
- class
What is more, differentiating levels of details may not be sufficient to properly describe the intended change. Even a junior adept of software engineering knows that systems have static & dynamic perspectives (or as some call them: data & behavior perspectives). These have different qualities, different inertia, they are sensitive to different types of change & their dependencies are of different nature. In the same time, all these perspectives together form a (close to) full picture of the model.
OK, let's now confront all this with flat set of so-called "User Stories":
- supposedly independent
- implemented 1-by-1 (within a single Sprint)
- complete (in terms of "implementability") - in other words: atomic
These are the exact qualities which tend to get exploited (& twisted) on the daily basis.
As this is the only document-like "artifact" that gets explicitly mentioned in Agile canon & its form forces high granularity of the expectation (requirement) specification, frequently "User Story" becomes the design itself (sort of ...), especially when people who create it are more prone to "think with solutions" than in categories of the business problems to solve / address.
Under such circumstances, elaborate modelling seems redundant, there's always just-in-time crafting only, conceptual model pretty much never exist - compare it with the human as a living organism: it's like one doesn't never ever go above the level of individual cells & their nearest surroundings - ignoring the organs & whole systems (like limbic system, neural system, etc.). What do we get if development on cellular level goes rogue & doesn't serve the overall development of whole organism anymore - cancer ...
Emerging design ... my ass
Some may argue that this is what emerging design (or emerging architecture) is about. That this is the best possible way to avoid YAGNI syndrome. But even if the idea is laudable, it's leaned too far to the extreme. Emerging design is not only about postponing decisions as much as possible to focus only on what's relevant at this moment, for currently implemented features. In fact it's about being able to notice (preferably in advance) patterns, regularities & common "denominators" in whole system state (not in an atomic User Story you're working on right now) to continuously adjust it to ever-changing reality.
If this practice is not present, system built incrementally on "User Stories" only reminds me an infinite stack-alike construction created with tiny fibrils, stashed in layers, one on the top of another. In time, you get more & more of them, they don't mix up / merge into anything consistent, instead they get more & more dense & difficult to separate. Systems grows indefinitely, each quantum of functionality dependent heavily of continuously growing stuff inside - but there's no map, no composition, no option of point re-adjustment - just a kneaded mass with barely any chance for non-shallow refactoring.
Obviously, it's not a fault of User Story as an Agile concept. It's we, system builders, who tend to twist it. It doesn't really matter what method do you follow, there's always a need for a "conceptual scaffold" (reference-able, shareable, etc.) you'll be building your solution around.
- the more people involved, ...
- the more complex & heterogeneous the system, ...
- the more dependencies & interactions between components ...
... the bigger the need for unambiguous, ever-green (kept up-to-date) & commonly understood design (/model). Actual form it takes is of secondary importance - whatever works for all involved parties: digital diagrams, formatted documents, wikis, mind-maps, hand-drawn pictures, documentation-as-tests, UML atrocities ;), meta-models bound to code ... - as long as it's accessible for everyone involved, widely accepted & maintainable (including clear responsibility/accountability split).
