Steps Towards a LeSS Adoption in a Large Investment Bank

Background

(VBB is a pseudo name. Corporate policies restrict the usage of the actual company name. All names of individuals in this case study are also pseudo names.)

This report is about a 2015-2016 Large-Scale Scrum (LeSS) adoption experience, shared by the two agile coaches, Stuart and Gene, that were hired into VBB to help with an agile transformation. The coaches had some prior understanding of VBB’s internal dynamics.

The product scope for this LeSS adoption was document management for the intake, transmission, and storage of legal and financial documentation.

Prior Organization

VBB departments have a traditional organizational structure, with multiple reporting layers and middlemen. For example,

Development group: There were on average 5-6 reporting layers of management between the overall VBB CIO and real hands-on developers.
Business group: Multiple layers of “translators” and “delegates”, such as BAs, PMO, and various engagement managers, in between the real hands-on users of software and the real developers

Prior to the LeSS adoption the Development group had component teams. Requirements intake was typically done by Development group business analysts, interfacing with Business Group business analysts, interfacing with either other middlemen or real users.

The Component Teams and “Products”

Prior to the LeSS adoption the document management solution was composed of a few narrowly defined so-called “products” that were just components, with component teams attached, and as usual with component teams, none created complete cross-component end-to-end customer-centric features.

The component teams and related software “products” are shown in Figure 1:

• CAP - A newer component for capturing data from another upstream system, external data-feed or manual entry
• COM - A newer component for communicating captured data from system to system and, ultimately saving it as a document
• CAR - A legacy component that recorded all documents

Adopting “Faux Scrum”

There had been an initial attempt to implement a faux “Scrum”. Each team member was still a single specialist. There was almost no interest in learning new functional domains or technologies, as everyone’s job title was ‘business analyst’, ‘tester’, ‘front-end developer’, ‘manager’, ‘architect’, etc. Lack of motivation by people to learn additional functional and technical skills was driven by the process of individual goal-setting and performance reviews, enforced by line managers. Everyone’s end-of-year performance and discretionary incentives (bonuses, promotions) were based on an individual’s ability to prove that they delivered as per their original job descriptions (and did better than their peers/colleagues). For example, business analysts were measured based on how efficiently they were able to ‘write stories’, testers were measured on how many bugs they were able to discover, and so forth. This also led to local optimization by each single function and subsequently, to sub-optimization of the overall organizational system.

Because of that, everyone was risk-averse and not willing to experiment with anything new or innovative , as it would make them being perceived as ‘less efficient’. This was a class manifestation of Law # 5 of Larman’s Laws of Organizational behaviour (“Culture follows Structure”), in which one can’t realistically expect people to behave in a way that is very contrary to the organizational system, especially when it involves salary and career promotion.

Naturally, this “Scrum” adoption with component teams and single-function specialists and traditional manager roles and policies did nothing to increase adaptiveness or quickly deliver end-to-end high-quality features, and it demonstrated massive waste.

Existing Preconditions Supportive of LeSS Adoption

The following were some internal preconditions within Development that were already supportive of LeSS guides and experiments before the coaches got engaged:

• PMO, as an organizational unit, was dissolved and some remaining PMO-like functions were reabsorbed by teams (e.g. scheduling, forecasting, work assignment, progress monitoring) and business people. (LeSS experiments: Avoid… Project Management Office, Avoid… So-called Agile PMO)
• There was a clear understanding that having Scrum Masters doing performance appraisals on team members would be a serious dysfunction. (LeSS experiment: Avoid… Scrum Masters do performance appraisals)
• Even with initial adoption of faux “Scrum”, teams started to define and adhere to a (very incomplete) Definition of Done with each Sprint. (LeSS guides: Creating the Definition of Done. Evolve the Definition of Done)
• In the Development group everyone understood that adding ‘fake’ team members (e.g. project managers, “powerpoint architects”) to teams would not help. Instead, it would just create an illusion of having a ‘bigger team’ (LeSS experiment: Avoid… Fake team members)
• Senior managers were comfortable to be referred to and acting as “IRS” (Impediments Removal Service), rather than as a “change management group” (LeSS experiment: Try… Impediments service rather than change management). For example, a senior manager when receiving a call or email from a team member with a problem would not delegate, but rather offered a meeting.
• Multisite planning poker was already effectively used by leveraging some simple tools and video equipment (LeSS experiment: * Try… Seeing is believing—ubiquitous cheap video technology and video culture.* Try… Multisite planning poker (estimation poker)). For example, each team had its personal common area equipped with a video camera, speakers, and a small whiteboard. This made the use of physical planning poker cards possible (no need to mess with more complicated software), as each team member could flash their physical voting card to people in the room as well as to the camera. Whiteboards were used to do quick note-taking so that people in the room and through video camera could see information.
• Centralized (organizational) coaching departments (e.g. so-called “agile center of excellence”) and centralized agile/lean cookbooks were already viewed as a sign of faking, re-labeling the status quo, and local optimization that would eventually lead to building silos of disconnected and privileged coaches (LeSS experiments: Try… Prefer decentralization solutions over centralization ones. Avoid… Central coaching group with formal authority.’ Avoid… Internal agile/lean cookbooks). The organization saw value in deeply embedded coaches that worked closely with teams and business or product people. People preferred embedded coaches working together as a community (image on right) over secluded power structures of ‘chiefs-coaches’. See Figure 2.

