Nexus and Nexus+ at an international payments company

The goal for the first 6-12 months of the change was faster delivery (while still focusing on the customer where we had opportunity) all the while deprecating WaterScrumFall, promoting good sustainable purposeful agility, transitioning the organization design to agility, with DevOps 1st and Lean Finance 2nd. The goal in each case was later to focus on the customer and innovation.  

We were all for creative tension, but said to ourselves “why start a >70% chance of failing on a bad footing?”. Our Boston Consulting Group DICE scores for change readiness only went green/amber if we either diluted our 6-month goal or limited the scope of the organization we attacked so to speak.
“Why promise lots when you’ve got delivery plumbing problems” was the rationale. When DICE scores were poor, it didn’t take long to decide to :

• go narrow and deep where there is “strong pull”, or
• simply aim for better lead times, delivery rates and failure demand, with a view to chasing more customer in the follow-up 6-12 month wave

Spend in scope, in our sphere of infuence, was in tens of millions of USD in the payments company. We avoided metrics and went for measures and trends; we even influenced CxO objectives.

Case Study

My role here was to help figure out the co-design of a DevOps first transformation design. I rolled off just as implementation began but I received confirmation that the design was appropriate and fit for purpose. I had  implemented Nexus+ before, but this time it was a bit of a bigger deal. We needed to do the following:

• deliver faster while keeping everything safe – we embraced the State of DevOps reports – a focus on better leads to cheaper
• deprecate WaterScrumFall
• transition all non-agility roles to  agility
• provide a toolbox of methods so we wouldn’t have “one size fits all”
• Figure out a way to synchronize work with people in different methods with dependencies / constraints on each other
• cut across the functional silos to have cross-functional teams
• overcome the “utilization mindset”, probably by adding “intangible” work to Scrum/Kanban boards and by using Kanban measures such as lead time, failure demand, and delivery rate
• consider Cost Of Delay ranking and Black Swan Farming (small bets) to overcome HiPPo ranking
• demonstrate control with fit for purpose outcomes, not senseless deliverables

It was apparent that some teams could not use Scrum, due to a control mindset. Given that Kanban, as per the latest Essential Kanban Condensed guide, can tolerate that situation more easily we let those teams use Kanban, and we encouraged them to use Kanban by the book for now. This was a scenario where check-lists were likely to be used as a “culture island” (Edgar H. Schein), much like they are in the airline industry, such was the task orientation and muscle memory.

Smart people will notice an error on the checklist – it’s a checklist for Scrum, not Nexus – PBR is an event in Nexus:).

It was also apparent we’d be more set up for success than in other transformations, as we were starting with DevOps first, spending millions on infrastructure to enable continuous delivery pipelines. Plus, we were making the immediate transition to long-term stable product teams from projects and programmes. There was a fly in the ointment, DevOps should have been called Dev, as the CD pipelines only went as far as pre-production. Adding the Ops piece was going to be a longer-term negotiation, as the “keep the bank safe” (still) is a really strong principle for them, as one would expect. At the State of DevOps reports in the world weren’t helping us much. We needed like-for-like reference sites also, which we eventually found.

We were desperate to avoid SAFe as it would not move the organization enough. We wanted LeSS, but Kanban was a fly in the ointment, no disrespect to Kanban, which I also teach and love. We had a suspicion that SAFe would become a default option and the current order would be preserved. We wanted to go “the whole hog” so to speak. But we couldn’t use LeSS. We wanted to use LeSS on some products when we could so our Nexus+ was not so much a Nexus of Nexus but a Nexus of Nexus/LeSS, with a view to getting to LeSS Huge in the long term.

I decided to leave for another opportunity but before I left I met the people on the ground pessimistically expecting the notions of Nexus+ to be blown away by reality. But I had nothing to worry about. People just wanted to get on with it. 

So we opted for Nexus +, Nexus of Nexus, capable of handling up to 81 teams, and with adaptation, it could handle (good) Kanban as well as Scrum. We wanted to avoid the “slippery slide” back into WaterScrumFall, which to my mind is the biggest anti-pattern in agility.

We got exec and senior leadership objectives aligned to what any decent agilista would dream for. The sponsor was (and still is) incredible, so much charm, intelligence, people sense, and humour. As much as I can be certain about anything, I am certain I will read wonderful articles about him, his wonderful transformation team, and the transformed organization. Because it is still a struggle, I know they’re doing things right.

 

Developments after I left the building

• Nexus caters better for non-feature-teams and can be adapted for other methods more easily. Nexus is great, but my view is that LeSS Huge is better thought through than Nexus+, and for that reason, the aim should be to move to LeSS Huge, product by product, requirement area by requirement area, whilst using Nexus+ as the scaffolding to keep WaterScrumFall at bay. Nexus has a short guide, LeSS has three fat books.  More on LeSS in a future post….
• The team seems tired and it’s only the start. I hope they look after themselves and each other properly. It’s a marathon. It’s a rock-star team, and I hope it stays that way.
• If I hadn’t an opportunity for a large case study on developing I am the Change agility change chefs, I’d be back in a flash if they’d let me.

Next posts will be 1). LeSS pracitioner course lightbulb moments, 2). a parody on the state of agility, 3). a review of Barry O’Reilly’s SEACON UK talk on 10th April 2017, and 4). Scrum Vs Nexus Vs LeSS Vs SAFe,