All too often when the agile project model is discussed, the debate turns into a religious war with waterfall as the villain. But asking which project model will bring salvation will only bring attrition, because the question is not which is the best but when it is the best. It’s like asking if a hammer is a better tool than a sickle !
Instead, one should first try to understand how they stand apart, and deduce from that what they are best for; the comparison between the left and right sides of the brain may provide a good starting point.
B2C: Balancing Brain Capacities
If it is (still) impossible to know what people think, it is possible to know where their thinking is rooted in brains, and the answer is unequivocal:
- The left side of the brain is analytical; faced with a problem, it looks for parts and process them in sequence.
- The right side of the brain is better at synthesis as it looks at the whole and processes all relevant information simultaneously.
Obviously casts will differ between individuals depending on inborn qualities and developed preferences; moreover, each individual will balance his brain sides according to the task at hand. The same should apply when projects must decide between iterative and procedural approaches.
What a Hand can Hold
When project management is first considered, the Whole vs Parts alternative should be the discriminating factor: since human brains cannot process an unlimited number of elements simultaneously, work units to be handled by teams must be clearly circumscribed, with a number of independent functional units not exceeding a dozen.
That could be a pitfall for agile developments if iterations and increments were to be associated with an exponential growth of complexity. Yet, partitioning a large project into sub-tasks doesn’t necessarily call for a waterfall schema if the sub-tasks can be performed independently.
What the Hand is Told
Sequential processing can be dumb because the intelligence can already be etched in the sequences. That’s not the case if relevant information is to be picked out and processed as a whole; that can only be done with a clear purpose guiding the hand.
Replacing an administrative process by a collaborative one entails some kind of shared ownership, with teams granted full responsibility for decisions, schedules, and quality. Otherwise the different concerns, purposes or authorities, possibly but not necessary at odds, should be set apart as sub-tasks, and milestones introduced for their consolidation.
What is Handed Over
Development projects may handle three kind of artifacts: texts, models, and code, the first and last being mandatory, the second being optional. Since texts and code are best processed sequentially they are handed over to brain left side; conversely, models are meant to combine different perspectives, e.g structures and behaviors, which put them on the right side of the brain.
Curiously, that seems to put agile in some kind of conundrum: despite models being the symbolic representation best suited to holistic processing, agile approaches are partial to code, even if models are not explicitly ruled out. As a matter of fact, agile tenets are more partial to products than to code, and what is handed over and tested against requirements is not meant to be a program but a running application.
Hand in Hand
Just like the two parts of the brain bring their best to shared concerns and purpose, agile and phased schemes should be enlisted according to their respective merits and shortcomings:
- Agile is clearly a better option when shared ownership can be secured and milestones and models are not needed.
- Phased solutions (“waterfall” is a red-herring) are necessary when organizational, functional or technical dependencies between projects mean that some consolidation cannot be avoided between development process.
Assuming agile methods are used whenever possible, models should provide the glue when external dependencies are to be taken into account:
- Organizational dependencies are managed across model layers: business requirements govern system functionalities which govern platforms implementations.
- Functional dependencies are managed across architecture tiers: transient non shared components (aka boundaries) are governed by transient shared components (aka controls) which are governed by persistent shared components (aka entities).
- Development dependencies should not cross projects limits as they should be managed at domain level using inheritance or delegation.
- Thread: Agile
- The Scope of Agile Principles
- Agile Delivery & Dynamic Programming
- Agile Architectures: Versatility meets Plasticity
- Agile between Space & Time
- How to Mind a Tree Story
- From Stories to Models
- Use Cases are Agile Tools
- Agile & Models
- Agile Falls
- Thinking about Practices
- Spaces, Paths, Paces (Part 1)
- Spaces, Paths, Paces (Part 2)
- Tests in Driving seats
- Projects as non-zero sum games
- Iterative Processes
- Phased approaches
- Products, Projects, Processes
- Project Management