HR-Related LeSS Experiments – Deciphered

Large Scale Scrum has a history of more than a decade. The first book about LeSS was published by C. Larman and B. Vodde (the co-creators of LeSS) in 2008.  There were two more books on LeSS, subsequently written in 2010 and 2016.  There is no surprise, why the collection of LeSS experiments from the field is so valuable: the authors have documented many (more than 600) experiments, based on their personal experience with LeSS adoptions, as well as feedback and information collected from other organizational design consultants, coaches and early adopters of LeSS, around the globe.

Today, references to LeSS Guides and Experiments can be found in various places on the internet and intranet of many companies that have decided to experiment with LeSS.

This writing is about a small sub-set of LeSS experiments that are specifically related to HR norms, policies and practices. They are all listed in the guide (referenced above), under the section “Organization” and this implies that they are directly related to an organizational design – the first-order factor in success of LeSS adoptions and agile transformations, at scale.

“Avoid… Performance appraisals – p. 273” — There is a lot of research and evidence, supporting that individual performance evaluations and individual appraisals that are linked to monetary rewards, are not an effective way to make individuals become more efficient and productive.  When a manager appraises an employee, there is usually only one opinion that matters: a manager’s.  Feedback that is delivered once or twice a year is outdated and therefore is hardly actionable by an employee, thus for the most part is useless.  Neither an individual that delivers an appraisal, not an individual that receives it – like the process.  The process, is also pretty expensive, as it uses a lot of company’s resources: it involves lots of documentation, coordination and men-hours spent by many people, from first-line management to HR.

It is worth noting that there is an indirect relationship between conventional Budgeting process and conventional Performance Management process – both of which harmfully feeding off of one another. This is described in the book “Implementing beyond Budgeting: Unlocking the Performance Potential“, by Bjarte Bogsnes.  In his work, Bjarte refers to performance appraisals as “legal trail for a rainy day”.

“Avoid… ScrumMasters do performance appraisals – p. 275” —Just like performance appraisals done by agile coaches could lead to serious dysfunctions (page. 130), performance appraisals done by ScrumMasters are also harmful.  Drafting ScrumMaster into the role of an appraiser may create a serious conflict of interest and will hinder ScrumMaster’s ability to influence natural growth and evolution of learning among team members. Impartiality and neutrality of ScrumMaster is highly important; becoming an appraiser – takes away this advantage.  Only by remaining neutral and non-authoritative (performance appraisal is exhibition of authority) will ScrumMaster be able to help a team to self-discover, self-improve, and become autonomous in their journey to success.

“Try… De-emphasize incentives – p270.” | “Avoid… Putting incentives on productivity measures – p. 271.” — If achieving a higher productivity (output, velocity) is coupled with monetary incentives/perks or other political gains (typical of many companies that overuse scorecards, metrics, KPIs, RAGs), there is will be always attempts by individuals/teams to claim successes/achievements by ‘playing the system’, in pursuit of recognition and a prize.  For example, in pursuit of ‘higher productivity’ teams may start inflating estimates, to claim higher velocity or deliver work that is low in priority but simple to deliver – just to create an illusion delivering value (output != outcome). Incentivizing ‘higher velocity’ is an invitation to moving from “low Fibonacci numbers to high Fibonacci numbers” during estimation.  (Also, see Addressing Problems, Caused by AMMS)

“Try… Team incentives instead of individual incentives – p. 272” — The process of individual performance reviews loses its original meaning when people work on a same team, where swarming (working together on the same task) and collective ownership is encouraged.  Offering individual incentives to people would just polarize them and move in opposite directions, towards becoming self-centered, individual performers and super-heroes. In cases such as these, people may be easily drafted into unhealthy competition with each other over claims of success, trying to privatize what should be owned and worked on collectively. Companies that continue incentivizing individual performance with monetary perks, just continue widening the gap between “what science knows and business does” (quote from Daniel Pink).