Initial Steps for the LeSS Adoption

The coaches limited the scope of the adoption to about 50 Development and 20 Business people.

This was consistent with one of three LeSS adoption principles that states that for a successful organizational adoption of LeSS, it must be “deep narrow over broad and shallow”. To take this further, one of LeSS guides also suggests that when adopting LeSS, organizations must “..focus LeSS adoption effort on one product group, give them all the support they need, and ensure they work really well….”

Defining a Broader Product Definition

Consistent with the LeSS rule to define a software product as broad as possible, the CAP, COM, and CAR components were merged into one broader product definition. Why not broader? This was the limit of scope of influence of the management involved in the LeSS adoption.

The coaches recognized that merging the CAP, COM, and CAR components into one broader product definition still did not create a complete end-to-end customer-journey software product. In order for the software to be a complete end-to-end, it would actually have to include other software components (and teams) in the bank, such as:

• Regulatory components
• Client on-boarding components
• Legal components
• HR and Recruitment components
• Purchasing components

However, that broader definition was not yet possible.

Moving towards Feature Teams

Since component teams are not consistent with global adaptiveness, working on highest value, or low total end-to-end cycle time, they had to be replaced with cross-component feature teams, reflecting the LeSS rule that the majority of teams are end-to-end feature teams.

The coaches facilitated a pre-workshop activity with senior management and stakeholders, representing all three components. A couple of visualization techniques (business value flow, customer journey, story mapping) were used to engage participants in a dialogue and a series of use case simulations that revealed that neither of the individual components represented a complete end-to-end customer or user feature.

Perhaps the most important education activity during this step in preparing to create feature teams was the following:

Managers had to learn to see that component-team development was the root cause of integration and excessive cross-team coordination problems.

It was important that they understood some organizational implications of moving from component teams to feature teams. Specifically, with feature-team development, the control by existing VBB “component owners” would need to be eliminated. As will be explored later, this issue will become one source of dysfunction in the adoption.

The original CAR component team was in an external (and very remote) vendor company. It added an additional degree of complexity: time zones, vendor middlemen, handovers, and above all, commercial contracts influencing dysfunctional to internal behavioral “contracts”. As a part of moving towards feature teams, it was decided that vendor developers would be mixed with internal developers, in ways that would de-emphasize belonging to different companies and emphasize belonging to the same feature teams. A series of meetings with VBB and vendor managers were held about the importance of having legal contracts written in ways that supports agile ways of working Some LeSS experiments were presented and discussed in the context of what was known about the existing organizational dynamics:

• Try…Lawyers study problems arising from silo mentality and lack of systems thinking
• Try…Lawyers study agile, iterative, & systems-thinking concepts

The coaches also suggested that corporate attorneys should be invited to future training and coaching sessions. )

The coaches also organized a full-group training workshop. The coaches covered basic tenets of Scrum and LeSS. Particular focus was put on the difference between Scrum and LeSS, with respect to roles, events and artifacts. In training, developers were mixed with business people and managers at tables, for better collaboration and learning (there was no ‘developers-only’ table, or ‘managers-only’ table). During the workshop the coaches covered all LeSS rules and principles. They also discussed LeSS guides and provided some examples of documented LeSS experiments. The audience was also introduced to LeSS Huge but it was made clear that it would not be necessary in this adoption (since there was less than “8” feature teams).

Self-Designing Teams Meeting

Before facilitating a self-designing teams meeting, both coaches studied one of the older case studies, that described a similar event at another large bankfinancial company). This was helpful as the coaches got to read about some practical techniques that could be used with the teams.

