On day two of the Agile Dev East, Better Software Conference 2017 in Orlando, Florida, I found myself at an afternoon session led by Dave West, the CEO of Scrum.org. The talk was on scaling in general, but Dave made a pretty compelling case for the Nexus framework. Here are some takeaways:
Scale. Scale means working product with an agile approach. We then add portfolio planning, support, and other things as we try to undo the water-scrum-fall that occurs when we work with other functions in an organization. It is almost impossible to make a blueprint to give an organization that wants to adopt agile practices and principles. But, with Nexus, there is an assumption that the organization is in place to allow product teams to deliver products, and that the high level or portfolio planning has been worked out (HR, budgeting, etc.) Nexus does not attempt to solve the base problems plaguing traditional and hierarchical organizations. It does provide a method, however, to optimize the work of a team of teams working from one product backlog to produce potentially shippable increments every sprint. You can scale as long as you continuously:
- Identify and remove dependencies
- Integrate work across all level
- Create and inspect integrated increments regularly
- Provide adequate tooling and skills
- Inspect and adapt
Nexus. Defined as a relationship or connection between people or things.
Nexus is the exoskeleton of scaled Scrum — Ken Schwaber
3-9 scrum teams, working on a single product backlog. Many of the events are the same, but we scale up one level to include nexus events. And deliver an integrated system every sprint.
Roles. Take the roles from Scrum, and add the Nexus Integration Team (NIT) Purpose: provide transparent accountability for nexus integration. Accountability: ensure that an integrated increment is produced at least every Nexus sprint. The NIT has the Product Owner, a Scrum Master, and team members. The scrum teams do the integration work, however the NIT remains accountable for delivery. There can be people outside the Nexus or the Nexus Integration Team that may be called upon to help with integration. One idea is for an organization to put specialized skills in a form of a service bureau or guild, that can provide skills when needed.
Events. The events from core Scrum also remain, but we we add Nexus Sprint Planning, which allows the NIT to confirm the priority before teams conduct sprint planning. There is also a Nexus Daily Scrum, which is done before the Daily Scrum for the teams. This allows alignment, and to use Dave’s metaphor, it allows us to get the ball back in play on the field. The Nexus Sprint Review is not a phase gate to release into production, it is a review of working product increment, and uses data from production (ideally). The Nexus Sprint Retrospective may be more useful if the NIT gets together before the Scrum teams. Or, they can retrospect after.
Some final Big Ideas. Scaled Scrum is still Scrum. Optimize the whole. One-piece flow: continuous delivery of unique, custom work. Don’t call it a standup. Not everyone can standup, and we need to remind ourselves of why we do this. It is a Daily Scrum, using the term from rugby, because we need it to get the ball back in play. We work as a team to get going again. There is only one product owner for a Nexus. One person makes the decision on priority. The team has to step up and do story creation, etc. But, you can have as many scrum masters as you need. At least 1, and no more than the number of teams. Some teams need a lot of love. Teams may be self forming as part of Nexus Sprint Planning. Allow this to happen. While velocity may drop, it does not matter because it helps us deliver working product frequently.
For more information, you can check out the Nexus Guide yourself.
Until the next Iteration . . .
Jason