Agile Project Management | By Adam Alami | Read time minutes
Agile methodologies promote lightweight practices to establish a flexible framework that operates within broadly defined roles in order to achieve the desired outcome. Iterative and incremental cycles, comprising dynamic interactions, evolve to become a highly collaborative and productive team.
The advent of Agile as an alternative to the conventional sequential waterfall approach finds its genesis in response to the challenges of managing 'change' and is associated with the 'complexity' resultant to the surge in scale of production.
1. What Is the Underlying Complexity in a Project?
In general, 'complexity' implies intricacy due to the availability of multiple divergent options, leading to a multidimensional scenario. However, business complexity inherently arises because of uncertain conditions, varied methods and technological advancements. Project level complexity has two dimensions: (1) project complexity and (2) requirements complexity.
1.1 Project complexity
Uniqueness, limiting factors and degree of uncertainty construct the level of complexity of a given project. However, different organisations assign different meanings to the concept of project complexity.
Uniqueness: Every project is unparalleled to the organisation and has unique attributes and requirements. The organisation's project execution maturity grows organically as it increasingly learns through experience. Project uniqueness prevails when the organisation has no prior experience in running similar projects. For example, 'green field' venture, new technology, etc.
Limiting factors: Project complexity also relates to stringent constraints known as 'limiting factors'. These factors could be parameters imposed on the project (i.e., schedule, budget, etc.)
Uncertainty: The overall level of uncertainty in relation to the approach drives delivery to achieve the scope. Uncertainty can be driven by external or internal factors. External factors vary, but the most common are government regulation, market change and economic climate. Internal factors, although sometimes not recognised as factors, are real and contribute to enhanced levels of volatility in processes. Some examples are changes in enterprise strategy that impact the project or new project sponsors that pursue different directions and have different philosophies.
It is a fact that project complexity determines the rate of success in any particular organisation. The way in which an organisation anticipates, understands and navigates the complexity of a project determines its rate of success. Wherein an organisational project has a high degree of uncertainty and limiting factors, the rate of success of that project is likely to be constrained to that extent.
In order to eliminate the concept of complexity and enable the organisation to realise its full potential, its members need to comprehend that complexity exists and can increase by scaling up operations. Nonetheless, the team needs to know that effectively dealing with complexity delivers a competitive advantage. This being a barrier to entry eliminates those who are unable to cope with the inherent complexity.
1.2 Requirements complexity
Requirement analysis is the journey to discover the 'unknowns'. It is an understanding of the business problem, needs and what it takes to address them. Requirements complexity is defined by two key factors:
The level of "unknowns": At the start of the project, how much is 'known' about the problem statement? How much is known about the business processes? The level of 'unknown' must be assessed at a very granular level, particularly pertaining to business rules, systems, functions, etc.
Volatility: What is the expected level of requirements volatility once the project is launched? 'Volatility' in requirements emerges due to frequent changes, starting from the design phase all the way through implementation. Project management methodologies often assume that, when requirements move onto the design phase, they stand 'complete' and are not subject to change. However, that is not always the case as there is always some level of uncertainty and unpredictability. Requirements volatility leads to significant risk and its consequent uncertainty.
2. Can Agile Reduce Complexity?
2.1 Requirements complexity
In the traditional project management practices, 'requirements complexity' is managed by investing a significant amount of time at the 'requirements analysis' phase. This is based on the assumption that the time invested in analysis will reduce complexity. This provides more time to unravel the 'unknowns', permitting the stakeholders to make an informed decision while the requirements are being understood and defined.
The Scrum Guide claims, Scrum is a framework for developing and sustaining complex products.
To be fair to the Scrum Guide, complexity is subjectively defined. In this statement, we don't know what 'complexity' means to the author.
The Scrum Guide also states, No changes are made that would endanger the Sprint Goal.
This statement implies 'changes' are allowed as long as they don't 'endanger' the intended outcome. However, it leaves 'endanger' subjectively defined. The guide further distinguishes 'change' and 'scope' as two distinct types of change when it states, Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
However, they are two different things:
- Requirements volatility: Change tends to be induced by requirements volatility. Herein scope remains frozen, but the requirements change. It implies the change on the requirement has little or no impact on the defined scope.
- Scope change: Herein the scope change, 'I want more'. The business introduces additional deliverables or extends the final project outcome to cover elements not agreed upon initially, when the scope was defined.
However, change in the scope can bring volatility to the requirements. Scrum has some level of control over 'change', whereas one of the Manifesto principles is 'responding to change over following a plan'.
No project execution methodology proposes an effective method of managing requirements uncertainty and complexity. It seems that managing change and complexity is left open to the project team's intuition.
2.2 Project complexity
Agile emphasises adaptive planning, evolutionary development and delivery in a cyclic approach.
Every project tends to come with a unique set of circumstances. Project circumstances entail the handling of a distributed environment and complex requirements. The following need to be carefully identified and implemented to effectively understand and manage the circumstances:
- A realisation, acknowledgement and comprehension of project circumstances and constraints are necessary
- Agile must be aligned to these circumstances and constraints (i.e., distributed environment)
- Adjustment to the agility level at an appropriate degree is necessary to meet the constraints
'Close, daily collaboration' defines the ability to identify deltas and implement quick responses, which translates into faster turnaround time. The benefits of collaboration are evident when a team believes in instant communication rather than hanging on to an observation, in validating and verifying before sharing it with others.
Further, the ability to adapt to change is easier when there is 'regular adaptation to changing circumstances'. No change is too big to handle, but smaller advents of change are easier to handle. Thus, if the changes in circumstances are identified early and there is regular correction in methods, assumptions and functionality, it becomes easier to manage change.
Agile methodologies are not built around a set of rules that must be followed. Instead, the team has to reflect frequently and improve its practices according to specific circumstances, adjusting them to external and internal factors. However, less regulated processes need a mature team to use the flexibility with caution. Otherwise, things may start to become chaotic.
3. Conclusion
Project complexity is inevitable and should be acknowledged to enhance the team's ability to respond and adapt to change while staying focused on the end objective. Agile practices and methodology promote the capability to drive and manage change through an understanding of the inherent complexity in projects. Even though managing requirements complexity in Agile is a little blurry and left to interpretation, the Agile principles are valuable guides for projects that enable them to cope with complexity. As a quick refresh, here are the four principles:
- Iterative and incremental
- Collaboration and adaptability
- Welcome and respond to change
- Continuous improvement
Fundamentally, Agile recommends dealing with complexity by segmenting the requirements into manageable scope that can be achieved without triggering constraints. It also promotes collaboration to create team spirit, knowledge sharing and 'adaptability to change' in the project environment, thus diluting impact and facilitating learning to adjust as the project progresses. So does Agile reduce complexity? While Agile is easy to comprehend but difficult to master, the answer is 'yes' if it is mastered and if there is the required maturity to implement and run the process.
About the Author
Adam Alami is a seasoned, versatile IT consultant with over 18 years of experience revolving around major business transformation projects. He has a wealth of cross-industry experience with Tier 1 businesses in major projects in the areas of enterprise transformation, integration, migration and systems modernisation.
Adam is passionate about research. His research interests are IT offshoring, global project management, banking technology, business analysis, information technology and culture, enterprise innovation, and business solutions. To find out more, contact Adam by email.