Graphic illustration of key elements of the new product group was visualized on giant whiteboards: the components, other supporting applications outside the group, individual skills and domain expertise required, and geographic locations. A few additional graphic illustrations were written on flip-charts of historical learnings of shortcomings of working in siloed ways, to remind people ‘the WHYs’ behind the exercise.

During the meeting some managers were on standby to address organizational issues, should those arise. Specifically, going into this meeting, there were some concerns about:

• attempts by prior designated team leads to influence decisions of others
• building teams around existing reporting lines and/or single components (e.g. UI or DB team)
• persons not wanting to be on the same team with someone else because personal dislikes, etc.

Managers were explicitly asked to stay out of the self-designing teams meeting unless concerns became true risks. Luckily the only manager involvement that was necessary was providing some information about a small handful of newly hired but not yet on-boarded developers that would be added to the team within weeks. Another managerial input was reinforcing that the newly formed teams would be long-lived.

Of course, the key activity of the meeting was that people self-organized into new teams. This was done with all people coming together and discussing best ways to cluster into teams to deliver end-to-end features. The LeSS “use volunteering” adoption principle was used. At the beginning, everyone was reminded of the goals of the product and the workshop, as well as what it would mean to form well-structured teams, by ensuring that each team is co-located, cross-functional, knowledgeable of several components, self-managed, sized between 3 to 9 people, and long-lived.

Finally, three collocated feature teams were formed to work on the same product, sharing one Product Backlog.

The Initial PBR Workshop

Before starting Sprint 1, the product group decided to follow one of LeSS guides and hold an initial Product Backlog Refinement (PBR) workshop, during which the scope and vision of the product were clarified, key people required for work selected, highest priority features identified, and an initial Definition of Done clarified.

Here is an example of the vision statement for CAPCOMCAR:

“VBB employees and external clients will prefer to use our document capture platform as the most efficient solution that enables timely setup and management of products and accounts and conforms with global, legal, regulatory and control requirements. The process will include information capture, communication and storage”

During the workshop both business and development stakeholders agreed on the high-level product themes and strategic, long-term goals. Facilitated by the coaches, this was done by using a combination of user journey identification and story mapping techniques and helped visualize big work that had strategic meaning. All future work was captured in one shared Product Backlog.

Finding a Product Owner and Domain Experts

Identifying someone for the role of Product Owner was challenging. It was practically impossible to find a person that would have a sufficient strategic vision and enough organizational empowerment to set priorities for multiple teams. Finally, such a person was found in the business group.

But then another challenge was faced: she did not have any knowledge of basic Scrum (let alone LeSS), and thus, of the role of Product Owner. This was addressed by helping her through Scrum training followed by personal continuous coaching support by one of the coaches.

Lastly, the product group was directly introduced to real hands-on internal users that were asked to be available to provide clarifications and details to the teams. Special care was exercised in selecting these people and making sure that they were not middlemen, delegates, or proxies. Three individuals were identified that had a lot of hands-on knowledge with each one of the above mentioned components (and related steps in the Document Management process): CAP, COM, CAR.

Forming Communities

In line with the LeSS guide and experiments, several communities were created. (LeSS experiment: Try… Cultivate Communities of Practice. Try… Use CoPs for functional learning.)

This started with a Scrum Master Community. Emphasis was made on improving facilitation skills of Scrum Masters and their ability to distinguish between team-level (internal) impediments and organizational (external) impediments. Based on the community involvement it was easy to differentiate between individuals that could become great candidates for the role of Scrum Master and those that would not. Through the community, Scrum Masters were able to further develop.

There was a lack of maturity in automated testing. To remediate this a Test Automation community was created. This allowed experience to be shared and establish better testing practices. This gave birth to gradual absorption of test automation activities into the teams.

Flattening Organizational Structure and Communication

(LeSS Experiment: Try… Keep the organization as flat as possible)

A key message that was frequently delivered to management was that organizational design is the first order (key) factor that influences organizational culture and individual behaviours, and the behavior of the overall organizational system. Various coaching tools and techniques were used to help people see this: causal-loop diagrams, surveys, discussions. As a result some steps were taken to improve dynamics within Development:

• Strong messages were delivered by senior management that becoming a ‘line manager’ (by title) and acquiring reportees did not equate to a guarantee of promotion or salary increase
• The number of people reporting to the same manager was increased to the upper recommended level of about 20-25.
• Individuals were encouraged not to perceive their immediate line manager as an impermeable layer, above and beyond which they were forbidden to go. On the contrary, a series of meetings with line-manager+1 were instituted.
• To strengthen the message that line managers were not the only channel for communication, more senior management (at the recommendation of the coaches) instituted the Impediments Removal Service (“IRS”) so that any team member could escalate their problem.

