How do we pay people in a LeSS adoption?​

In every LeSS course and LeSS adoption, the question is asked how do we pay team members, Scrum Masters, and even managers. The reason why this question is always raised is due to significant reduction of organizational complexity. The number of roles, layers, positions is much less to choose from or grow towards. This seems to create some kind of communist system :-). Nothing is further from the truth.

Screen Shot 2018-08-16 at 09.34.44

Let’s go through what is already known and described by others.

Esther Derby advises in her blog post () to:

  • Don’t rate and rank individuals. Get rid of performance reviews and merit pay.
  • Adjust salary based on the cost of living
  • Do profit sharing with employees
  • Adjust salaries based on the current market rate for skills and roles
  • Increase salary / promote an individual who is “performing above others”
  • Use existing short feedback loops (instead of an annual cycle) to know how to improve as individuals. ScrumMaster plays an important role here.

In the book “Scaling Lean and Agile development”, Bas and Craig give several general advices: “Avoid…Job titles”, “Try…Create only one job title”, “Try…Let people make their own titles; encourage funny titles” , “Try…(if all else fails) Generic title with levels”, “Try…Simple internal title map to special external titles”, “Avoid…Job descriptions”, “Try…Simple general job descriptions”, “Avoid…Career paths”, “Try…Job rotation”, “Try…Start people with job rotation”, etc. This overview of advices give a basis for the question on how to pay people.

In the book “Practices for Scaling Lean and Agile development”, Craig Larman and Bas Vodde advise completely in line with Esther’s advises:

  • Avoid career paths that encourage people to see coding as just an early phase
  • Connect salary directly to the skills of an individual
  • Teams should define their own targets and measure themselves, not management.
  • Management should measure product performance instead of each team or individual contribution.
  • If, for some reason, an organization doesn’t want to remove performance appraisals, at least reduce the harm of such policies (page 408)

In addition to the above, I would add:

Sustainable over current performance

The following is based on teaching from Bas Vodde in his course, but he cannot remember stating something similar :-).

Although individual or a team performance is important, the more pressing question is whether we wish an individual to perform well now or continuously. If we wish continuous or sustainable performance then we should assess for sustainable performance. In other words, the ability of an individual to perform. Also, we should stop measuring current performance since it might have the opposite effect on a sustainable one.

What does this mean concretely?

Sustainable performance is a result of learning, an increase of one’s skills. In the context of Scrum and cross-functional teams, becoming multi-skilled is highly beneficial for the team and individual. This should be reflected in rewards.

Replace bonus with a one-time salary increase

Individual bonus essentially emphasizes temporary performance over a sustainable one. In reality, most HR departments have already figured out that emphasizing temporary performance and hence giving very different bonuses over the years is a bad idea. It becomes more a bonus in the name only. I have seen 2 forms of bonus systems:

  1. If the bonus is a significant percentage of yearly salary, then it barely fluctuates over the years unless the company has some financial problems. Fluctuations would seriously kill motivation and invite gaming of the bonus system. Initially, the bonus becomes an easier way for management to do salary corrections.
  2. If the bonus is a minor percentage of yearly salary, then it becomes a symbolic way to recognize the more sustainable growth and behavior of individuals.

So, we start to see the trend here that already materializes in an increasing number of companies. Even banks are ditching bonuses. All major Dutch banks have already removed individual bonuses for employees.

So, you would pay people more if they read more books?

What if someone is making sure that he is advancing his future career by learning and getting more skills at cost of current contribution? What if someone is learning stuff and in the meantime not delivering what he is supposed to deliver?

The assumption in this thinking is that there is a disconnect between becoming multi-skilled and actual delivery in this sprint. Hence the thinking that an organization must measure and reward current individual performance in addition to sustainable aspects (skills, experience).

That happens indeed. It happens in dysfunctional teams and organizations that have serious problems of disengagement. One should understand and solve the root cause. Low level of engagement due to the unhealthy environment cannot be remedied with financial incentives.

It could also be that an individual is simply not fit for the job, or doesn’t see the job as a chosen profession. The rest of the team (or manager if the team is unable) should fire the person in that case. Btw, hiring should be done by teams too.

In the end, an individual with increased skills and experience will contribute more and have a positive impact right now too.

