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 :
- 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
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:
- Europe - (DevOps and automated testing) infrastructure – Kanban with learning time boxes
- Europe - Application Development – Scrum
- India Application Development – 2 teams, Scrum
- USA – Scrum
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.
Developments well after I left the building:
- pressure from regulators and board caused senior management to fall back to what they know plan on a page, Gantt charts, immovable milestones 6 months out. Milestones were hit by changing content of delivery. Ironically, whilst this team of teams argued against milestones, their electronic tool is remarkably good with milestone burn-up charts.
- Poor financial control made it hard to argue the Agile case – they felt that if they had tracked cost against deliverables it would have been easier to show (value or not). It was hard for them to measure value on a system most people just took for granted.
- There is still some roll over between sprints
- Relocation of USA team to West Coast caused a massive drop in productivity during the move and worsened an ongoing challenge with lack of time zone overlap. The folks in Europe and India are still working to try and make the USA team feel more connected.
- India-based-teams have excelled. India Team 1 is self-organising with minimal input from Scrum Master, India team 2 is getting there.
- DevOps tooling (with the exception of test automation) stopped due to lack of funding but is still carrying on as a "side of desk" activity as staff see the value. First stage will be automatic build from Git using Jenkins to push code to NonStop platform as there’s no suitable NonStop Git client, with build being run by Jenkins using existing (very old scripting language called TACL) macros.
- Re-work of testing using VersaTest has produced a much more accurate test pack with better test coverage. Tests now run clean and whilst not automated take one key press.
- Overall, it was a case of two steps forwards and one step backwards, but still overall forwards. Sometime in the next 6 months they will have automatic builds. They have decent metrics on what can actually be delivered by development. The teams in India are doing very well.
- I could be happy that I left a legacy of agility long after I moved away from this team. I left fine proteges behind to continue support as I always knew my time would be cut short. It was really the passion, focus, and energy of the people involved and I was lucky to work with these people. We went to Nexus as a stepping stone to LeSS. More support for Feature Teams and Theory Y thinking is needed to help that next step.
- I am already seeing signs in the rest of that Bank that people who now love working with agility will leave because we didn't get to the stage of transitioning non-agility roles & ways of working at senior leadership levels. Conveniently, as the change of walk the gemba was arriving at senior leadership's door, I think they decided, enough of this agility stuff, we're good now (even though we were only half way there). I regret not adopting a trick of not using any electronic dashboards to force walking the gemba earlier. People are already leaving. Theory X is back. People were trained on Theory Y only two years earlier. I have faith in the above team of teams but it's just a pocket, and things aren't likely to get better unless senior leadership understands the irony that good agility is Lean. Any one for a gemba walk? Oh, that's for everyone else too?
The change starts with me...