Below (Figure 3), is a graphic illustration that was used to educate the organization on the concept of organizational flattening that was required for scaling organizational adaptiveness:

The Early Sprints

Running a Sprint in LeSS

The following was implemented by the teams:

• Sprint Planning - Multi-team with whole teams in attendance.
• PBR - Overall Product Backlog Refinement (PBR) sessions were followed by multi-team PBRs, during which the teams discussed low-level implementation details. The coaches made it explicit that having single-team PBRs would be undesirable, because it would lead to creating separate “implicit” Product Backlogs per team and local optimizations.
• Sprint Review - Attended by all teams with Product Owner, users, and stakeholders.
• Retrospectives - There were team-specific Retrospectives attended by Scrum Masters and teams only. There was an Overall Retrospective attended by Product Owner, team members, and Development managers. The latter was invited to learn and take responsibility for removing organization-level impediments.

Early Results and Perceptions by Business

The first step of the LeSS adoption to a broader product and feature teams impressed the users enough to ask for more. In short, they said, “we really like what you have been producing and we want more of it. What would it take to have more features delivered to us, more frequently”?

Why were the users pleased with the initial results of the LeSS adoption?

• First, they were able to see more complete features at the end of each Sprint, not just disjointed components that require further integration.
• Second, thanks to teams’ improved design and stability, consistency of delivery was increased. It further led to improved ability to forecast delivery of features to users.
• Third, and as a result to the first two points, overall relationship between business and technology improved. Trust and respect started building up.

Expanding from Three to Five Feature Teams

Because of the benefits and also the desire for more features, two more teams were created with developers from the same technology space, and put through some initial preparatory steps.

These steps included: a refresher training on basic Scrum, introduction to LeSS, familiarizing new teams with the Product Backlog, priorities and strategic goals, and then bringing them into the LeSS product group for an upcoming Sprint.

One of the experienced Scrum Masters from the first three teams was asked to serve the new teams, and the other Scrum Master served the original three teams. Now the product group of five teams had two Scrum Masters. This was in line with a LeSS rule: “A Scrum Master is a dedicated full-time role. One Scrum Master can serve 1-3 teams”.

A few senior developers from the first three teams were asked to temporarily take on the role of developers-travelers (LeSS experiment: Try… Travelers), and join the new teams, to lead by example and provide some guidance. The travelers temporarily became a pivot for each of the newly created teams by teaching new members not just the dynamics of LeSS but also certain nuances of different components that the new teams did not know.

To speed the process of assimilation with more experienced teams, all teams agreed that both new teams would be coming to multi-team LeSS events (Sprint Planning 1, multi-team PBR) in full, whereas the three seasoned teams would be sending just representatives. Also, for a few initial Sprints, the two new teams went into multi-team Sprint Planning 2 with at least one of the original three teams. This approach was used for a few Sprints until everyone gained confidence that the newly joined teams became comfortable enough with the process of the LeSS events.

Changes in Running a Sprint with Five Teams

Sprint Planning - Part 1 (“what”) and 2 (“how”) became more clearly distinguished in purpose and attendance. Part 1 had just representatives from the three mature teams, plus all members from the newly added teams. Having all new team members made sense: while planning sessions did not get too crowded, newbies benefited from attending and learning together.

In Sprint Planning Part 2, the goal of each team was to define its own Sprint Backlog. Given the nature of work and the preference to discuss technical solutions of backlog items together - something that would increase domain knowledge and mutual understanding of the work, as well as allow leaving decisions about which team picks up which Product Backlog item until the last possible moment, the 5 teams would typically do planning together (LeSS Guide: Multi-Team Sprint Planning Two). Rarely, the teams split up into two teams + three teams sub-groups for planning .

Organizational Elements That Limited Improvement

Finance and Budgeting Policies

(LeSS Experiment: Try… Beyond budgeting)

At VBB, there is a strong belief that “everyone must follow the plan and say on-budget”, as opposed to “everyone needs to be able to respond to changes, and take advantage of newly raising opportunities”. As such, budgeting is still done traditionally by once-a-year allocating a fixed amount to new projects (with fixed timeline and scope), basing decisions on a prior year’s expenditures and coarse-grained estimates from hands-off Development managers.

With this approach, the following challenges are constantly in faced:

