Coach’s Experience Report: Putting LeSS Teachings to Work

 

The following Coach’s Experience Report describes various teachings of Large Scale Scrum (LeSS) framework in the context of their practical use by Agile Coach. What is below does not represent a single case with a single organization or company. Rather, experiences with multiple organizations, under different conditions are being described. By the same reasoning, not for every organization, whose experience is being drawn upon in this report, all of LeSS teachings that are described below, have been experimented.

---

Coach’s Discovery: Scrum teams have been struggling to gain autonomy and independence due to close monitoring and constant involvement of line management. Teams’ decisions, made during sprint planning were continuously overruled by management. Mandatory requests coming from management were frequently in conflict with priorities coming from Product Owners. Teams – were unable to conduct sprint retrospectives privately and safely, with management insisting on its presence in ceremonies and/or reviewing retrospectives’ outcome.

LeSS Teaching by Coach: Tylorian Carrots & Sticks used to be effective during American Industrial Revolution, when they were applied towards people that performed mundane, unskilled, manual labor. But in modern work settings of the 21^st century (for the most part) don’t work, if applied toward intellectual workers. Command & Control behaviors suppress individuals’ willingness to explore and innovate, discover and experiment; they demotivate and demoralize workers, and therefore lower productivity.

Senior management needs to order fist-level line management to step back and allow teams norm and gain autonomy and independence. Close oversight and supervision will not allow teams to fully explore their potentials and achieve higher productivity.

Overall Result: Positive. Many teams have been liberated from Management Type X and have been treated with Management Type Y, instead.

---

Coach’s Discovery: Team members were expected to work closely together, share knowledge, help each other grow complimentary expertize. Teams were also asked to deliver together, “as a whole”, at the end of each sprint, and demonstrate shared ownership and swarming during sprints.   Team members were expected to take turns in a driver’s seat during showcases, to equally gain visibility in the eyes of Product Owners and customers.

But at the same time, each team member was being stack-ranked, during an individual performance appraisal, against his/her own team members, as well as against members of other, neighboring teams. Each ranked individual understood that he/she competed with other team mates for discretionary money that would have to come in the form of a bonus at the end of year. As it came closer to mid-year reviews and end-year reviews, teams dynamics worsened and bad behaviors were observed, practically, inside every team: less collaboration, emphasis on private ownership and individual deliverables, selfishness, blame-gaming and finger-pointing. As a result, teams’ velocities dropped, quality went down, and customer satisfaction was lowered.

LeSS Teaching by Coach: “The idea of a merit rating is alluring (as per S. Deming)”. Individual performance appraisals, linked to monetary incentives lead to demotivation, loss of enthusiasm and bad behaviors, such as internal competition, rivalry, selfishness and organizational degradation. Having individual performance appraisals, linked to distribution of discretionary monetary incentives, such as bonuses and salary increases, worsen a situation even further.

Overall Result: Mostly Negative. Line management did not except the fact that merit rating and individual appraisals had such harmful downstream effect on teams’ dynamics and cause organizational degradation. Senior management seemed to understand that the problem existed and was serious, but was still too hesitant to ‘rock the boat’, as many fundamental organizational norms and policies, many of which set by HR, would be challenged. In rare situations, however, management was able to emphasize team performance and collective results as main attributes of individual performance/results.

---

Coach’s Discovery: Recently trained teams fell under close surveillance and scrutiny by line management. Line management viewed agile/scrum, as a magic wand that would miraculously resolve all their existing problems. Management started paying too much attention to metrics (e.g. Velocity) and set unreasonable expectations for teams’ productivity during initial sprints. When teams initially failed, management blamed agile/scrum for failures, instead of treating it as a “mirror” that just painfully reflected existing broken processes.

 

LeSS Teaching by Coach: In Scrum, when a team just gets trained and is set sail, Private Sprints with “Fake” Product Owners (if a real one is identified yet) are recommended. Why? A team may want to practice/dry run scrum dynamics (roles, artifacts, ceremonies, feedback loops) but may not necessarily want this information be publicly disseminated across an organization, to avoid premature judgments and “mis-measurements of success”. A team is not obligated to announce to the rest of the world that they are experimenting new ways of working UNTIL everyone who is involved is ready and comfortable.

Overall Result: Positive. Teams no longer viewed the last day of scrum training as a commitment point, at which they had to announce to the rest of the organization that “they were agile now”. Teams became more comfortable to transition into new dynamics, and did it gradually, while “playing it safe”, before publicizing their intentions or results. In cases, when a real Product Owner was not immediately available, teams used another surrogate to play this role (e.g. Senior BA or SME).

---

