Synchronized turtling - Benny Mazur
This post is a supplement to my general post on Nexus and Nexus+. The Nexus format for these experience reports is essentially the same with additions of Kanban or The Lean Startup in "sprints"; the Nexus Integration Team is accountable for minimizing dependencies across all teams in the Nexus, and is accountable for a combined potentially shippable increment. I jokingly called it "KanScrumUp", but I wouldn't wish another framework on you. So it's Nexus with some tweaks. So perhaps this is not a fair account on Nexus. There are plenty of posts that already explain pure Nexus hopefully.
We had a number of teams per product that wanted a choice of Scrum, Kanban as per the 2016 Essential Kanban Condensed Guide, or the Lean Startup. The teams wanted a pattern. I wasn't aware of a pattern for those methods. So I modified Nexus as above. And in one Nexus+, I added the Architecture Owner role to reduce organizational "anti-bodies" while still urging emerging design by self-organizing teams.
We had three instances of (modified) Nexus - one across all initiatives, in one of those initiatives. In one of the initiatives, we had 5 teams in one Nexus, mostly Scrum teams, with one Kanban team; the other Nexus had three teams initially, one with Lean Startup, one with Scrum, one with Kanban.
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 :
The scope was 25m USD in spend pa roughly. We had an agility maturity model which was useful. I didn't like the targets, the targets were set based on progression through the agility maturity framework. But they were useful, in that I understood how leaders were motivated.
Looking back now, I’d say that senior management commitment turned out to be lower than in the example. When push came to shove, top down management fell back to Gantt charts as a safety blanket.
....we used Nexus to have more or less monthly Sprint Review across the portfolio and we pressure tested all forecasts with Monte Carlo probabilistic forecasting to spot what we called "incredible plans". We also ensured we developed internal capability so that when the hatchet would drop on my cost entry, the organization could continue its agility journey without missing a beat.
One of the bigger initiatives was really interesting, as we were bringing the old tech world of the bank to agility and DevOps:
The Architecture Owner had a strong role as this was back-end plumbing (card authorizations - no pressure). Courage, tenacity, accountability, knowledge, humanity, quality, professionalism personified. I never had to say or ask anything of the Product Owner or the Architecture Owner more than once. The Scrum Masters and Development Teams were quick to shift mindset and that all helped. Courage, tenacity, accountability, knowledge, humanity, quality, professionalism personified.
The 5 teams implemented test automation and monthly releases. Previously, the releases were irregular and project driven, which reduced predictability and caused project sequencing problems e.g. if a project had another component that was late, close following projects had to re-baseline and test. We had 6-10 releases a year.
This was on really old technology, as in a good contender for the oldest technology in the bank award. Because the technology was so old, we had to resort to end to end system automated tests as opposed to Test Driven Development (TDD). All those card transactions I mentioned earlier in the post were going through the technology these teams were changing every month. These teams overcame "protect the bank change the bank" paradox, by embracing DevOps. We had a proper Product Owner, an agility oriented Architecture Owner ( just to tick the Disciplined Agile standard box and deal with that paradox), proper Scrum Masters, proper Scrum, proper Kanban. We had zero tolerance for WaterScrumFall. As it turned out, all teams went for Scrum in the end. #proud #readyforLeSS
One of the other initiatives in my sphere of influence that was spending 15m USD approx expressed a strong interest in Nexus before I left....
After I left, the Nexus rhythm kept going. There are always new struggles. Solutions cause new problems. Synchronization was still a challenge when I left between West Coast USA and India.
The change starts with me...
John Coleman has been knocking around with agility since 2004, starting with a mission critical piece of work back then against advice and taking on ever more scary work since then :). A speaker, consultant, coach and trainer on all sorts of agility.
Nexus images copyright of Scrum.org. Nexus+ images were...