IS Nexus even really AGILE?
Gosh I sound like a negative nancy and maybe I should stop posting here. I tend to think real world vs a lot of answers I see are theory never applied to real work.
I switched from a scrum alliance guy to a scrum .org mainly for the sake of test taking time. I can self-study take what I want when I want.
Nexus is one of my next tests but to the authors of the “Nexus framework for scaling scrum”. My take away is even though you did a good job explaining and the case studies were interesting this does not feel like agile. If I did every single technique you have in your case studies with PO, DEV TEAM, NIT, and Scrum Master I’d be back at waterfall. Seems like a lot of steps to actually getting to work.
The backlog refinement over and over to get to a Nexus sprint backlog to get to team backlogs feels a lot like a big old bunch of upfront design before you even get to coding. Does not feel very emergent or lean.
My capacity would have to be set at 4 hours a day of real development to get all this in. Granted a good deal of this falls outside of DEV code work but just to start get coding seems like a on of work. I’ll state again I have scaled scrum pre-Nexus back in 2012 and while challenging and complex we did it without as many steps. I picked NEXUS because I thought it was more streamlined than SAFE 4.5 and it is but not by much.
Still a lot of overhead and cost to training an org to scale the Nexus way.
If I did every single technique you have in your case studies with PO, DEV TEAM, NIT, and Scrum Master I’d be back at waterfall.
Dan, but it is not that new compared to what you are doing with Scrum already. The only difference is the focus for the NIT (as opposed to the each DEV TEAM) would be on dependencies and making sure they are addressed in each team continuously.
- REVIEW - Since you are developing only one product in the end you will have one review meeting instead of many. (that is simplification in my mind)
- PLANNING - There is an additional planning meeting to identify the right teams for the work and expose the dependencies so each team can have their own planning meeting with more transparent dependencies addressed first and foremost.
- RETROSPECT - The process improvement suggestions from each team retrospective (part one) are gathered to be discussed by the NIT representatives (second part) to bring forth the solutions that work for ALL teams and discussed again in individual team retrospective (part three) for implementation
- DAILY PLANNING - Appropriate representatives from each Development Team meet daily to identify if any integration issues exist. If identified, this information is transferred back to each Scrum Team’s Daily Scrum.
It took me this long to explain, but idea is pretty straight forward. meet first to identify the dependencies and make sure they are addressed first in each teams daily work.
The backlog refinement over and over to get to a Nexus sprint backlog to get to team backlogs feels a lot like a big old bunch of upfront design before you even get to coding. Does not feel very emergent or lean.
Scrum Guide - "Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items". I would consider refinement as one of the core development effort (not just coding), as this is one of the main ways we can make sure the items of high value are well understood so the right solution is derived to bring them to reality first. The biggest problem in transforming teams to agile mindset is to make them understand the importance of planning and thinking before doing things (especially to the highly technical folks who are so eager to just want to DO IT!).
The right work done for 1 functionality after careful amount of planning (detailed, ordered and estimated) is of more value and contains less technical debt than a poorly planned work done for 3 functionalities with no planning in the same time.
I picked NEXUS because I thought it was more streamlined than SAFE 4.5 and it is but not by much.
Same here. I am a fan of NEXUS. It is easy to teach to my teams to begin with. And I agree that this can be improved.
Still a lot of overhead and cost to training an org to scale the Nexus way
I think, I should agree with based on my experience of trying to scale teams, but this is still manageable compared to SAFe ! Also the more mature the individual scrum teams with their process are the easier it is to scale them.
That is why I always ask my management to not hire more people (with hopes of increasing productivity) without realizing the full potential from the existing team. They need to let the current teams mature and make sure they are doing at least close to their top potential before scaling. If not the overhead for the coaches and loss of performance will be unbearable !
Consider for a minute the number of communication channels, represented by n (n – 1) / 2. On a Scrum team of a Product Owner, a Scrum Master, and a Development Team of 3, n is 5. You have (5*(5-1))/2 = 10 communication channels. Nexus is optimized for 3-9 Scrum teams. Assuming 3 Scrum teams of the same composition, you would have up to (15*(15-1))/2 = 105 communication channels. However, Nexus simplifies this. The Nexus Integration Team works to ensure that teams don't all need to communicate with each other all the time. By spending more time at the NIT level to do refinement and order the backlog items to reduce dependencies, you are working to try to minimize the teams that need to coordinate inside of a Sprint. It's a tradeoff - a little more time and up-front work to ensure that teams can deliver work in their cadence.
As far as time commitments, there are two options for staffing the Nexus Integration Team. The members of the NIT can be dedicated to the NIT or they can be members of the Scrum teams. If they are members of the Scrum teams and they have responsibilities to the NIT, then yes, their capacity may be reduced. However, when they are dedicated, the capacity of a Scrum team isn't much different than a Scrum team operating by itself. The biggest changes are to the Sprint Retrospective as there needs to be opportunities for the teams to reflect on their own Sprint as well as across the teams in the Nexus.
Thomas, I like your explanation of the trade off w.r.t comunications: From 105 communication channels to 10 :)