Preamble
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.
Further Reading
- 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
We are getting so so analytical about the philosophical aspect of Software Development that we are nearly forgetting about the technical aspect of this profession. I am from the old school and I will never exchange one crack developer with scrumming bad developers. Scrum as much as you want – Philosophize about software development and how things should be done. Come time to deliver the completed and totally functional product, no one would care how many morning and evening scrums have you held during the development of the product. What they care about is their product and you have to deliver and thats all that matters.
As long as external stake holders (clients) are aware of the cost implications of going for Agile, because of it’s iterative approach, agile gives a better visibility about the deliverable & lesser risks. In bigger applications, it is better to go for waterfall till the Deign stage , then Agile for Development. Otherwise it will be higher risks in high level design & cascading effect …
I like this article and in particular the “when is it suitable approach”. For me Agile is a tool and it is suitable for some projects and not for others. From some of the comments you would think that adopting a waterfall approach automatically means that there is no collaboration or communication in the project team. Command and Control sounds more like a project management style than a model.
Reblogged this on Rtech – e-Solutions architecture | אר-טק and commented:
מאמר מעניין אודות שיטת ניהול Agile מול שיטה מסורתית של “מזרקה” (waterfall)
Right about collaboration, but that is the topic of the 4th paragraph and the conclusion: the two parts are meant to collaborate, with agile development applied between milestones.
This is less about Left v Right brain than about collaborate v command and control.
Some people are only happy when they are the boss. They believe the correct approach is for them to give orders and other people to obey them.
The problem with this is that there is only one person doing the thinking (whichever part of their brain they are using).
At each stage in the waterfall some of this thinking is lost, but none is added in.
In a collaborative model, the effects of silo thinking soon become apparent as people discover that others have a different view of the world – company – purpose – metrics etc. Suddenly they are working together and devising a true common aim and the means to meet it.
Command and Control builds resentment. It drives people to build barriers to success. Collaboration dismantles those barriers.
That’s the real difference between the two approaches.
Nicely said Peter
Waterfall attempts to control outcomes and manage risk that enable teams to stand by “the requirements said” type statements irrespective of the finished products being fit for purpose.
Agile recognizes the difficulty in creating requirements and assumes a constant state of change, encouraging collaboration to obtain a functional outcome.
PM is an art recognizing how the WBS should ideally connect to hit schedules. Requirements and code are a science requiring experimentation and refactoring to achieve perfection. Manage the release and resource allocation in a plan, not the requirements.
IMHO
Reblogged this on lava kafle kathmandu nepal.