Who and how determines skills level?

The following is my interpretation of a practice I learned from Craig Larman.

Introduce a scale: Developer level 1, level 2, level 3, level 4, level 5. The baseline (level 2) is the market average for let us say a C++ developer if the product is a C++ based product. Difference between levels should be significant enough since developers skills can differ significantly. Level 5 is someone who is a well-known name in the C++ worldwide community.

Who and how assesses this is a very easy question to answer. If the manager doesn’t already clearly sees who is which level compared to each other, then he already is not present enough and hence doesn’t understand what is going on. This should be an easy job for a manager, and he doesn’t require any special HR process or tool. A developer doesn’t grow from one to another level suddenly.

As mentioned before, the hiring process should preferably be done by teams instead of a manager. Also deciding level for a newly hired person should be quite easy for a team to do. But, since this is quite sensitive and obviously effects company cost, it should usually involve the manager.

Dependencies, teams and microservices

The Candidate LeSS trainers mailing list is a place where passionate people have interesting discussions. This post is a result of one of those discussions.

An assumption in agile community is that scaling agile is mainly about managing and reducing dependencies; either between teams or with others outside of a product group. This is used as a reason to introduce additional structures and roles, such as architecture owner, program / project manager, integration or a system team. These groups will manage dependencies and have overall picture.

An alternative is presented: microservice-driven teams organization. Each team works relatively independently from other teams, and owns set of microservices. Well…let’s see.

Just like embracing instead of managing changes (one of the Agile principles), this post explains why we should embrace dependencies instead of trying to avoid or “manage” them.

Therefore, LeSS doesn’t have roles, structures or architectural solutions to manage or reduce dependencies.

Of course, dependencies do not magically stop to exist in LeSS. There is something else going on. Let’s go through common types of dependencies.  Continue reading

Do 12 Agile Principles scale?

Do you remember those 12 Agile principles written a loooong time ago? Well, the whole Agile thing is kind of based on them.

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Of course, after such a long time these could be outdated. Since we love continuous improvement, the same could be applied to principles too right!? Well, a funny aspect of really good principles, is that they do not change easily.

I don’t have a good reason to suggest any change. Although there are few words here and there that could be different (e.g. overemphasis of projects instead of just product development), the reason to suggest Agile principles 2.0 would be too weak.

Nevertheless, a lot is written about how Agile Manifesto is outdated, something that was hot in 2001, but world has changed in last 10+ years. Therefore some improvements are suggested.

So, this is all great. Good discussions. But, what really bugs me are the compromises.

improvements_vs_compromises Continue reading

Scrum, dogmas, and actual results

The following statements are often mentioned:

  • Scrum-but is bad. You should stick to Scrum rules, otherwise you are doing it wrong.
  • Scrum coaches are often dogmatic.
  • There is no right or wrong way to do Scrum. It is all about inspect and adapt, even for Scrum rules.
  • My Scrum-but way is working very well.

I could continue, specially when talking about certain details. Such as, does it make sense to have 5 Scrum teams with 5 Product Owners delivering a single product? Continue reading

Descaling organisation with LeSS

Scrum is a successful and widespread framework, but at some point almost everyone started to talk about scaling. Large organizations want to spread this miracle and Agilize everyone. Many consider agilizing large organisations as bad, and some say it is inevitable. In any case, opinions are often negative about “big Agile”.

But what exactly is being scaled when we talk about scaling in Scrum or Agile software development? It seems that most imagine growing something larger, usually the number of people, or painting everyone in fake Scrum colours. “I see task boards, task boards everywhere!”. 🙂

Naturally, this triggers negative reactions from the Agile community.

Why would you want to deliver and support a product with multiple teams, when one team is so much more effective?

The first purpose of LeSS (Large-Scale Scrum) is actually descaling through organizational change. Descaling the number of roles, organizational structures, dependencies, architectural complexity, management positions, sites, and number of people. LeSS is not about scaling one team into multiple teams. LeSS is about scaling up Scrum itself in order to achieve organizational descaling. Just to be clear, looking for a scaling framework to “buy and install” and to organize lots of people for the sake of “painting agile or Scrum onto our big group”, is just plain wrong. Continue reading