I will be conducting a Nexus workshop in Boston on November 17-18, with Richard Hundhausen and Rob Maher, fleshing out the Nexus Guide with examples, case studies, practices and tooling
– Why Nexus?
The word Nexus refers to a connected group or series that are integrated, linked together. When I use the phrase Nexus. I also mean that the group or series act and are seen as one. Nexus adds just enough to the Scrum framework to create this reality, providing the dance steps needed to act as an integrated whole. The skill of dancing, or integrating, is still excruciatingly difficult, requiring practice and continual improvement, until it is second nature.
Dependency identification and removal as well as continuous integration to identify ongoing quality are minimal requirements. However, I expect many not to pick up on the ideas of descaling and Scrumble. Organizations need to assess the art of the possible when scaling, always alert to the need to reduce scale rather than generating technical debt.
Many scaled efforts delay integration, Nexus requires integration at Sprint boundaries, removing fthe technical debt that accrues when focus is only placed on longer term goals.
– What’s so special about Nexus?
Nexus is a lean extension of Scrum, an exoskeleton. Single team Scrum artifacts are integrated in Nexus artifacts (Nexus Sprint Backlog, Integrated Increment). Events for managing the integration through identifying and resolving dependencies drive existing Scrum events, such as the Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Retrospective and where appropriate replace them (Nexus Sprint Review). Rather than relying on serendipity, integration responsibility is formally embedded in a new role, the Nexus Integration Team.
Nexus is lean, modulating the existing Scrum framework and consistently building on Scrum practice knowledge already gained by Scrum users worldwide.
Nexus+ provides us with an architectural platform for consistently integrating the work of multiple Scrum teams into a consistent, quality whole. This has become critical as software development becomes a large part of mission and life critical products. Nexus+ starts with lesser mechanisms such as product family and COM architectures, but relies on platform computing to deliver the sophistication and complexity of the future.
– Why now?
Most of my work has been with thinking organizations, those whose success pivots around their ability to build and deploy innovative software.
In the metaphor of Crossing the Chasm, the desire for agility has now reached the early and maybe the late majority. True to form, large IT organizations have purchased methodologies and tools the will give them “silver bullet” agility. Scrum is often bundled into these methodologies in the development “phase.”
Unfortunately, these agile methodologies do not include instructions for scaling software development and Scrum. Enter Nexus, a framework that can be placed over the development phase of these methodologies. Nexus also provides a consistent terminology with which these organizations can enter into the Scrum community and dialog.
Hi Ken, just read your Nexus Guide. Wondering if you´re interested to have it translated to German? I´d like to do it.
I’m holding off for the time being to see if the Nexus Guide shakes out anymore after the November class. Then, will visit.
Hi Ken, I wish you great success for your class and will be glad to support your idea then in the future.
Pingback: Scrum @ 21 | Ken Schwaber's Blog: Telling It Like It Is
Pingback: Scrum at 21 with @KSchwaber | @DevOpsSummit #Agile #AI #Scrum #DevOps – parwati