The agile movement properly recognizes the value of getting to code early and not spending years on “Big Design Up Front” without demonstrating executable software early in the lifecycle. Agilists are correct in believing that a great deal of knowledge will be gained about system requirements by putting live software in the hands of users early. However, agile development as currently practiced across much of the industry has removed too much engineering from software engineering.
Agile/scrum and kanban put the focus on project management rather than engineering. Engineering tends to be left to the discretion of the developers, and there is an active mindset of “code first, refactor later” as opposed to systematic exploration of requirements and designs. Agile in practice is often used as an excuse for not doing architecture, not doing engineering and avoiding thinking about rainy day scenarios, leading to buggy, fragile (non-resilient) software. There is a general mindset on agile projects of achieving quality by testing rather than achieving quality by design. This mindset very often tends to be overly-focused on unit testing because acceptance testing requires that rainy-day scenarios be fully modeled and accounted for.
Complicating the problem, basic software engineering skills like developing quality use case models that fully explore sunny/rainy day behavior, how to properly decompose a use case into models, views, and controllers (MVC) and how to model the problem domain as a set of conceptual objects are often not taught adequately at the university level.
Resilient Agile (RA) is an attempt to put the necessary engineering back into software development without losing the “get to code early” focus that agile gets right. RA is based on a time-tested method (ICONIX/DDT) of developing an initial problem domain model, then decomposing a system into collaborating use cases and elaborating each use case by doing a conceptual MVC decomposition. Note that MVC as used within Resilient Agile does not represent the technical architecture of the system, but rather is used as a way to analyze a use case and identify participating elements such as screens, logic, and database tables.
With ICONIX/DDT, storyboards are developed for the View elements and Model elements belong to the domain model. Meanwhile, unit test cases are generated for each Controller, and acceptance tests which fully expand sunny/rainy day use case “threads” are generated for each use case.