“Scaling is our main goal”
The whole idea of “since we are so large, all of our solutions must be also large” is flawed.
Just because an organization is large, does not mean that it is usefully and productively large. It could be that historically, or due some other conditions, an organization has built up a lot of internal waste that led to a costly dysfunction that is not visible. If we apply a large scaling solution on top of an existing large dysfunction, we shall only further amplify a dysfunction. Therefore, before jumping into scaling (one of the three most shiny objects), consider de-scaling (simplifying) your organization first.
So, instead of immediately assuming that an organization’s size is “un-touchable”, it would be wise to re-think if its organization really needs to be as large as it has been.
Getting drafted into “productization” saga (relabeling)
“Our company needs to become a product company. Let’s turn every body of work that we do into a product“. Although, not quite in the same words, in essence, this is what we hear/see at companies doing, as a part of looking for shorts cut when defining their products:
- Shared Services Component –> Shared Services “Product”
- Platform Component –> Platform “Product”
- Micro-service Component –> Micro-service “Product”
- DLL Library Component –> DLL Library “Product”
- API Component –> API “Product”
- Middleware Component –> Middleware “Product”
- Front-End Component –> Front-End “Product”
- Back-End Component –> Back-End “Product”
- DB Component –> DB “Product”
- Framework Component –> Framework “Product”
- Platform Component –> Platform “Product”
- Micro-service Component –> Micro-service “Product”
- DLL Library Component –> DLL Library “Product”
- API Component –> API “Product”
- Middleware Component –> Middleware “Product”
- Front-End Component –> Front-End “Product”
- Back-End Component –> Back-End “Product”
- DB “Product” –> DB “Product”
- Framework “Product” –> Framework “Product”
To a large extent, this is caused by historical resistance of middle managers and technical component owners that push back on dismantling of component/application teams, because the view it as a challenge to personal control and organizational influence. It is a always a good idea to think of a product definition from the stand-point of a paying customer (or internal user), not from the stand-point of technology areas (and how they are controlled).
Assigning team members, based on traditional staffing models
For a successful LeSS adoption, it is important to attract highly skilled, cross-functional, full-stack product developers that are available, from the very start (hiring junior developer is OK, but they should be gifted and talented, as well as well vetted, prior to on-boarding). This may require initiating a rigorous search for the best talent available internally or recruiting best talent from outside. With the ladder decision, you may have to go above and beyond a standard rate card limit, to make the job attractive (your internal standards and HR guidelines may become an impediment – beware!).
One of the classic miscalculations/illusions that are observed with staffing is that developers are compensated and promoted for actions/behaviors that are not consistent with what is expected of them, once the are put on cross-functional teams. For example, hiring a front-end developer and managing his/her individual performance (and compensation) solely based on individual contribution as a UI designer, is not supportive of the idea that a front-end developer is also expected to learn back-end technology and/or teach other team members how to develop a front-end piece of code.
Further, such concepts as ‘shared resources’, ‘developers-loaners’, etc. should not exist in LeSS. Each product developer in a LeSS product group, is a dedicated team member (and therefore, a LeSS product group member). For example, staffing a team of six people, with only one developer and keeping “supportive roles“, such as business analysts, manual testers, project managers, non-developing architects, may create an illusion of a fully staffed team that has a high output. In reality, we are dealing with a single-threaded ‘assembly line’, with lots of hand-offs and a low (one developer) capacity server at the tail-end of it.
Assuming that LeSS product group design fits traditional organizational design
LeSS is not a methodology, “operating model” or a framework that can be easily unpacked and installed on the existing organizational design. It is an organizational design on its own: lean, flat, product-centric organizational structure that is optimized for effective product development and customer centricity. It is built organically, bottom-up. Therefore, we should not be expecting that existing organizational elements, such as roles, reporting lines and power structures, etc., will seamlessly map LeSS elements. LeSS is a de-scaling framework that de-scales (flattens/simplifies) an organization, in ways that requires fewer people with more responsibilities, as opposite to too many people with few responsibilities, per person (and lots of hand-offs).
Keeping HR norms and policies unchanged
It is important to understand that job definitions, career paths, compensation and incentives of product developers in a LeSS product development organization are not the same as in a traditional organization. For example, there should be more emphasis on full-stack skills than on single-function specialty skills, team performance than to individual performance, compensation/promotion that is based on hands-on contribution than becoming a manager aspirations.
Today, too many organizations, are still governed by HR norms and policies developed more than a century ago, based on Taylorian/Theory X management norms. We do not see enough meaningful job requisitions and well defined career paths for product developers and other roles that are important for adoptive organizations. For the most part, what we see is role relabeling phase. Perhaps, soon, GenAI will strongly mandate cheese changes.
Delegating the role of PO to low-ranking PMs (a.k.a. “left over” people)
Therefore, a person who is asked to step into the role of a PO must be properly positioned organizationally, in a way that enables him/her to own a strategy, mission, vision and budget decisions. Effectively, a PO is a highly visible, empowered and influential figure in LeSS. When the role of a PO is delegated to a BA, PM, or another ‘left over’ traditional role, its essence gets diluted and it leads to a lack of empowerment and inability to guide on strategic decisions. Subsequently, this makes the person into an order taker and ‘jira ticket holder-pusher’. It is worth noting that if a real PO gets drafted in meaningless (mechanical, administrative) activities, he/she will very quickly lose interest in playing the role and will look for ways to delegate responsibilities to one of the aforementioned, usually subordinate, ‘left over’ people. (at times, ironically referred to as ‘proxies’).
Assigning a fake PO (“TOO”) to each team
This frequently observed dysfunction is related to the “proxy PO” problem described above, and seen in environments, where:
- The role of a real PO is not well understood
- PO is not available to teams and/or when users and customers are not readily available to teams
- Teams are still structured around components (applications), not around product features
- Teams (developers) are reluctant to learn business domain or develop relationships with users
- There are too many ‘left over’ people (business analysts, QA, project managers) within an organization who, and instead of being retrained and meaningfully used, they are re-purposed into locally optimized roles, redundant layers that further create artificial barriers to simplicity (desirable) of communication between developers and users.
This problem is very well described in “Why “Scrum” Isn’t Making Your Organization Agile: Harmful Misconceptions About Product Owner Role”, by M. James.
Maintaining implicit, team-specific backlogs, within a product backlog
As a horse and carriage, this problem usually comes along with the problems of multiple ‘team-level POs’ and fake productization (both are described above).
In essence, team-specific backlogs are either lists of narrowly focused product features (at best) or technical components (at worst). In the former case, we are dealing with feature teams that are over-specialized in a narrow business domain and therefore, miss out on the whole product focus. In the ladder case, we are dealing with technical component/delivery teams, whose focus is even more narrow: technology, application, API, microservice, platform, etc.
In both instances, team-specific backlogs represent ‘locally’ prioritized (optimized) sub-lists that do not represent real priorities of a product owner. Work that is completed by teams, based on such sub-lists creates an impression of high (voluminous) output that does not directly translate into outcome.
“Are We There Yet”? – rushing a LeSS adoption to meet year-end goals
In organizations that are strongly driven by numbers and year-end goals, is it not uncommon to see maturity metrics/maturity levels, as means of rushing initiatives to completion.
“Are we agile yet?“, “have we reached agile maturity level XYZ?” – we often hear these types of questions, asked by senior executives of their agile transformation offices and agile centers of excellence.
We see the same problem with LeSS adoptions and the classic sign of watering-down the essence of LeSS, is minimizing everything to low-level mechanics, such as scheduling LeSS events for teams and day-to-day interactions. At the same time, the following critical elements of a LeSS adoption are trivialized or completely overlooked:
- Educating executives
- Improving HR norms and policies(careers, compensation, promotion)
- (Re)defining products
- Rethinking budgeting (from projects and programs to products)
- Reducing mid-layer management
- Allowing teams to self-design and self-manage
LeSS and LeSS Huge adoptions are deep and narrow organizational improvements that take years, tons of work and effort, and a lot of patience and sense of humor. LeSS and LeSS Huge adoptions are not broad and shallow, fast-fast-against-the-clock superficial make-overs that are done to but a “done” check-mark in someone’s individual performance journal.
Lack of LeSS coaching guidance and organizational consulting quality
A successful LeSS adoption requires certain organizational design improvements that can be only initiated from the top.
It is not a secret that senior executives and top management – people that are in charge of key decisions (e.g. HR norms and policies, budgeting, site strategies) are reluctant to receive guidance from organizational structures that are subordinate to them (e.g. agile transformation offices and agile centers of excellence). Executives tend delegating their responsibilities, not taking them, while minimizing their own learning to a minimum.
This is where experienced organizational design consultants – independent professionals that are not institutionalized (do not belong to the same organizational structure), can become very instrumental. They come with rich industry experience, having seen successes and failures at other organizations, and do not feel pressured into delivering sugar-coated messages to leaders.
A great organizational consultant comes with a gamut of coaching and training skills that have been polished over years of client work (illustration on left), not by fast-tracking his/her career to another “agile promotion”.
An experienced and self-confident consultant is usually immune to internal politics and power struggles and therefore, can challenge organizational dysfunctions more effectively than a person, who is a part of the same organization.