As one who recently acquired the Certification for Professional Scrum Scaling using the Nexus Framework, one first needs to ask themselves if scaling is truly what the organization is in need of. Whether one is to scale horizontally or as is more typical vertically where numerous product teams work on the same product using the same product backlog, it is important to make sure that organizations are currently using the Scrum™ Framework to its most optimal ability.
As both Scrum.org and Scrum Alliance, both certifying bodies in the various Scrum roles such as Product Owners, Scrum Masters and so on agree, the Scrum Guide written by Ken Schwaber and Scrum.org is the “Definitive Guide to Scrum:” The Rules of the Game. Simply put, you can implement Scrum is partial but you are then not doing Scrum™ so as a Framework with plenty of room from techniques to be plugged in a augment the SDLC, companies do have a lot of freedom but must adhere to the framework to truly reap the benefits of Scrum™.
I emphasize this in that if an organization is not truly doing Scrum then their desire or feeling a need to scale might be skewed by the perception that adding more resources means delivering proportionally more releases. However, without current 1 or 2 Scrum™ teams working on a single backlog not optimally doing Scrum adding more teams under the same scenario might actually lead to lower productivity rather than greater.
So what do you do you might be asking? You first and foremost make sure you are getting all you can from your current 1 or 2 Scrum teams and adapt and improve on your following the Scrum framework as prescribed in the Scrum Guide and once the teams are optimal and producing all they can and you still need more as an organization then scaling may be in order.
If you have decided that it is time to scale, then one must consider that there are numerous Scaling approaches and might be unsure what to do. From my experience many scaling frameworks are a bit cookie cutter and while they often work for some organizations they do not work for all. Every organization is different as is their culture, product needs, people, skills and so on. To assume that a fixed framework would work for all in my experience is simply not true and may often cause a need for more resources than many companies are able to provide.
Also in the realm of importance is that in order to scale scrum properly, one must use a scaling framework that augments the Scrum framework not one that bends and twist the Scrum™ framework to fit with the scaling approach. I personally and professionally find that the Nexus Framework, the core behind Professional Scrum Scaling not only keeps Scrum™ intact as it was designed with that in mind by the same team who developed the Scrum Guide, it also being a framework rather than an all inclusive rigid model allows the unique differences in companies to be incorporated into the framework just as the Scrum™ Framework has since it was developed.
The Nexus Framework in the Nexus Guide is defined as “Nexus is a framework consisting of roles, events, artifacts, and techniques that bind and weave together the work of approximately three to nine Scrum Teams working on a single Product Backlog to build an Integrated Increment that meets a goal.” It builds on the Scrum™ framework maintaining similar and complimentary additions to scale single products being developed where 3-9 teams are to be used. The addition of a new role known as the Nexus Integration Team sees to it that an “Integrated Increment” is delivered each and every Sprint. At the same time, new events either encompass traditional Scrum events or replace them and new artifacts are added to support the work of the Nexus or the collection of work produced by each and every team ultimately as one Integrated Increment.
While there is so much more that could be said on the Nexus Framework and why I professionally see to as one of the more logical ways to address scaling Scrum™, this should give a fairly high level perspective for those just hearing about the Nexus Framework or those beginning their search for what solutions to use for Scaling their Agile Scrum™ projects.
Published on January 23,2018 LinkedIn