• Of course very broadly, delivering the wrong thing and not responding to changes and learning, because of a project model rather than a product model.
• Decisions about what to do made by Development managers, rather than a business-side Product Owner.
• Inacuracy of estimated budgets are translated unexpectedly de-scoping critical features, and by doing so, upsetting users.
• Rushing to deliver fast, without proper testing, and by doing so, compromising product quality.
• Terminating good but more expensive developers and hiring cheap low-quality developers.
• Related to the all above, process-heavy budget-extension requests that are frequently accompanied by finger-pointing between Development and Business, leading to relationship deterioration.
• Fea by developers to experiment and innovate, because experimentation and innovations are not budgeted for.
• In some cases if an allocated budget is not fully spent by year-end, ‘burning’ it on something unimportant. Otherwise risking not getting the same amount the following year.

The coaches organized a workshop to educate managers in

• adaptive budget planning
• work on a product with continuous adaptive delivery rather than on projects
• differences between output and outcome

One of LeSS experiments “Try… Beyond Budgeting” was introduced and explained by leveraging industry examples described in “Implementing Beyond Budgeting” by Bjarte Bogsnes (selected excerpts from the author’s book were reviewed).

Although the coaches were able to develop appreciation by management for these ideas, unfortunately, conventional top-down fiscal year planning remained the official approach to do budgeting during the LeSS adoption.

However, the limited victory that the coaches had was convincing the management to consult more frequently and directly with teams with respect to forecasting, and with the Product Owner with respect to emerging needs and (re)prioritization. These conversations started happening every month (after every second Sprint).

Product Owner Availability

One issue was continuous unavailability of one of the key stakeholders, whose input to Product Owner and the teams was critical. This person was continuously travelling and not too keen to attend Sprint Reviews. Instead, she would send delegates to ‘represent her views’. This was not sufficient, since information was often skewed and twisted in translation. Senior management took necessary steps to ensure that the required person became available in future Sprint Reviews.

Existing Reporting Structure

While the LeSS structure prevailed, and the self-formed teams were also self-managing, without any apparent interference from first-line management, the formal traditional reporting relationships were not officially eliminated. This was primarily due to the twice-annual performance-review process forced by HR. This led to a variety of wastes and some conflicts.

Managers Going Around the Product Owner

Even after CAPCOMCAR product was properly defined, teams properly structured and Product Owner elected, there was still one issue remaining: communication.

There were still attempts by technical managers of Development, that were outside of LeSS product group, to request technical improvements and “side work” from teams, without cleaning it first with the Product Owner - and justifying their actions by perceived urgency. For some time, it continued, despite strong recommendations by the coaches not to do so and follow LeSS the advice in the “Getting Started” guide instead: “only the Product Owner provides work for the teams” and “keep project managers away from the teams”.

Given the potentially unpleasant implications to developers (e.g. accusing them in not respecting subordination boundaries, leading to low performance appraisals), of refusing to obey hierarchical lines, an experiment was attempted by the teams to* inform* the Product Owner of such managerial “emergency changes”. This was done implicitly, rather than explicitly, to avoid inflaming situations, and as follows:

On a few occasions, line management was invited in PBR sessions as guests where they were asked to state their most pressing needs explicitly and candidly, in front of Product Owner and some key stakeholders. This was discussed in the context of the teams’ capacity and priorities coming from the business. Very diplomatically, line management was put in a situation, when they had to negotiate not with the teams but with Product Owner directly - what priorities should be. The teams merely observed and contributed to a dialogue in various ways (e.g. clarifying capabilities, limitations, dependencies, etc). By removing themselves from potentially unsafe negotiations, the teams were able to focus more on work and less on politics. This approach has worked, as the teams were no longer as exposed and were out of harm’s way.

Minimizing Side-work and Supporting Single Product Backlog

Due to a significant amount of interruptions it became critical to increase transparency on the associated dollar-cost of unplanned/”hidden”/side-work. As it is often the case within large enterprise organisations, facilitating big changes required an empirical approach. For this, the teams were advised to stop using a separate backlog to manage interruptions and side-work, and instead keep all of their work in one shared Product Backlog. This allowed the Product Owner to refer to one single “source of truth”, instead of multiple independent “containers of wishes” - to see the overall amount of work the teams were asked to deliver, with conflicting priorities, and by doing so, set real priorities.

Taking into account inevitable work interruptions, helped manage the teams’ capacity and better reflect it during planning. After several Sprints, senior management was presented with the data that illustrated how ad-hoc, unplanned/interruptive work diluted the teams’ attention and shifted their focus away from planned and forecasted product-centric work. The main way to illustrate the problem was data collected from cumulative flow diagrams (CFD) that exposed how long Sprint work, on average, spent in each status. Overall, WIP for each Sprint backlog item was very high and it was mainly due to frequent interruptions (start-stop-start-stop), caused by new, unplanned work, being forced into a Sprint by managers.

