Systemic-ness of the Agile

Systemic-ness of agile means to leverage Systems Thinking not only in the context of the individual project but also to be considered at the enterprise level.

"Being agile" considers the entire enterprise, not just the project. "Being agile" is based on systemic principles: the discipline of seeing "whole" which facilitates the rapid creation of business value. "Being agile" is dependent on the appropriate amount of up-front architecture. "Being agile" acknowledges and encourages the dynamics and emergent properties of the project, the project team, and the environment. In other words, "agile" that is standardized is not agile. Adding Systems Thinking to agile projects is always beneficial to improve agile maturity. In more detail, what's the "Systemic-ness" of the Agile?

The Agile Manifesto does not necessarily equate to "being agile": The Agile Manifesto was not written as a systemic prose and thus is not sufficient criteria to determine if Agile is systemic. An Agile manifesto is not a description that includes all details. It is just a minimum set of principles that the proponents of a movement could agree upon. The rest is left for interpretation for each of the proponent. Though such set of principles leaves loopholes for improper usage, it might be the only way of having some agreement and move forward. The idea with the Agile manifesto is that it itself should be used, not dogmatically, but in an agile manner. Systems Thinking should be maintained throughout the project lifecycle to support agility through a balance between adequate architecture definition up front and flexibility to enable the solution to evolve as needs change or are better understood. When you combine a structured approach, rooted in architecture and methodology with an agile mindset and agile way of working (without being dogmatic about it), the complex problems can be solved more easily and radically.

The systemic-ness of the agile approach shouldn't be about software development in isolation: The impact that the developed software or new adjusted functionality will have on the organization and environment it will be used in should be considered too. Here are three examples:

(1) User adoption: A system that works as designed, but is very user-unfriendly, won't be used to the extent it could be used. The worst case scenario is that the end-users work around the system or misuse features of the system in order to do their job effectively.  A systemic approach would include the user adoption of the system being developed.

(2) Cost analysis: Development costs are often only a small part of the costs of the total application lifecycle. Often maintenance costs are five to ten times the original development costs. Savings in development costs often leads to higher development costs. Because departments / teams and budgets / financial reports of the development of the software differ from the maintenance of the software, this is often overlooked. A systemic approach would include an analysis of the costs of the total application lifecycle, and design decisions would be based on that full analysis.

(3). Impact on the process: Even when the software has been built as designed and the end users are satisfied with it, the situation could be that the software doesn't have an added value in the business process it is used for or regarding the goal of the organization as a whole. A systemic approach would include the impact of the developed software on the business processes and at the added value regarding reaching the goal of the organization.

Properly identify what amount of "architecting" is important up front: By jumping too soon into "iteration mode," many teams lose track of Systems Thinking and increase the risk that individual features will be initially approved by users only to be rejected later on when other related features are implemented. The agile methodology puts the focus on implementation (programming, test, operation) and tacit knowledge transformation easing requirements on the design documents, in the ideal case not requiring them at all. The question arises on how this type of development can produce maintainable software, is the knowledge acquired during agile cycles stored, and how it can be reused in the next cycle, or in the next projects. Lack of Systems Thinking is behind this issue: as new users stories are produced, they may expose the inadequacy of a previously approved solution precisely because the design did not take into consideration how one story influences another within the whole. At this point, all the talk about agile being less costly because it enables issues to be discovered and fixed sooner goes out the window.

Adding Systems Thinking to agile projects is always beneficial. Systems Thinking should be maintained throughout the project life-cycle to support agility, with a balance between adequate architecture definition up front and flexibility to enable the solution to evolve as needs change or are better understood. Systems Thinking is the best answer against late architecture-breaker rework and the steep slope of the cost-to-fix curve in many complex projects using agile approaches. Agile can be summarized as "real agility" (defined as the intent behind agile practices = rapid creation of business value) is always desirable. Specific agile development approaches (Scrum, test driven development, other frameworks that rely on very short development cycles) all have their "sweet spot," working very well for some types of projects, not well at all for other types. There isn't a "one size fits all" model for software development. Systemic-ness of agile means to leverage Systems Thinking not only in the context of the individual project but also to be considered at the enterprise level, where the same principle of Systems Thinking being important at all times applies as well.

Posted in: Agile,Systems Wisdom