Whether it is due to frustration, creativity or combination of both, the modern age software industry is overflowing with ever-emerging frameworks and working methodologies. A few make money out of it, while others struggle to change and adapt to processes that aim ‘to magically solve their issues’. Focus on the actual work is being lost, and very often, more damage is made. Nevertheless, there is nothing wrong with frameworks themselves, but rather with people’s perception of them. Companies promoting the use of a certain framework forget that they act as guidelines and not as a set of rules set in stone.
Once upon a time, there was a set of principles known as the Agile Manifesto. The manifesto came out as a solution provided by the seventeen frustrated software engineers, yearning for an alternative to the existing documentation driven software development processes. They presented a way all stakeholders can collaborate at all times by following a set of procedures in order to deliver quality, continuously.
We are uncovering better ways of developing
software by doing it and helping others do it.
The agile principles emerged in 2001 putting in focus linear requirements-based processes that attempted to impose predictable delivery methodologies and project management processes driven by time and output.
Improvements were seen immediately, but agile did not manage to kill off complex management layers and the embedded waterfall behaviors. Over time the agile principles have been incorporated into many management practices.
There are a number of larger scaled frameworks and their derivatives in the market place today, ranging from Lean Startup, Cynefin, Portfolio Management, Right Shifting, Test Driven Development, to Extreme Programming, Scrum, Kanban and more. Agile remains an umbrella term that means different things to different people.
Fast forward to 2018, the agile methodology Scrum seems to be an absolute favorite in the business world. With Scrum, the product is built in a series of fixed-length sprints that give teams a framework for releasing software on a regular basis and bringing them a feeling of tactile progress.
Fixed and limited to a one month period, Scrum Sprints reinforce the importance of good estimation and fast feedback from tests, thus solving the struggles encountered by other frameworks. However, in the world where organizations need to build products that bring value, and do so better, faster and less costly, Scrum revealed not enough.
Trying to scale by adding more developers and managers harms the workflow and collaboration between teams, further affecting transparency and accountability. A potential solution comes from one of the creators of the Scrum Framework, Ken Schwaber. He created the Nexus Framework in 2015, and refreshed it just recently in 2018.
Preserving Scrum, the Nexus Framework uses an iterative and incremental approach to scaling software and product development, but it augments it minimally with one new role and additional events and artifacts. It is used by organizations when multiple Scrum teams work on one product and struggle with cross-team dependencies and integration issues.
Nexus introduces the Nexus Integration Team (NIT) which is responsible for successful integration of the entire workload created by all Scrum teams.
It also introduces two new artifacts: Nexus Sprint Backlog and the Nexus Goal.
Nexus Sprint Backlog represents the sum of all product backlog items from the sprint backlogs of the individual scrum teams, and it is used to highlight team dependencies. Similarly, Nexus Sprint Goal is the composite of sprint goals of the scrum teams within the Nexus.
Four new events are introduced:
1. Nexus Sprint Planning coordinates the activities of all scrum teams in a Nexus for a single sprint.
2. Nexus Daily Scrum is attended by representatives from individual development teams who gather to inspect the current state of the Integrated Increment and identify integration issues and cross-team dependencies.
3. Nexus Sprint Review is held at the end of the sprint to gather feedback on the Integrated Increment and to adapt the product backlog if needed. It replaces individual scrum team sprint reviews.
4. Nexus Retrospective is a formal opportunity to look back and create a plan for improvements. The focus is on identifying cross-team dependencies, challenges and potential solutions, and agreeing on how to visualize and track identified actions.
Additionally, unlike Scrum, Nexus makes Refinement mandatory whichserves a dual purpose: it helps the scrum teams efficiently delegate backlog items across teams. Refinement is continuous throughout the sprint to ensure tasks are sufficiently independent so there is no conflict.
The focus remains on the self-organizing teams and organizational bottom-up intelligence. In its heart lies the belief that autonomy, ownership, and continuous improvement do not need to be compromised even at scale.
Just like other frameworks, Nexus alone is not enough for success. It stands for a minimum needed to empower teams to effectively deliver value to clients and get better at it with each sprint completed. It represents a relationship between people who appreciate each other and respect the teamwork spirit when working together toward a single goal, and it should be taken as such.
While Nexus is a promising framework which mitigates problems raised through the use of Scrum, it is down to actual teams (users) and their readiness to adapt to changes that will ultimately bring value.
Lastly, the ultimate formula for success remains constant; being stubborn on a vision and flexible on how to deliver.