Coach’s Discovery: A team was experiencing a lot of distraction, coming from stakeholders and customers. Instead of going to Product Owner with requests, customers went directly to the team. Frequently, competing priorities arose: a solution that addressed one request conflicted with a solution that addressed another request. Product Owner, took advantage of his overly proactive clients, stepped back and did not do his job.

LeSS Teaching by Coach: When it comes to feature (scrum) team communication, there are three main types exist:

• Requests: From Customers/Users and Product Owner
• Prioritization: From Product Owner to Team
• Clarification: Between Customers/Users and Team (also can come from PO)

Effectively, this allows for business requests to flow from various areas/departments of an organization to Product Owner but then to be prioritized and fed to a team/backlog by Product Owner himself, in a controlled fashion. While a team is shielded from Customers’/Users’ ad hoc requests, sometimes competing, it still has a right to go to Customers/Users for clarifications.

Overall Result: Positive. The Team learned how to say ‘NO’ to customers and defer their requests to stakeholders. Product Owner was ‘forced’ to step up to the plate and practicing one of his key responsibilities – being voice of a customer, facing a team.

---

Coach’s Discovery: An organization had wide geographic distribution, with technology resources present in India, Eastern Europe and South America. The long-standing goal of outsourcing was to find the cheapest resources for a single specialty. For example, front-end Java developers were all sourced from India, Flash and UI experts – from Eastern Europe, architects – from Argentina. This has caused a lot broken communication and unnecessary coordination between feature team members: language barriers, geo- time-zone distribution, etc.  Also, end-customers were from the US, and this further added to complexity. Inefficiency of highly distributed teams, trying to coordinate ceremonies and optimize time overlap, was painfully noticeable.

LeSS Teaching: Given today’s global market place, geographical distribution of skilled workers is practically inevitable, for most companies. However, when it comes to teaming it is critical to avoid geographical distribution within a single team. Companies should support collocation of members of the same cross-functional team (note: even with the latter approach, doing this with componentized teams presents other problems). Also, bringing business (stakeholders, SMEs, Product Owners) closer to teams, is highly desirable.

Overall Result: Partially Positive. The leadership agreed to reconsider the current geographic collocation strategy. Having a group of single specialty experts located in one place, communicating across many time zones, with another group of single specialty experts, became a less preferred option. The leadership started to see more value in collocating individuals, based on their needs to work together, on same features. At first, it became more expensive, to procure certain expertise, where it was not as abundant and its cost was higher (e.g. Flash developer in India), but over time, increased efficiency and higher rate of business value output by each team made changes worthwhile.

---

Coach’s Discovery: During initial stages of agile transformation, senior leadership came to realization that by restructuring their organization to improve overall organizational performance, some internal “waste management” activities had to be done. Specifically, it became clear that certain processes, artifacts and roles were redundant, unnecessary and costly. As such they had to be reduced or removed from the system, altogether. This raised a particular concern for senior management, as removing certain elements of organizational structure could become too politically inflaming. For example, an excessive amount of business analysts and project managers (PMO) represented two pretty thick organizational layers that were primarily focused on producing heavy documentation and less- than-reliable reporting, respectively. Reducing these two layers would effectively mean downsizing certain individuals – something that could loudly resonate across the rest of the organization.

LeSS Teaching: Organizational Leadership needs to understand the difference between Local Optimization (e.g. improving performance of a single organizational layer, functional silo, reporting structure) and System Optimization (e.g. improving performance of an entire system). Looking at an organization from a stand point of System Optimization, an organization should care to provide Job Security to its employees, not Role Security. Ultimately, the goal of any organization is to continuously strive towards improving its efficiency, not providing safe haven for roles that make it [organization] less efficient.

Further, from System Optimization perspective, it is wiser to support the idea of not having individuals that are all just Specialists in a particular field or domain; an organization needs to have a good amount of Generalists to avoid workflow management dysfunctions and workflow bottlenecks. Presence of T-shaped individuals are highly desirable.

Overall Result: Positive but WIP. While removing organizational waste, senior leadership tried to strike a happy balance between simplifying organizational structure and removing redundant/unnecessary roles on one end, while trying to provide job security and alternative career paths for some knowledgeable and highly qualified individuals.

---

Coach’s Discovery: After more than a dozen of sprints, a group of feature teams still could not show any progress in their ability to deliver potentially working software at sprint-end.   At the end of each sprint, teams still produced code that needed additional testing, test automation activities, integration with code of other teams, extensive UAT, and other “Udone” activities. The initially proposed Definition of Done (DoD), at the time when teams got trained, did not change much and before releasing to production, teams still required at least one ‘hardening’ sprint.

LeSS Teaching: As a feature team matures, gradually, it should extend it definition of “Done”, to bring itself closer to a point, where, upon finishing a sprint, it makes its deliverable production-ready.

