Agile Falls

Objective

Engineering processes involve different stakeholders, each with different horizons and different contexts. Waterfall project management use milestones and schedules to align their different objectives and agendas. That usually brings about cumbersome structures with bureaucratic definition of tasks, limited empowerment, and significant overheads.  At the other end of the spectrum, agile methods take the opposite view by replacing planned milestones with objectives set dynamically through iterative collaboration between business and system analysts. Clearly there is room in between where both approaches should be combined, the former when integration is required, the latter otherwise.

As Falls Architecture …

Waterfalls are usually set along organizational boundaries: stakeholders set goals, business analysts define requirements, system analysts specify functionalities, system designers do the same for system components, developers implement them, and users validate deliverables.

Yet, behind and beyond those organizational outlines, there are more constraining boundaries which, contrary to the organizational ones, cannot be easily removed, or even moved:

• Requirements are set by market opportunities and business goals. Investments are to be planned, operations resources make available and their use allocated between business units. That cannot be achieved without commitments to milestones and schedules.
• Business operations are to be supported by integrated applications, and that cannot be achieved without consolidation of system functionalities across business processes. If such functional architecture is to be used as a reference, and possibly modified, by new applications, the life cycle of analysis models must be explicitly managed.
• The same rationale hold for design models regarding technical architectures.

Those constraints are materialized by milestones  and set the framework within which iterative development can be achieved.

… so Agile Falls.

According to the manifesto, agile development is best described by four counterpoints:

• Individuals and interactions over processes and tools (democracy trump bureaucracy).
• Working software over comprehensive documentation (animate descriptions trump inert ones).
• Customer collaboration over contract negotiation (win/win situations trump zero-sum games).
• Responding to change over following a plan (set the goal, not the path).

A noted above, that’s not always possible and some grounds are better suited than others when agility is concerned, from the natural ground of agile, where complex problems can be undertaken in isolation by combined teams, to interwoven projects involving periodic integration across domains and business units.

An ideal situation would be a standalone project without shared architectures, i.e integration tasks. That would open the way for iterative collaboration between business analyst and system developers all the way from requirement to implementation and validation.

Yet, the real challenge for the agile approach is to square its basic principles of iterative collaboration and shared responsibility within the walls  raised by organizational structures or functional architectures. For that purpose agile project need to set their loops on solid ground and complete them with integration mechanisms.

Loop Invariants, Milestones, and Traceability

Whenever architectures are shared across project, iterative collaborations must take into account what is given and how new developments should be consolidated. Just like programming loops, that should be done by explicit definition for invariants, increments, and exit conditions.

The simplest configuration would be changing requirements within the perimeter of persistent or execution units, i.e without impact on functional architecture. Concretely that would cover projects limited to new features, operations and rules. A more realistic configuration would target the boundary tier, i.e not shared execution units.

The need for explicit invariants should not appear until new roles and functionalities are added to existing shared execution units. Then, iterations will have to be circumscribed by a frozen set of persistency and execution units, and the neutrality of the new functional units will have to be checked before being integrated.

One step further, one should consider the possibility of extensions to execution  units, and then to persistency units. Along that reasoning a limited number of development cycles can be identified and then grounded on formal agile principles as defined by Robert C. Martin in “Agile Software Development”:

• Single-Responsibility Principle (SRP): Unit descriptions should have only one reason to change. Whereas that should be easily achieved for boundaries (which are not shared), integration will be needed for iterations affecting persistency units (shared by different functional units), and for execution units (shared by different roles).
• Open-Closed Principle (OCP): Unit descriptions should be open for extension, but closed for modification. That may be achieved if iterations are carried out through strict specialization, i.e without affecting the identification and semantics of targeted units.
• Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types. Originally introduced for design, this principle can be used to check the external consistency of analysis models. Assuming that iterations comply with OCP, the LSP should be used when integration is needed and outcomes must be consolidated.

Two additional principles, Dependency-Inversion Principle (DIP) and Interface-Segregation Principle (ISP) deal more specifically with design concerns.

As a conclusion, the benefits of iterative solutions should be assessed within the broader context of development process; more precisely, their scope should be set by project milestones and their conduct should guarantee the traceability of their outcome.

Iteration Patterns

Having established project objectives on solid ground, it’s possible to identify basic configurations for iterative development.

• The simplest configuration deals with the non shared tiers of architectures, namely entry points. New users or devices are given access to system functionalities. Project requirements can be mapped into the design and implementation of new boundaries through iterative development without encroaching on existing domains, processes, or implementations.
• The next configuration entails changes of shared functional units. Whereas that may induces consolidation of analysis models and optimization of design, that can be achieved through iterative development, i.e without additional milestones.
• That may also be possible for new execution units supported by service oriented architectures, i.e a two-tiers functional architecture. In that case new specific processes may be developed iteratively as far as services are not affected.
• Things are not as easy with a single-tier functional architecture. In that case execution units cannot be added without milestones and integration with existing ones.
• The same constraints must be taken into account when persistency units are extended or modified without the benefits of access services.

Agile & Aristotle’s three units rule

Agile approaches can also be defined by reformulating Aristotle’s three unities:

1. Unity of action: a project should have one main objective that it follows, with secondary threads, if any, set within circumscribed requirements and returning to the main thread after completion. In other words, the project team must constantly know about development dependencies.
2. Unity of place: developments should be executed into a space within which all resources can be obtained directly and communication carried out without mediation.
3. Unity of time:  work units should be set within fixed and continuous time-frames. That is a necessity if innards and synchronization of tasks are to be managed independently of context contingencies.