“Try… Team-based targets without rewards – p. 273” — Clearly, team-level behavior, is an extension of an individual’s behavior.  Just like individuals could be inclined to ‘game a system’, so could entire teams, if they are put under bad conditions.  Just like individuals, whole teams might be drafted in unethical conspiracies to game numbers, in pursuit of meeting targets, or beating other teams (e.g. producing ‘higher velocity’), whenever monetary rewards are offered.  If it is mandatory to set targets for individual teams that work on par with one another, for the same organization, it would be best to decouple team targets from team rewards.  The latter could be handled through, some sort of profit sharing formula, based on a company’s financial success, achieved because of great team work.

“Avoid… Job titles – p. 276 | Try… Create only one job title.  Try… Let people make their own titles – p. 277 | encourage funny titles” – p. 277 —In pursuit of job titles, individuals may also seek gaining authority and an “upper hand” over their peers and colleagues.  This may lead to artificial organizational complexity and hierarchy, as well as a casting system.  Individual job titles can also polarize people and drive them in opposite directions, away from shared ownership.  It is for this reason that on agile teams (e.g. Scrum), there is only one title – Developer.  This approach encourages people to think of each other as an equal colleague and be willing to grow into T-shaped, multi-skilled, cross-functional, willing-to-swarm workers.  In situations, where some distinction between individual jobs is absolutely necessary, funny job titles are recommended.  For example, instead of calling someone QA Tester, a person could be called “Bug Finder and Exterminator”

“Try… (if all else fails) Generic title with levels – p. 277” — If it is necessary to have title distinction (e.g. to signify different levels of seniority/expertise of individuals), try using a leveling system.  For example, Developer level 1(junior), Developer level 2 (mid-level), Developer level 3 (senior).

“Try… Simple general job descriptions – p. 278” – Do not over-complicate job descriptions.   Precision in a description may lead to contractual perception of what a person should and should not do, in a workplace.  This may also limit a person’s willingness to step out of his comfort zone and learn other areas of work, other skills and becoming multi-faceted.  It may then further lead to “managing by objectives” that are based on detailed job descriptions, and subsequently, bring about problems of performance appraisals, described above.  Complex job descriptions also have a tendency attracting under-qualified external candidates, whose resumes are excessively long, as they are ‘tailored to closely match complex job descriptions’.  (Relevantly, attracting bad agile coaches, by creating inappropriate job descriptions is a known problem).

“Try… Job rotation – p. 279 | Try… Start people with job rotation – p. 280” — Give individuals opportunities to learn new domains, technologies, lines of business.  This may reduce the risk of a person becoming uninterested/bored with his current job.  Further, by rotating from one job to another, a person may discover where he fits best and delivers most value.  By having this opportunity, a person will also have a higher chance of merging the gap between “having to do a job” and “wanting to do a job”.  This is especially important with newly hired people that have a limited industry experience (e.g. recent college graduates).

“Try… Hire the best – p. 280 | Avoid… Hiring when you cannot find the best – p. 281” — Do not settle for less than “best people your money can buy”.  It is better to rely on fewer great people that you already have on-staff than bring on more under-qualified people, to speed up work, especially at the end of a project that is already late (Brook’s Law).  From a system thinking perspective if you are trying to increase velocity (output) by a scrum team and decide to do so by adding more developers that you procured on low cost (low pay will most likely buy you low-skilled developers), you will most likely reduce velocity, by having low-skilled developers introducing more bugs into a system. Please, see why.

“Try… Team does the hiring – p. 281” — If you plan on hiring an individual to join a team, please make sure that a team does most of interviewing and vetting.  Through that, not only a person’s skills and experience will be examined but it will become more apparent if a person can organically jell with a team: if there is compatibility, chemistry and synergy with other team members.   Panel interviews by whole teams are usually much more effective, since they include practical tests, real-life simulations and hands-on exercises.  It also allows some people to observe, while others ask questions, and then rotate.  Try to reduce the level of influence that HR personnel and first-line management have on the process as much as legally possible.  This will reduce the amount of subjective, administrative, frequently bias and error-prone screening (refer to top of page 17).

As a summary, please consider the following quote that describes sushi-roll-like organizational design in Large Scale Scrum (LeSS), by C. Larman (also, explained in detail in Agile Organization, as a Sushi Roll):