Project Complexity: Can Agile Help Reduce It?

Agile methods enable useful practices to establish a dynamic framework that functions over well-defined roles in order to achieve the desired result. Iterative and incremental phases, precise flexible interactions, evolve to establish a highly collaborative and productive team.

In many cases, complexity appears due to the availability of multiple different options, leading to a multi-dimensional project path. However, business complexity obviously increases, because of uncertain conditions, varied methods and technological advancements. Project level complexity has 2 dimensions: (a) project complexity and (b) requirements complexity.

a) Project complexity

Originality, limiting factors and degree of uncertainty define the level of complexity for a given project. However, different organizations have different meanings to the concept of project complexity.

Uniqueness: Every project is exceptional to the company and has unique attributes and requirements. The company’s project execution wisdom grows constantly, as it increasingly learns through experience. Project uniqueness appears if the company has no previous experience in running a similar type of project. For example, a business startup, new technology, etc.

Limiting factors: Project complexity also appears due to tough constraints known as limiting factors. These factors might be parameters defined for the project (such as schedule, budget, etc.).

Uncertainty: The total level of uncertainty in relation to the development method is dependent upon the scope. Uncertainty is defined by external or internal factors. External factors are different, but the most common are law regulations, market change, and economic environment. It is a fact that project complexity determines the rate of success in any particular company.

b) Requirements complexity

Requirement analysis is a path to discover the unclear items. It is an understanding of the business problem, needs and what it takes to address them. Requirements complexity is defined by 2 crucial factors:

The level of unclearness: At the start of the project, how much do you know about the problem statement? How much do you know about the business processes? The level of unclearness must be assessed at a very granular level, particularly pertaining to business rules, systems, functions, etc.

Elusiveness: What is the expected level of requirements elusiveness once the project is launched? Elusiveness in requirements emerges due to frequent changes, starting from the design phase all the way through implementation. Project management methodologies sometimes consider that, when requirements move into the design phase, they have status ‘complete’ and are not subject to change. However, it is not always the case as there is always some level of uncertainty and unpredictability. Requirements elusiveness leads to significant risk and its consequent uncertainty.

Can agile reduce complexity?

a) Requirements complexity

In the classic project management practices, requirements complexity is controlled by spending a significant amount of time in the requirements analysis phase. It is worth to mention that the time spent in the analysis will reduce complexity. This will provide more time to discover the unknowns, allowing the stakeholders to make a reasonable decision while the requirements are well understood and defined.

The Scrum Guide defines the Scrum as a framework for developing and preserving complex products. To be honest to the Scrum Guide, complexity is subjectively defined. In this statement, we don’t know what complexity really means.

The Scrum Guide also states that no changes should be made that would obstruct the Sprint Goal. However, it leaves ‘obstruct’ subjectively defined. The guide also observes ‘ the change’ and ‘the scope’ as two distinct types of change. The scope can be clarified and re-negotiated between the Product Owner and Development Team, as more is learned.

b) Project complexity

Agile assumes adaptive planning, incremental development, and delivery in a cyclic rhythm. Every project tends to come with a unique set of factors. Project factors entail the handling of a distributed environment and complex requirements.

Also, the ability to adapt to change is easier when there is a regular adaptation to changing events. All changes can be resolved, but smaller advents of change are easier to handle. Thus, if the changes in factors are identified early and there is a regular correction in methods, assumptions, and functionality, it becomes easier to manage change.

In Agile environment, the team has to reverse frequently and improve its practices according to specific factors, adjusting them to external and internal events. However, less regulated processes need an experienced team to handle the changes carefully. Otherwise, things may start to become uncontrollable.

Conclusion

Agile practices and methodology provide a capability to manage the changes through an understanding of the inner complexity of projects. Although to manage the requirements complexity in Agile is a little fuzzy and left to interpretation, the agile principles are a good direction for projects that enable them to handle the complexity. As a quick refresh, here are the 4 principles:

• Iterative and incremental;
• Collaboration and adaptability;
• Acceptance and response to change;
• Continuous improvement.

Agile recommends handling the complexity by splitting the requirements into manageable parts that can be achieved without initial constraints. It also inspires team collaboration to establish knowledge sharing and adaptability to changes in the project environment, thus mitigating the impact and facilitate learning to adjust as the project progresses.