What are the experiences of a large group in a tier-one financial services firm adopting Large-Scale Scrum (LeSS)?
Background
J.P. Morgan’s (JPM) Global Core Processing Technology is a 3000+ strong organization operating across multiple locations globally, led by Simon Cooper. In 2013 the group decided to change to (real) Scrum, and the Large-Scale Scrum (LeSS) framework, which implied changes to the organizational design.
Previously, “Scrum-But” and various agile engineering techniques had been used sporadically, mainly in development teams, but there had been no significant change in the existing power or group structures, or in the interaction with business -- which was still “contract negotiation” rather than “customer collaboration”. There were still R&D project managers responsible for delivering a ‘contract’, team leads, single-function specialist roles, and separate component teams and functional teams (such as a testing group).
The decision to change the organizational design to the Scrum framework on a larger scale (LeSS) followed from an impactful session Craig held early in the year with Simon Cooper and his direct reporting managers.
This leadership session shone a light on the “contract game” dynamics at play in the organization which were acting as impediments to increased agility and improved deliver of customer-centric features.
The leadership session also explored the idea of real feature teams -- cross-component and cross-functional feature teams that could delivery end-to-end customer features without handoff, dependency, or delay. This would require the elimination of organizational barriers such as functional departments and component teams, and the related manager roles.
The management team were receptive to these ideas, seeing the possibility for increased agility, simpler planning and coordination, an increased value focus, and reduced delivery problems. And they now realized that changing to the Scrum framework would require organizational structural change and learning involving them, rather than their prior belief that “Scrum was just a practice for teams.”
Change within the Core Processing Securities Group
It was decided that in the path to Scrum, the Securities organization under Mike Goldverg would be the first to re-organize. This meant the Securities team had to consider being the first to enact far-reaching organizational changes. The group decided the following priorities:
- Clear articulation of the products the department supports and identification of Product Owners empowered to make release date, content, and priority decisions each Sprint.
- Creation of feature teams and removal of functionally-aligned departments.
- Elimination of Level-1 manager role.
- For remaining managers, a change in mindset and behavior from command and control to coaching and mentoring.
- Identification and development of master programmers as teachers who work directly with teams to coach Extreme Programming (XP) techniques, such as TDD.
- Important decisions, such as selection of Scrum Masters, would be made by the self-organising feature teams.
Traditional Component Teams and Related Planning
The Securities group had previously been organized in a traditional way, by architectural components, and each component had a manager-owner. The component owners had become accustomed to making decisions in partnership with multiple business units, predominantly as part of annual planning cycle. In order to deliver an end-to-end customer-centric feature, several component owners would need to agree on scheduling and priority, since a customer-centric feature typically spans multiple components. This upfront coordination planning (which in any event was often not realized in practice) would often be time consuming and involve many cycles of conversation and tradeoffs, as different business units (and features) competed for the availability and priority of the component teams and ‘their’ private code.
Identification of Larger Customer-Centric Products
As part of the adoption of Scrum, it was realized that customer-centric solutions or products involved families of components being delivered together, since customer-centric features typically spanned components.
Therefore, as part of the change to Scrum, the traditional component teams (and related manager roles) were eliminated and replaced by larger multi-component products reflecting more end-to-end customer-centric features. For example, a transaction processing product.
Identification of Real Product Owners
Changing to feature-centric products simplified planning and prioritization, because less coordination between separate management groups was necessary. Who would do this prioritizing? Rather than the traditional component owners or R&D project managers, we sought out business-side Product Owners, supporting the cooperative game of Agile development in which R&D and business people are closely collaborating.
Often, it has been difficult for us to find suitable Product Owners, because for decades the traditional model has been that the business-side would not be involved in development, except perhaps once annually to “define the requirements for the next year.”
The key has been to find senior, respected, and motivated -- typically by them understanding that the traditional model caused delay and inflexibility -- business-side Product Owners. This has involved partnering with Senior Operations executives to find the right people.
Within the Securities Operations organisation it was challenging to find the right people with all of the attributes and behaviours to be the Product Owners (there are multiple large products in Securities). This was due to the operations group being arranged in silos divided by business process. As a product would typically support many business processes there was no obvious candidates with the right level of seniority who could make priority decisions across a large product.
The solution was to create a small Product Owner group by cherry picking willing, bright, and experienced people from both R&D and Operations. A Senior Operations Executive was appointed who was experienced in building new products and given this responsibility.
Several of the new product groups are somewhat large -- with more than 10 feature teams. In those cases the new (single) Product Owner could not effectively interact with all the teams, so there was a need to divide and conquer. Rather than the traditional approach of dividing by architectural components again, we instead divided by areas of customer focus called Requirement Areas in LeSS. For example, in the Securities Processing product we introduced the Requirement Areas Market Onboarding (with 4 teams) and Regulatory and Control (with 4 teams).
Then, associated with each Requirement Areas (as per the LeSS Huge framework), we introduced an Area Product Owner that worked with the subset of teams focused on one area.
The creation of this group was a significant re-organisation and shifting of responsibilities away from the traditional project managers and component owners, towards more engagement with business-side people, and underlined the commitment of senior leadership to making LeSS work.
Feature Teams are Born
In the prior “Scrum-But” cases, the group thought they were “Sprinting” and doing Scrum with separate analysis teams, component teams, and testing teams, handing off work to each other in something like a waterfall process. But it was all just local optimizations, basically superimposing Scrum terminology on top of the traditional status quo organization. In the “Scrum-But” situations, delivering a customer-centric feature involved complex coordination between many groups, lots of handoff, staggered work, and high levels of multitasking. This led to long durations to deliver features, more defects, dissatisfaction amongst the developers, and ultimately client frustration and reduced business value delivery.
For the transition to real cross-functional Scrum teams that could do end-to-end features, Mike Goldverg visited his key sites globally and introduced the self-designing teams workshop technique described in LeSS (for more, see the ScrumAlliance LeSS article How to Form Teams in Large-Scale Scrum? A Story of Self-Designing Teams).
Each site took less than three hours to go from separate functional and component teams to cross-functional and cross-component feature teams. Each new team had a blend of domain, technical, and functional skills.
This has been -- and remains -- a challenging mindset change for the new teams, because now their responsibility is to deliver “done” customer features, rather than just doing a small part and “working to job title.”
The adjustment to feature teams was more challenging for some given the scale of the shift from centralised decision making and specialist groups to distributed decision making and cross-functional teams.
For example, one team member was previously a single-specialist Information Architect (IA). In the new Scrum Team model he was being encouraged by teammates to teach his IA skills to some other team member (to increase flexibility and reduce “key man” risk), and also to pick up tasks in a new secondary specialty of his choosing. But he just wanted to do IA tasks -- local optimization. He was good at it, but was actually acting as a bottleneck in overall throughput, reducing team flexibility, and increasing risk by not teaching someone else what he knew. Within a couple of months he found a traditional IA role in a different organisation.
Meanwhile, a few other team members who had IA skills (such as data modelling) as a secondary speciality were now able to work on and grow their skills in that area, which helped speed up the delivery of customer features, and reduced key man risk.
Before the adoption of LeSS the teams in Securities were under mandate to adopt certain core building block components. For example all datastore interaction utilised an internal proprietary framework which abstracted the application tier from datastore specific functionality. This API layer was private code owned by a central team. The result was that if any team found a bug or needed a change they would need to persuade the central team to prioritise the work and wait (often, a long time) for the next release cycle.
But, after adopting LeSS with feature teams and a more internal open source or collective code ownership approach, a more progressive stance was adopted. Some core common components are still built primarily by a core team but in partnership with the product feature teams. The code base is internal open source and everyone is encouraged to contribute and evolve the core components. Comprehensive automated tests which run pre-checkin ensure that all teams can work on trunk with confidence they are not breaking key functionality. And there is a component guardian from the core team that teaches other developers about the component and keeps an eye on the code/design quality. The result is that the lean waste of waiting has been eliminated together with a certain amount of frustration which existed with the old practices.
The overwhelming majority of team members embraced the changes. A team member who had previously been a dedicated tester was, within two Sprints, doing some regular programming and checking in simple Java changes (often via pair programming) and thereby developing a new secondary skill, in addition to continuing help with testing. Now her team has the flexibility of a member who can not only test but also perform development tasks, allowing them to deliver faster than before because there is more flexibility in terms of who can help with tasks.
And related to this was a change in HR policies, with the elimination of various function-specific titles such as Business Analyst, Tester, and so on. Instead, consistent with the Scrum Guide, the new job title is the more broad (product) Developer, in which people are encouraged to develop more than just one skill.
Many developers in the group now say that this is the happiest and most productive environment they have worked in as a result.
Elimination of Level-1 Manager Role
In some cases the best developers had been ‘promoted’ to level-1 manager roles or “team leads”. Although the original intention was that team leads would remain 50% active doing technical work, in practice most of their time has been consumed with traditional overhead management tasks such as:
This meant they were not able to spend time doing hands-on value-creation work for the customer (developing software features), even though, ironically, their high skill in hands-on work was often the reason they had been promoted.
Since a real Scrum Team is self-organizing teams without a team lead, the role was eliminated.
The ex-team-leads were encouraged to join features teams as regular members, and many relished the opportunity to be back full time doing what they were best at: analysis, coding, and testing!
To help address career path concerns, the leadership made a strong point in terms of communication and compensation: existing managers were encouraged to return to hands-on value creator, and would be very well paid for doing so.
Interestingly, even some Executive Directors (a relatively high-level role in the bank) who had previously been excellent developers (but more lately, doing management tasks), returned to hands-on development, the work they got the most satisfaction from. These moves have been publicly recognized and well-rewarded.
On the other hand, a few people from management who tried returning to teams could not (or would not) change to collaboration-based behavior in a team and still tried to direct other team members or make decisions that are now the remit of the Product Owner from business. In those few cases, the person eventually moves out of the organization.
One Vice President in the group who was a L1 manager prior to adoption of LeSS thrived in the new model as a team member. Now back to doing value work and no longer burdened by managerial responsibilities he earned the respect of teammates and the Product Owner; encouraged a culture of learning and as part of a feature team was instrumental in delivery of key features to the product. He was promoted to Executive Director as a result, and is still a hands-on team member.
The broad organizational goal is to create a culture of great well-paid hands-on long-term developers, rather than creating more manager positions.
Emergence of Line Coaches
Remaining technology managers were encouraged to change from a command-and-control mindset to a coaching-and-mentoring mindset as line coaches. The organization is significantly flatter without the Level-1 and functional managerial roles. Consequently, each line coach could be responsible (from an HR hierarchy perspective) for up to one hundred employees.
The attributes, behaviours, and responsibilities of a line coach are ideally as follows:
- Command and control mindset and behavior is replaced with coaching and mentoring.
- No longer responsible for project or feature delivery. The feature teams self-manage to deliver the “done” items prioritised by a business-side Product Owner.
- Help teams to produce maximum client satisfaction and product quality.
- Concentrate their personal development on:
- building and maintaining lean thinking plus their technical and domain skills
- helping their teams maintain focus on continuous improvement through Stop and Fix behavior, and improvement experiments
- practicing Go See and Help; leave separate offices and sit directly with teams
- facilitating versus directing; influencing versus forcing; mentoring versus evaluating
This is a seismic shift in the culture of a traditional bank, from a command and control hierarchy where managers were used to making decisions, giving directions, and being accountable for “meeting the contract.”
We came to understand why the previous cases of “Scrum-But” didn’t actually change that culture, because the old manager structures and specialist positions didn’t change. But in this closer-to-real Scrum change, the leadership actually transformed the structure and policies, and then we saw more meaningful cultural change. In short, really changing culture and behavior required first changing the system.
Not all new line coaches eased naturally into the new role. Some enjoyed and indeed thrived on the responsibilities of their previous responsibilities -- which included funding and the associated financial planning, delivery prioritisation, and stakeholder management.These functions were no longer relevant as they had transition to Scrum, with these responsibilities belonging to the business-side Product Owner.
In a few cases, the prior managers were not comfortable with the change, and then mobility moves were supported into other groups which were still following a traditional waterfall development approach with command and control management.
Teams Make Important Decisions
Prior to the adoption of closer-to-real Scrum, in either no-Scrum or “Scrum-But” cases, the technology managers would typically assign team leads and/or project managers to direct the teams. But in Scrum, self-managing teams are flat and teams are encouraged to make important team-related decisions -- such as hiring and firing -- for themselves.
In the example show in the photo below, Scrum feature teams at the Manilla site who were late (but keen) adopters of LeSS had identified the need for full time servant-leader Scrum Masters and raised this as an impediment with Matt. A session was arranged where the teams could interview and select (or “hire”) full time Scrum Masters, rather than Scrum Masters being assigned in a traditional command and control management system.
Most important decisions in the group are made in a similar way, with autonomous self-managing teams making important decisions.
Feature teams in Manila select full time Scrum Masters
In Conclusion
Within the Securities department some fundamental organisational changes have been implemented, towards a closer-to-real Scrum-based organization.
We’ve seen that the creation of feature teams has reduced handoffs, context switching, delay, key man risk, inflexibility, and single-specialist bottlenecks. Most of these are related to reducing the lean wastes.
Elimination of the Level-1 manager role has returned some of our more skilled developers to direct value-adding work where they are concentrating on the next generation of customer features, and doing more skills transfer.
For small, urgent demands the delivery cycle time is being measured and has improved.
For larger requests, release burnup charts have created transparency on progress and release planning. Software is integrated into production every Sprint so nebulous and unpredictable merge, integration, and test phases are a thing of the past.
And with Product Owners from the business side now involved, doing responsive planning based on inspection and adaptation, and working with smaller requirements, the groups are spending more of their time working on things of most value to the business.
The line coaches are learning to support and mentor rather than dictate.
Teams are empowered to make important decisions without the need for approval from above.
It’s far too early to gauge one of the most important tenants of success: client satisfaction. It will likely take several years for these deep structural changes to become a stable and effective norm with a new culture. But already there are some early encouraging signs: increased agility (flexibility, lower cost of change) and improved quality.
We’ll close with a comment made by one of our colleagues recently: “I’m really enjoying this, I couldn’t go back to the way we used to work. The team is happy, bought in to evolving and improving the product and able to concentrate on delivering value to the customers.” Team Member, Singapore Securities
About the Authors
Craig Larman is the co-creator (with Bas Vodde) of Large-Scale Scrum (LeSS), and an organizational-design consultant for enterprise adoptions and very large-scale product development with LeSS. In addition to being one of the first Certified Scrum Trainers, since 2004, he has helped groups with LeSS adoptions, such as J.P. Morgan, Ericsson, UBS, Xerox, bwin.party, BAML, ION Trading, Valtech India, and more. He is the co- author (with Bas Vodde) of the upcoming book Large-Scale Scrum: More with LeSS, and the two existing LeSS books, Scaling Lean & Agile Development: Thinking & Organizational Tools and Practices for Scaling Lean & Agile Development: Large, Multisite, & Offshore Product Development with Large-Scale Scrum.
Matt Winn is Securities Location Coach for Singapore and Manila at J.P. Morgan. He is responsible for coaching and mentoring over 100 staff who are members of 14 cross functional and multi-skilled Feature Teams in the Corporate and Investment Bank (CIB). Matt and the teams are focused on the Securities Processing product which is integral for many Business Units within the CIB. Prior to his current role he was Chief Business Technologist responsible for several mission critical applications. He has 15 years + of software development experience predominantly in financial services but also in computer communications, computer telephony integration, and the high speed telecommunications network test domains.
