In the previous post we looked the difference between “Being Agile” and “Doing Agile”. In this latest post on Agile Methods, we look at what this means for using Agile methods in Open Networks projects.
Characteristics of Open Networking Projects
Open Networking projects are challenging for many reasons and this requires that our project approach be defined specifically to address these challenges.
Open Network solutions typically contain a mix of technologies, people and organisational units that may have different perspectives on their implementation approach, especially if there are multiple vendors involved. Multiple technology streams are woven together across both software and hardware, each with its own supply chain, timelines and data models. A high level of integration means a large number of interfaces and interdependencies.
There are also likely to be many actual and potential users of the solution, especially for “generic” solutions like a cloud platform.
And typically, if a solution is more of a generic platform, this makes requirements gathering more difficult for many reasons.
These factors drive a higher level of uncertainty, both in terms of technology and end-user requirements.
Open Networks are Complicated and Complex Systems
A common analysis model used decision-making is the Stacey Matrix, which has been adapted from its original to computer systems in the following illustration:
The characteristics of Open Networks place themselves towards the top/right quadrant of that matrix, into the “Complicated” and “Complex” solution contexts, and more likely into the “Complex” zone.
One important aspect of understanding the complexity of Open Networking projects is that they:
”defy any single person’s ability to see the system as a whole and understand how all the pieces fit together. Complex systems typically have a high degree of interconnectedness of tightly-coupled components, and system-level behavior cannot be explained merely in terms of the behavior of the system components.The DevOps Handbook
There are many implications of the attributes of complexity, not the least of which is the need for a high degree of co-operation and collaboration across multiple people in the project team. Complex systems, with high degrees of uncertainty in either or both requirements or technical baseline, have high rates of change across the entire lifecycle.
Such systems are difficult to reduce to static representations such as formal specifications or process descriptions.
The project team must constantly interact to share, reinforce and re-establish their understanding of the evolving system at any given point in time.
Agile and Open Networking
Agile (adaptive) implementation models work better in Complicated and Complex solution contexts, due to their ability to deal with change. The change is not just in the solution context, but in the changing understanding about the solution as it evolves over time amongst different stakeholders.
Participants in Open Network projects must constantly revise and re-establish their understanding of the solution overall and the relationship of their respective solution components and other components.
We closed the last post with the statement: “the mindset is more important than the methodology”.
The agile mindset is paramount in Open Networking projects, because we cannot, as a single team, fully understand or define the whole system in a static way at any one time. We need to be adaptable to the current and changing circumstances under which Open Network solutions are conceived, designed, implemented and operated.
Since we cannot fully and sustainably define the solution, rigid, rule-based and predictive approaches are very problematic. We need a different approach, and the agile mindset brings is the ability to work with heuristic principles.
Heuristics are specific kinds of tools that help individuals and teams solve problems quickly under constraints and uncertainties.
They are “rules of thumb” that inform our problem-solving processes. They are not perfect by any means; they don’t have the same level of reliability as more formal methods of problem solving. But these formal methods usually require both time and good information: resources that are often not available in the Open Networking domain.
A decision-making strategy often used with heuristics is “satisficing”, which is a combination of two words “Satisfy” and “suffice”. Satisficing is a strategy that seeks solutions or accepts choices that are “good enough” for their purposes but are not optimal.
We need heuristics in implementing Open network solutions because the rate of change is likely to be faster than the time to execute more formal processes. When we design a project approach for Open Networking projects, we must be sensitive to both the overall requirements and the individual and team situation. A key point is that the typical agile project is a software-only solution with little regard for underlying infrastructure that hosts the apps and relevant interfaces other than sizing.
In the twenty-teens, many agile projects are focused on cloud-based SaaS solutions, which can be easily and incrementally scaled. Network components and systems have not traditionally been a part of agile mainstream and present a different set of requirements throughout the whole lifecycle.
There is no point to saying “Everyone must use Scrum” or “we’ll all work on 2-week sprints” if that causes disruption on one or more areas of the overall project.
There are no books on “Agile in Open Networking” so whatever literature there is will inform Open Network projects with generic information that must be tailored. This requires a certain (higher) level of agile process knowledge that will be required in (at least) the early stages of the project, to ensure that tailoring the process is done in a way that promotes success but still retains the benefits of agile.
This is where Aptira can help, based on our deep and long experience in Agile approaches to complex solution integration projects like Open Networking.
We will touch on this more in future posts – Stay Tuned.