This led to making some hard, but necessary, decisions: to mandate from requesting individuals and business groups that tried to put their priorities on top of and around Product Owner’s priorities, to stop doing so. It was discussed and agreed upon by the heads of Development and Business organizational structures that requests would go through the Product Owner.

Traditional Management Communication Pathways

As mentioned above, the hierarchy of VBB was such that it led to command and control behaviours between reporting layers. Any action that, rightly or wrongly, deviated from the path dictated by management lines, or challenged existing norms and order, was often seen as risky and was discouraged.

Most attempts to put to light underlying problems and impediments went in vain. This was indicative of an endemic problem, as historically, the company actively resisted changes.

The coaches faced the dilemma: “how to help senior management admit that problems exist and require attention, and then make everyone else comfortable to step up, speak up and engage?”

To overcome this barrier, a compromise solution was proposed. It provided at least a safety-net for some more courageous individuals, who would otherwise have had only the option of escalating through the hierarchy and putting themselves at risk, to get their observations and concerns brought to light and to senior management.

As an experiment, the coaches have conducted a few sessions with senior management, educating them on the benefits of gemba/go-see. Specifically, managers were informed (based on the LeSS Guide “Go See”) that the purpose of go-see was not to micromanage, give orders or attempt to solve problems for teams. Rather, the purpose of go-see was to learn/understand teams’ problems and teach them how to solve problems independently of managerial control.

The management was encouraged to start coming down to teams’ area, and talk to individuals in their work area/seats, and ask questions about concerns, solicit feedback. Management was guided specifically not to push back problems back onto teams and not to try to solve problems for teams. Instead, the management was guided to teach teams how to solve problems independently.

The management also decided to resort to various discrete escalation techniques that would encourage individuals from lower organizational levels communicate directly to higher organizational levels. The “IRS” (Impediment Removal Service) was introduced, as a means of safer escalation of problems from teams and Scrum Masters to senior management. It came in the form of a dedicated internal email address alias that anyone could submit their personal challenge/problem in the form of a community discussion.

Manager Component Owners

The manager component owners were a source of initial resistance against forming cross-component feature teams. Why? For component owners, ownership meant personal visibility, power and control and, therefore, a better chance to be promoted and better compensated.

So the more senior managers needed to figure out a way to ensure that prior component owners were removed from the organization during LeSS adoption. How could this be done swiftly?

Component owners that still possessed strong technical skills were offered an opportunity to join teams and become hands-on contributors. They were also offered the role of component mentors whose responsibility would be to teach other developers.

The other component owners were moved to other parts of the organization.

In order for the above changes not to cause too much unest, senior managers conducted a round of discussions with all prior component owners and explained to them that going forward, their individual contribution and performance would be measured based less on owning, doing and telling others what to do and more on teaching/mentoring. People were given assurance that by educating their teammates, prior component owners would be neither reducing their own importance, nor putting their own jobs at risk. LeSS Guide: “Job Safety but not Role Safety” - was leveraged for this.

Management and Engineering Practices

LeSS Test - “Avoid… Test department - Avoid… Separate test automation team - Try… Zero tolerance on open defects - Try… Acceptance test-driven development - Avoid… Traditional requirement handoff”

Unfortunately, manual testing practices were long-established within VBB and this meant manual testers were distributed across newly formed teams. To remediate this weakness, test automation and sharing of good engineering practices was strongly encouraged across the teams. This advice was supported with training and coaching by one of the coaches (Stuart). The primary vehicle for this focus was via an Engineering Community (see the LeSS Guide: Communities) and targeted training was also provided when particular needs came up. Teams were encouraged to transition from the traditional process of “testing a release candidate” using manual testing to manual or automated testing of features as part of the Definition of Done.

Figure 4 shows the Definition of Ready/Done/Undone derived by all teams in one of the kickoff workshops. Unfortunately, notice the initial continued inclusion of manual testing in the DoD, even though some automated testing was introduced in the LeSS adoption.

Why? Unfortunately manual testing remained in two cases, both at the request of the teams:

1. The first was Integration Testing performed by the team in all environments
2. The second was User Acceptance Testing (UAT) performed by an external, separate group with their own cadence.