Overall Result: Partial Success. The teams was encouraged to identify during retrospectives at least one or two elements of DoD that were either missing or needed an improvement. Based on this, the teams were able to gain some momentum and with every subsequent sprint improved production readiness of their code.   However, there were certain organizational impediments that still prevented teams from delivering faster: certain external dependencies on organizational layers that were “outside of agile sphere of influence” – they prevented DoD to become fully inclusive.

---

Coach’s Discovery: Individuals that have been elected (or appointed) to the role of Product Owner, did not have time to do the job. They were either too senior within an organization “to deal with IT directly” or had already too much on their plate to take on, yet another full time role of Product Owner. This created a serious gap that made scrum extremely ineffective and overall agility low. To fill this gap, Product Owners found other people, other person within their own reporting structure to fulfill this role. They delegated most of PO responsibilities to this new, artificially created role of Product Owner “proxy”.   This brought about a lot of dysfunction and hindrance to the process as “proxy” did not have the same level of empowerment as a real PO.

In some situations, existing terminology that had a completely different purpose and meaning was overloaded. For example, Area Product Owner (LeSS term) was used to describe a role that did not fit the definition of Area PO. Effectively, Area PO term was used to describe the role and behavior of PO “proxy”.

LeSS Teaching: A business person that represents a single area of a complex product is called Area Product Owner. Area PO is in close communication with other Area POs, responsible for other areas of the same product, as well as with Product Owner (main person) that oversees an entire product. Area Product Owner is not to be confused with an ill-defined role of Product Owner Proxy. The latter term is not really defined in Scrum. This term exists in places, where a real PO is not able or not willing to do his job (no time, not enough interest/motivation). PO-proxy, is PO’s surrogate that interfaces with team(s) to mimic PO (minus authority) – it is an unnecessary organizational layer.

Overall Result: Situational Success. In situations, where organizational structure (on business side) was relatively flat, the success of identifying an effective Product Owner and bringing him closer to teams was much higher.   In situations, where business organizational structure was more complex, with multiple reporting layers, the success of identifying Product Owner that would be equally knowledgeable, empowered and engaged were lower. Another consistent observation was that every time Product Owner came from middle organizational tier (e.g. Operations, a.k.a. not true end-customer) chances were higher that the role of “proxy” would emerge.

---

Coach’s Discovery: This was a large organization, with complex structure, heavy tooling and internal processes that was looking for scaled agile solutions to accommodate its “internet historic complexity”. The organization was looking for agile frameworks that would seamlessly fit its existing dynamics, while not requiring too many changes. The organization was not really trying to improve existing dysfunctions and repair problems. Instead, the organization was trying to look for ways to “improve” its existing condition by overlaying agile norms, terms and principles on the top of its current system. This included introducing more agile roles, ceremonies, processes, organizational layers, handovers and bureaucracy on the top of what existed already. Over time, it worsened the situation even further, not improved it.

LeSS Teaching: In order to improve organizational agility and be able to implement agile at scale (e.g. have more teams being involved in the same large scale Scrum, as opposed to having many unrelated teams attempting to do their own scrum), organizational De-Scaling is required first. This includes: removing organizational waste, lowering bureaucracy, flattening organizational structure, removing non-value adding roles, reassigning responsibilities to key roles, discontinuing norms and behaviors that have been statistically proved as harmful.

Overall Result: Partial Success. The organization understood principles of LeSS, especially, it core Lean Thinking. The organization understood that organization descaling (removing what exists, instead of adding more to it) should come before any attempts to scale agility across broader organizational boundaries. However…the organization was still not fully prepared to deal with all consequences of waste removal. There were concerns with political and legal implications of such bold actions.

---

To Be Continued:

TBD – more Coach’s Discoveries and respective LeSS Teachings that were used to remedy problems:

• LeSS Teaching: The following elements and attributes lead to “The Contract Game”: componentized organizational structure, heavy/non-negotiable documentation, bureaucracy, functional silos, lack of cross-functional experts (T-shaped people), merit ratings/performance appraisals/bonuses or other forms of local optimization (e.g. harboring teams of BAs, PMs)
• LeSS Teaching: Lack of proper understanding of cross-functional, customer-centric feature development, leads to creating fake “products” or “projects” (e.g. server-side work, back-end coding, database, UI). This further leads to creating fake project portfolios and fake project portfolios. This further creates needs for excessive coordination that mandates unnecessary roles of fake portfolio managers and alike.
• LeSS Teaching: By analyzing system’s Feedback Loops: Velocity, Bugs, # of Developers, Budget Supply – it becomes clear that, for example, the increase in funding (budget) does not necessarily translate into increased velocity or improved product quality. Negative Feedback Loops are just as important to consider as Positive Feedback Loops: more money may help hire more developers that will produce more bugs.