Scrum Case

By Luciano Osorio – Scrum Master at Zappts

Free Translation and Adaptation of the Original Text from ValueGlide, written by John Coleman.

A large European bank had several teams per product that wanted an alternative to Scrum, Kanban, or Lean Startup.

The teams wanted a standard for these methods. That’s how Nexus+ was born, which is equal to the Nexus framework but with the addition of the Architecture Owner role. Nexus+ was adopted as a Digital Transformation tool at this bank.

In one instance of Nexus+ at this bank, there were 5 teams in a Nexus. Four teams were Scrum and one team was Kanban. One of the other Nexus had three teams: one Lean Startup, one Scrum, and one Kanban.

The Scope

The goal for the first 6 to 12 months of the transition to using Nexus was faster delivery. In parallel, there was a gradual withdrawal of the Waterfall/Scrum hybrid previously used. This promoted good agility, sustainable and purposeful. DevOps was the highest priority, with Lean Finances coming in second. The objective in each case was to be able to later focus on the customer and innovation.

The Boston Consulting Group’s DICE scores for change readiness at this bank would only be green/yellow if the 6-month goal was diluted or if the organization’s scope was limited.

The bank’s employees began to aim for better times and delivery rates with the goal of attracting more customers in the 6 to 12 month follow-up wave.

The scope was US$25 million in approximate spending.

Transition to Nexus+ and its Instances

Nexus was used to have more or less monthly Sprint Reviews across the entire portfolio. Predictions were made with Monte Carlo probabilistic simulations to identify “incredible plans”.

There was also internal capacity development. When there were cost cuts, the organization could continue its agility journey without losing pace.

In one of its instances, Nexus+ was implemented with distributed teams. The responsibilities and methodologies of each were:

• Europe: infrastructure (DevOps and test automation). Kanban with structured learning time.
• Europe: application development. Scrum.
• India: application development. Two Scrum teams.
• United States: application development. Scrum.

Nexus+ Roles and Challenges

The Architecture Owner is an important role, as they are responsible for the back end flow. In the case of this bank, the back end involved credit and debit card authorization.

The 5 teams implemented test automation and monthly releases. Previously, releases were irregular and driven by project execution. This reduced predictability and caused sequencing problems.

For example, if a project had a late-delivery component, related projects needed to reconsider and redo their tests. This allowed for around 6 to 10 releases per year.

All of this was done on legacy technology. For this reason, there was a need to resort to end-to-end automated testing, rather than TDD (Test Driven Development).

All card transactions went through the legacy technology. The teams were changing it every month using DevOps.

The teams had a disciplined Product Owner, an agility-oriented Architecture Owner, appropriate Scrum Masters, appropriate Scrum, appropriate Kanban. This eliminated the Waterfall/Scrum hybrid quickly.

There are always new challenges. Solutions cause new problems. For example, one of the challenges in this Nexus+ instance was synchronization between the US West Coast and India.

Outcomes

Despite all the changes, the pressure from regulatory bodies and the board of directors was significant. As a result, management retreated to what they know – planning on pages, Gantt charts, and immutable milestones for the next 6 months.

The milestones were reached by altering the content of the deliverables. Ironically, although this “team of teams” had argued against the milestones, their measurements were incredibly good, with milestone burndown charts.

Unsatisfactory financial control made it difficult to argue the case for Agile. The board believed that, if they had tracked cost against deliverables, it would have been easier to show value (or the lack thereof). It was difficult for them to measure the value of a system that most people simply considered natural.

The relocation of the US team to the West Coast caused a massive drop in productivity. This aggravated the time zone difference challenge. People in Europe and India had to make an effort to try to make the US team feel more connected.

Change Tools

DevOps tools (except for test automation) were discontinued due to lack of funding, but they still continue as a parallel activity and as the team perceives value in them.

The first stage will be to automatically build from Git using Jenkins to push code to the NonStop platform. Since there is no suitable NonStop Git client, with the build being executed by Jenkins using existing macros (from a very old scripting language called TACL).

Test rework using VersaTest produced a much more accurate test package, with better coverage. The tests are now clean and, although not automated, they can be run with the press of a button.

Overall, the balance was positive. In the following 6 months, automatic builds were implemented. The metrics used on what can actually be delivered by development are decent. The teams in India had good results.

Conclusion

The passion, focus, and energy of these people is what moved the team. Nexus was a springboard to LeSS. More support is needed for Feature Teams and Theory Y is necessary for this next stage.

Conveniently, when the change was reaching the board of directors, there was resistance. Employees are already leaving and going to other companies. Companies that have no resistance to agile methodologies.

There is no improvement if the board does not understand this.