Both the teams and technology/business managers felt it was important to continue this practice until trust was built in an automated toolset. As mentioned in the above Definition of Done picture, manual integration testing continued across a minimum of two testing environments for any deployment including DEV, UAT and Production. For example, this included a deployment to DEV environments at the end of each Sprint. Deployment to UAT would then occur as Undone work that carried over to the subsequent Sprint. This resulted in significant ongoing wastes. Interruptions to the teams existed because of slow feedback and a plethora of release related sign-off meetings that made it very difficult to facilitate positive change across the board fast. For example, teams would typically wait weeks for UAT sign-off after a feature was accepted by the Product Owner. Any feedback from the UAT team that required code changes would manifest as urgent interruptions to the development team. After passing UAT, releases into Production would require coordination and more manual testing across each application and was only allowed to occur in restricted time-windows. Of course, this led to the continuation of massive wastes.

LeSS Design and Architecture - “Avoid… System engineers and architects outside of regular feature teams - Try… Technical leaders teach at workshops - Try… Hire and strive to retain master-programmer ‘architects’ - Avoid… Architecture astronauts (PowerPoint architects)”

Another dysfunction in VBB was the existence of separate architecture groups (with managers that wanted to maintain their status quo positions) at multiple levels, both within Development and firmwide.

There were frequent interference attempts from the firmwide architecture groups that had the potential to be very disruptive. One minor benefit of the unfortunate continued existence of the local Development architecture group was to at least absorb this interference so that it didn’t cascade into the new teams.

Still the Development architecture group did not dissolve and so there were continuing wastes from the presence of this single-function group that made documents and dictates, not code.

In addition to architecture groups, technical managers also wanted to dictate architectural decisions, since their traditional positions were based on these kinds of actions. A Development manager introduced (without consultation with the teams) a weekly “Design meeting”. This had the effect of severely hampering in-flight and future work, and was a source of conflict for the developers across all teams. Because it was imposed by a middle manager, this was difficult to abolish. It took a number of Sprints until the problem was recognized by senior management (Scrum Masters escalated this problem and qualified it as an organizational impediment) and this low-level centralized decision-making attempt was abolished.

HR Policies

During the faux “Scrum” adoption, each team member was still officially a single specialist. There was almost no interest in learning new functional domains or technologies, as everyone’s job title was ‘business analyst’, ‘tester’, ‘front-end developer’, ‘manager’, ‘architect’, etc. Lack of motivation by people to learn additional functional and technical skills was driven by the process of individual goal-setting and performance reviews, by line managers. Everyone’s end-of-year performance and discretionary incentives (bonuses, promotions) were based on an individual’s ability to prove that they delivered as per their original job descriptions (and did better than their peers/colleagues). For example, business analysts were measured based on how efficiently they were able to ‘write stories’, testers were measured on how many bugs they were able to discover, and so forth. This also led to local optimization by each single function and subsequently, to sub-optimization of the overall organizational system.

Because of that, everyone was risk-averse and not willing to experiment with anything new or innovative , as it would make them being perceived as ‘less efficient’. This was a class manifestation of Law # 5 of Larman’s Laws of Organizational behaviour (“Culture follows Structure”), in which one can’t realistically expect people to behave in a way that is very contrary to the organizational system, especially when it involves salary and career promotion.

The partial success that the coaches were able to achieve was to persuade management to promote behaviors they were wishing to see: knowledge sharing, stepping out of a usual comfort zone and learning, shared ownership, swarming, etc.

A few years after the coaches disengaged, their prior effort to improve job roles finally paid off: A more general “developer” role with broad skills was introduced, and the job title of Scrum Master was added VBB-wide. This is a classic example that a coaching impact may have a delayed effect.

Culture is Influenced by Organizational Design

One of the most challenging aspects of organizational culture that the coaches had to face was the amount of emphasis that was put on individual performance. There was a deep systemic problem that had to be addressed, organization-wide.

Historically, VBB, had a culture that encouraged super-heroics and internal competition. People were primarily driven by extrinsic motivation and a desire to outperform their colleagues, competing for bonuses, promotions, and other perks. Individual performance appraisals and end-of-year reviews defined individuals’ behaviours and often led to system gaming, especially at year-end. This culture of heroics and internal competition was strongly influenced by the organizational design.

Such culture was not conducive to ways of working expected of teams in LeSS.

As an example, the below causal loop diagram (Figure 5) uncovers underlying system dynamics that involved individual performance evaluation process, and how it adversely impacted basic Scrum dynamics within the Development group (reminder: a faux “Scrum” had been already introduced before the coaches joined).

