Continuity of delivery and locus
While the scope of agile principles extends far beyond the eponymous methods, some of them are more specific and their applicability contingent on contexts and objectives; two of them are especially important as they entail very specific assumptions with regard to time and space:
- Continuous delivery of valuable software.
- Direct collaboration between software users and developers all along the development process.
Time Capsules vs Time Scales
If time is seen as a discrete gauge introduced to sequence events, it ensues that continuity indicates that no external events are to be taken into account. In other words, once its objectives have been set, software development must be carried out according its own pace, whatever happens in business context and enterprise organization. That’s a pretty strong assumption that should be explicitly endorsed by stakeholders and users.
Interestingly, this assumption can be set against fixed requirements and upfront design associated with waterfall approaches, as if development policies were to be set between two alternative options:
- Time capsules: projects deal with changing requirements subject to frozen business context and organization.
- Time scales: projects deal with frozen requirements subject to planned changes in business context and organization.
A pragmatic approach should take the best of each option: put limited and self-contained objectives into capsules and organize capsules along scales.
Collaborative vs Procedural Spaces
The reason for processes is that tasks cannot be carried out simultaneously, and the reason for human contribution is that some tasks involve decision-making based on circumstances and provisos that cannot be determined upfront.
Those decisions may concern different domains of concerns with their respective objectives and roles: business requirements, systems functionalities, or technical implementations. Agile and phased approaches clearly disagree about how those decisions are to be taken and conveyed along processes and across organizational spaces, the former ruling that all the parties should deal with them jointly, the latter opting for a separation of concerns. As a counterpart to time continuity, agile recommendation implies some continuity across organizational spaces that cannot be taken for granted. Whether that proviso can be met will determine the choice of a development policy:
- Collaborative: problems are solved and decisions taken through collaboration between parties within a single organizational space.
- Procedural: parties deal separately with problems and decision-making within their respective organizational spaces, and communication between those spaces is carried out through prearranged channels.
Those options clearly depend on organizational and technical environments, hence the benefits of charting projects with regard to constraints on ownership and delivery.
Charting projects: Ownership and Delivery
Given that choosing the right development model is a primary factor of success, decision-making should rely on simple and robust criteria. First, if decisions are to be taken and implemented collectively, shared governance has to be secured. Second, if deliveries are to be carried out continuously, projects shouldn’t be dependent on external events.
When charted with regard to ownership and delivery, projects can be regrouped into four basic categories:
- Business requirements with distinct stakeholders and objectives directly associated with business value (a).
- Business requirements with objectives and business value involving separate stakeholders (b).
- Functional requirements targeting features used by different applications (c).
- Non functional requirements targeting features used by different applications across different systems (d).
That straightforward taxonomy provide clear guidelines for project managers: options (a) and (d) associated respectively with agile and phased approaches, and options (b) and (c) to be decided with regard to actual projects, the ability of organizations to accomodate particular development schemes, and long term objectives regarding engineering processes.