The Agile development model should not be seen as a panacea or identified with specific methodologies. Instead it should be understood as a default option to be applied whenever phased solutions can be factored out.
- Scope: Of the twelve agile principles, ten apply to any kind of development, and only two are specific, namely shared ownership and continuous delivery .
- Characteristics: Assuming conditions are met, agile software engineering can be fully and neatly defined by a combination of users stories and iterative development.
- Alternative: When conditions cannot be met, i.e when phased solutions are required, model-based system engineering frameworks should be used to integrate business-driven projects (agile) with architecture oriented ones (phased).
- Variants and extensions: Even when conditions about shared ownership and continuous delivery are met, scaling issues may have to be taken into account; in that case they should be sorted out between broader business objectives on one hand, systems architecture engineering on the other hand
These guidelines are not meant to define how agile projects are to be carried out, only to determine their scope and relevance along other systems engineering processes.
Further Reading
- Thread
- The Scope of Agile Principles
- Thinking about Practices
- Agile vs Waterfall: Right vs Left Brain ?
- Iterative Processes
- Agile & Models
- Agile between Space & Time
- Agile Delivery & Dynamic Programming
- How to Mind a Tree Story
- From Stories to Models
- Agile Business Analysis: From Wonders to Logic
- Spaces, Paths, Paces (Part 1)
- Spaces, Paths, Paces (Part 2)
- Business Stories: Stakeholders’ Plots & Users’ Narratives
- Focus: Users’ Stories & Use Cases
- Projects as non-zero sum games
- Agile Falls
- Use Cases are Agile Tools
- Tests in Driving seats
- Models Transformation & Agile Development
- Agile Architectures: Versatility meets Plasticity
- Agile Collaboration & Social Creativity
- Business Agility & the OODA Loop
- Business Agility vs Systems Entropy