To alleviate this problem within the LeSS product group, the coaches decided to leverage the following LeSS experiment: “Avoid… Incentives linked to performance”, and “Try… De-emphasize incentives.” The goal was not to change norms and standards globally for the whole enterprise. Rather, the goal was to educate influential management to act locally by taking actions that would lead to changing individuals’ attitudes and behaviour, to make individuals more respectful of collective ownership and willing to cultivate “us- together” mentality. More about this effort below.

LeSS Experiments: Try… De-emphasize incentives - Avoid… Putting incentives on productivity measures - Try… Team incentives instead of individual incentives - Try… Team-based targets without rewards - Avoid… Performance appraisals

The Development management involved in the process of appraisals and rewards was educated on the harmful impact of these. How? A few workshops were conducted for managers and HR representatives to discuss:

• Research and studies of how individual performance appraisals and their linkage to monetary incentives can cause harm to employees and organizations (summarized, as case 1 and case 2)
• Systemic cause and effect relationships between individual performance appraisals/bonuses and health of Scrum dynamics. Above (Figure 5) is an example of a causal loop diagram that was produced during one of the discussions with managers to visualize the problem and educate people towards better behaviours.

The scope of these changes were of course local to Development. The LeSS adoption within Development was an experiment of organizational restructuring inside a bank, that — as in all banks that we have coached within — has deeply rooted traditional, hierarchical, top-down command & control culture aimed at shifting large cash bonuses to bank managers. So were not under a fantasy that these changes could be extended beyond our boundaries, and just sought to ring fence them locally.

One example of a locally controlled norm was emphasis on team-level ownership, responsibility and performance, rather than individual-level. Although the bank-wide process of individual performance appraisal still existed, Development management informally trivialized its importance. Valuing (and praising) team performance over individual performance became more of the norm. Eliminating the dysfunction-generating policy of appraisals and bonuses was not possible, but with the support of management what was possible was to reduce the harm and shift the emphasis.. This illustrated the LeSS experiment “Try… Reduce harm of policies that cannot yet be removed”

So within the organizational constraints the management tried to create an environment conducive to improved behaviour by developers. The following was made clear and continually stressed during Development events and regular communication:

• Importance of becoming T-shaped workers
• Benefits of learning new development tools and techniques
• Behaving towards other teammates in supportive, team-like fashion, as well as valuing team performance over individual performance.

Above all, a strong emphasis was made on customer happiness with the overall LeSS delivery being the most influential factor that identified financial rewarding of teams, and subsequently, individuals.

Although at the end of the year each Development employee was still given a year-end review and “report card”, it had much less bearing on how an employee was rewarded financially. Individual adherence and genuine support of agile transformation efforts and LeSS adoption were valued more than individual delivery and heroics. Letter-grading was still assigned informally by managers (it was entered in a centralized system of record, as it was required by HR) but everyone understood and spoke freely about the fact that it had practically no value to anyone. This illustrated the LeSS experiment Try… Fill in the forms, meaning that when it isn’t possible to eliminate wasteful HR processes, then just play the game by inputting the essentially meaningless information with the least effort, and focus instead on the important real work of improving how to delight the customer.

Conclusion

The LeSS adoption had some positive impacts:

• Users were pleased with frequent delivery of useful features. They could forecast better.. Also, the level of transparency and predictability brought by the LeSS adoption has grown much higher. Relationships between technology and business were at their best during the LeSS adoption .
• On both sides, Development and Business people learned how to identify organizational impediments and relate superficial discoveries to deeper, systemic root causes, that affected a broader system. We believe this learning will stay with people for a long time.
• The communities helped individual and group learning.
• Modern engineering practices grew deeper roots into Development and beyond, positively affecting the broader technology group.
• A handful of seasoned Scrum Masters was nurtured and some of them became so passionate about becoming change agents that they have decided to make this into a career journey.

The following challenges remained unresolved at the time both coaches departed:

• Component/application ownership did not completely transform into mentorship. There was still hidden resistance by former application owners to give up control and become mentors.
• People that were displaced because their original roles became no longer required in LeSS (e.g. business analysts, project managers, and manual testers) were not effectively accommodated by other parts of VBB. Effective cross-training to acquire additional skills (and hence work as an effective flexible team member) was not offered either. Therefore, displaced people continued to put up hidden resistance to the LeSS adoption.
• Self-management remained a challenge. For example, individuals were still required to “work with their managers” on individual career plans, even in situations when managers had little influence on decisions.
• Performance reviews and subjective bonuses continued to affect individuals’ morale, even though their importance was trivialized: complete decoupling of performance reviews from subjective monetary incentives did not happen