Sunday, May 15, 2022

Dice Estimation

Although I am a proponent of "#noestimates," that is - the concept that estimation is often the consequence of unsound mental models, and in itself somewhat wasteful, because we often don't know - I still propose an estimation technique that is as useful as it is simple. BUT - it requires context. Let me give this context:

Problems with estimation

Regardless of how we put it, one major challenge is that many organizations use estimates as if there was certainty that they can be met - which is a common dysfunction, because it results in undesirable wasteful behaviours, such as upfront design, padding, "challenging estimates" - and sometimes even post-hoc adjustment of estimates to match reality. None of these behaviours help us deliver more product, and they may even impede quality or time-to-market.

All these aside: we don't know until we tried - that is, there's this thing called "the high probability of low-probability events," so regardless of how much effort we waste on trying to get those activities "right", we could still be wrong due to something we didn't factor.

These are the common reasons for the #noestimates movement which simplys reject the discipline of upfront estimation in favor of monitoring the flow of work via execution signals to gain both predictability and control. You may ask: "If estimation is so obviously flawed, then why would you propose yet another estimation technique?"

Category Errors

One common challenge teams face is that not all work is equal: Giving a trivial non-tech example, it doesn't take much expertise to realize that building a tool shack isn't the same category as building a house - and that's not the same category as building a Burj Khalifa.

By simply letting uncategorized work flow into teams, we risk that extremely large packages block the flow of urgent high-value items for a prolonged time. Hence, a first categorization into "Huge, Large, Small" does indeed make sense - The key realization is that these aren't equal.
Hence, dice estimation first categorizes work into the right bin: everything that's workable can be taken up by the team, while everything that isn't workable should be managed appropriately before being worked upon.

Six-sided dice

Story Points worked out terribly, and they led to many dysfunctions - so let's avoid that side track. Instead, let's say that we estimate items in dice values. For small items, our estimation unit would be team-days, for large items, it would be weeks, and for large items, it would be months.
That also leads us to the first logical connection: 
One Small Dice at 5 or 6 could already classify for a "1" on a medium dice. We could think about splitting it in two if we want to take it on. On items bigger than 5, we should exercise caution: do we understand it properly, is the cost of implementation warranted - is it really the best thing to do next?

The same goes when an item exceeds 5 on the week count - at that point, it becomes a huge dice: we might want to check a lighweight business case and pivot before proceeding.

How Dice Estimation works

Dice estimation is very easy - you simply ask, "If each day of work was a dice roll, what would be the amount of sides on our dice so that we have enough time to hit a '1' - on average - by the time we are Done?" 

That is, if the team expects to be done on 2 days, they would choose 2. If they would expect 3 days, they would choose 3 - if they expect 6, it would be 6 days.

Measuring Confidence

Since dice rolls aren't linear, this form of estimation focuses on levels of confidence in completion within a predefined period of time. Hence, despite the fact that we estimate in days, dice estimation values confidence - and thereby clarity and understanding - above quantity of work.

Estimating with uncertainty

Just like a D6 doesn't mean that "we will roll 6 times, then we will have rolled a 1" - what we estimate is the amount of faces on the dice and thereby the expected amount of days that the item will be done.
Think of it like this: If you have a coin, you have a 50% chance to get heads on the first try - and while statistically, you'd expect to get at least one heads in 2 attempts, it's theoretically possible that you need to flip the coin an infinite amount of times and never get heads.

The estimate in team-days helps us manage our work on the Dailies in an efficient manner - as long as the estimated amount of days hasn't elapsed, it's safe to assume we are on track. Any item reaching and/or exceeding the estimate should be scrutinized: are we stuck, did we misunderstand something - what is going on? The "estimate," thus, isn't even estimating effort - it's forecasting a pivot-or-persevere checkpoint so that we minimize sunk cost.

Lightweight estimation

We can estimate work items either as they arrive, during refinement, or when we get busy - that doesn't even matter. The key reasons for estimation are first, avoiding category errors and second: setting up an intuitive checkpoint so that we don't run out of bounds.
With Dice Estimation, we avoid category errors and institute checkpoints in execution

Of course, you could use dice estimation during Sprint Planning or in a PI-Planning as well, but you don't even need cadences to take advantage of Dice Estimation.

Predictability and Forecasting

As we know, a dice averages at 3.5, so even if we didn't do anything yet except categorizing by dice size, we know that our backlog of workable, small items would take about 2 weeks for 3 items. Once we've done a little bit of work and know how much the completed items took, we can either run a simple Monte Carlo Simulation or apply the Law of Large Numbers to figure out how much known work we have ahead of us. The same applies to the Large and Huge dices, which gives us a fairly decent understanding of when an item might be delivered, based on backlog position.

Not a Performance Metric

The dice metaphor should make it easy to explain how neither can one measure the perfomance of a dice-roller based on how often they roll a die to get a certain number, nor does it make sense to "squeeze" estimates - the probability of guessing the right number don't increase by reducing the range of guessing if the number is set, but hidden. If anything, squeezed estimates would lead the team to spend more time on examining exceptions - hence, reducing performance. 

Why you should switch from Story Points to Dices

Dice Estimation is a minimum effort method of right-sizing work that helps with:
  1. Sufficient predictability
  2. Easy plannability
  3. Execution checkpoints
  4. Avoiding large batches that block flow
  5. "Split, Pivot or Defer" decisions

Thursday, April 14, 2022

Ten things eerily close to Scrum that you may misunderstand

 There are some ideas around Scrum that sound a whole lot like they're based on the Scrum Guide - when, indeed, they aren't. Even worse: you might be doing them in a way that could cause problems. Let's dig in.

1 - Scrum Roles

If I ask you what the Scrum roles based on the Scrum Guide are, you're probably very quick to answer: "Scrum Master, Product Owner, Developer."


What? How can that be wrong?

Well, because the Scrum Guide doesn't mention any roles. Indeed, it doesn't even use the term, "role" any more. Scrum Master, Product Owner and Developer are merely accountabilities. That means, someone has to be accountable.

2 - Dedicated Scrum Master

The concept of a "dedicated Scrum Master" isn't mandatory based on the Scrum Guide. Neither is the concept that "a Scrum Master shouldn't be technical, so they don't dump their own bias on the team."

These ideas are often marketed in an attempt to provide job safety for the myriads of people who can do nothing else. You can do Scrum very effectively even if Scrum Mastery is an accountability that rotates among developers, for example, on a per-Sprint basis.

Caveat - they need to know what they need to do, and have enough time for doing it.

3 - Product Owners aren't developers

Neither is the concept of a "Product Owner who isn't a developer, so they don't interfere in the work" prescribed by Scrum. It's entirely possible that, for example, a senior developer assumes the PO accountability. As long as the Product Goal is clear, the Product Backlog well-maintained, Sprints deliver high value and stakeholders know what to expect, there's not going to be much of an issue.

4 - Team autonomy

Are Scrum teams really autonomous? Doesn't Scrum rely on team autonomy?

Try searching for the term "autonom" in the current Scrum Guide - you'll be surprised! Team autonomy isn't mandatory for Scrum. In fact, in larger organizations, it can't be - because if you have larger products, multiple teams need to collaborate.

Before proceeding, let that sink in:
Scrum teams are not free radicals.

5 - Each team has their own Product Owner and Product Backlog

Certain "scaling" approaches suggest that each team has their own Product Owner and Backlog. Well - for a Sprint backlog, that's true. But having a separate Product Backlog for each team adds problems rather than solving them. The Scrum Guide states that multiple teams working on the same product, "should share the same Product Goal, Product Backlog, and Product Owner."

Note that this isn't a Scrum rule, only a suggestion. I will leave it as an exercise to the reader to figure out why that is a good suggestion though. And if the answer is too difficult, try the book "Scaling Lean and Agile Development" by Larman and Vodde.

6 - Teams have their own Definition of Done

One of the first exercises Scrum masters typically do with a new team is to draft up their own Definition of Done. That's not necessary in larger organizations, because the organization could already provide a DoD. "But that's not Agile..." - no! On the contrary, it ensures that the term "Done" has a consistent meaning anywhere in the organization. It reduces complexity and misunderstanding. It's quite irritating when a stakeholder has to ask in every Sprint Review, "What ... exactly ... does 'Done' mean, when you say that?

Teams are encouraged to add details to the organizational Definition of Done. If they deviate from the organization-wide DoD, though, they invite trouble. Caveat - an organizational DoD should be absolutely minimal, lest it slows down teams with pointless busywork.

7 - Refinement meetings

"In order to prepare for the upcoming Sprint, the Product Owner invites the team for at least one Refinement meeting during the ongoing Sprint." That's a really common practice - but it's not what Refinement is!

Refinement is no Scrum event, for a good reason. Taking a peek at the top couple backlog items, maybe doing a small spike, or creating a wireframe, are all activities that can't really be done very effectively in a centralized meeting. They're better done by brooding over the items from your desk. And sometimes, reaching out to a user has a delay, and we really need the answer before moving forward. The asynchronity of refinement also ensures we don't disrupt the flow of work by having yet another meeting on our calendar.

8 - PO acceptance

During the Review, the team demos their work to the Product Owner, who then accepts it.

Search for anything even remotely resembling this concept in the Scrum Guide. It just isn't there. This sentence contains so many flawed concepts that if you practice this, I wholeheartedly advise a Scrum refresher training. 

The Review is about stakeholder alignment, and it's a working session, not an approval meeting.

The Product Owner also doesn't supervise any work done by developers - together with all the stakeholders, they inspect the outcomes of the Sprint, regardless of how much work was done or not done. 

Nobody "accepts" individual work items of the team. Developers meet their DoD, and that's it. If the DoD isn't adequate or the backlog items not sufficiently valuable, that's not a problem we fix by adding an approval step to the Review. We fix it by improving our DoD, refinement and planning approaches.

9 - One Increment per Sprint

This is probably one of the oldest misunderstandings of Scrum - that at the end of each Sprint, the team delivers one Product Increment which contains all the changes made to the product for the duration of the Sprint.

An increment is produced whenever a modification has been made to the product, and it's in a usable state. Scrum and MinimumCD are not at odds. Scrum teams can - and actually should - produce as many increments as possible during a Sprint, and also deploy and/or release them as early as possible.

During the Sprint Review, the sum of all increments produced since the last Sprint Review is inspected, as these are the outcomes of the Sprint. This sum could be anywhere from zero to infinity. A team which only works towards a single, integrated Increment at the end of a Sprint, will be much more likely to find themselves empty-handed, so that's a bad strategy to begin with.

10 - Backwards-facing Retrospectives

"The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved."

That's a literal quote from the Scrum Guide, so isn't isn't the Retrospective pattern of "What went well, what didn't go well, what we could improve?" - the best way to conduct a Retrospective? No.

"The Scrum Team identifies the most helpful changes to improve its effectiveness." - that's also a quote. Of course, we need to have consider what happened in the last Sprint. The purpose of our Retrospective, however, is looking forward, identifying the most helpful changes. If all you do in your Retrospectives is dwell on the past and make miniscule adjustments so that the same old problems don't constantly haunt you, you're not future-proofing your team.

The most helpful change you can make is that which will make you most successful in the future - which may not necessarily be fixing a problem you had in the past.

Bonus - Ceremonies

It sounds like an innocent mistake, but there's a huge issue hidden behind this label. Scrum events are called "event" instead of "ceremony" for a reason.

An event is, literally, "when something notable happens."
A ceremony is, literally, "doing what we always do in the way we always do it." 

Organizations implementing Scrum "ceremonies" usually find themselves getting very low value from these, not understanding why they're important - and not thinking about better ways to achieve better outcomes. 

As a consequence, we see purely mechanical Scrum which helps nobody, gets on developers' nerves, and the one thing that makes agility tick - Double Loop Learning - is overboarded before it ever started.

Friday, April 8, 2022

Why test coverage tagets backfire

Most organizations adopt a "Percent-Test-Coverage" metric as part of their Definition of Done. Very often, it's set by managers, and becomes a target which developers have to meet. This approach is often harmful. And here's why:

The good, bad and ugly of Coverage Targets

Setting coverage targets is often intended as both a means of improving the product, as well as improving the process - and getting developers to think about testing.

The good

It's good that developers begin to pay closer attention to the questions, "How do I test this?" as well as, "Where are tests missing?" Unfortunately, that's about it.

The bad

The first problem is that large legacy code bases starting with zero test coverage will put developers into a pickle: If I work on a component with 0% test coverage, then any amount of tests I write will still keep that number close to Zero. Hence, the necessary compromise becomes not setting a baseline number, just ask for the number to increase. The usually envisioned 80+% targets are visions for a distant future rather than something useful today.

Looking into the practice - as long as the organization is set up to reward minimizing the amount of time invested into unit testing, the outcome will be that developers try to meet the test coverage targets with minimum effort. 

Also, when developers have no experience in writing good tests, their tests may not do what they're supposed to do.

The ugly

There are many ways in which we can meet coverage targets that fulfill Goodhart's Law:

Any metric that becomes a target stops being useful.

Often, developers will feel unhappy producing tests that they create only to meet the target, considering the activity a wasteful addition to the process, which provides no benefit.

At worst, developers will spend a lot of time creating tests that provide a false sense of confidence, which is even worse than knowing that you have no tests to rely on.

But how can this happen? Let's see ...

The first antipattern is, of course, to write tests that check nothing.

Assertion-free testing

Let's take a look at this example:

Production code

int divide(int x, int y) { return x/y; }


print divide(6,2);

When looking at our code coverage metrics, we will see a 100% coverage. But: the test will always pass - even when we break the production code. Only if we were to inspect the actual test output (which is manual effort that we probably won't do) - we will what the test does: There is no automated failure detection, and the tests aren't even written in a way that we would detect a failure: Who would detect the problem if suddenly, we got a "2" instead of a "3" - we don't even know which result would have been correct!

Testing in the wrong place

Look at this example:
Class Number {
int x;
void setX(int val) {x=val;}
void getX() {return x;}
void compute() { x=x?x/x^x:x-x*(x+x); }
n = new Number();
assert (N.x == 5);
assert (N.get() == 5);

In this case, we have a code coverage of 75% - we're testing x, we're testing the setter, and we're testing the getter.

The "only" thing we're not testing is the compute function, which is actually the one place where we would expect problems, where other developers might have questions as to "What does that do, and why are we doing it like that?" - or where various inputs could lead to undesirable outcomes.

Testing wrongly

Take a peek at this simple piece of code:
int inverse (int x) { return 1/x; }
void printInverse(int x) { print "inverse(x);" }
assert (inverse(1) == 1);
assert (inverse(5) == 0);
assert (print.toHaveBeenCalled());

The issues

There are numerous major problems here, all of which in combination make that test more dangeous than helpful:

Data Quality

We may get a null pointer exception if the method is called without initializing x first, but we neither catch nor test this case.

Unpexpected results

If we feed 0 into the function, we get a Divide by Zero. We're not testing for this, and it will lead to undesired outcomes.

Missing the intent

The inverse function returns 0 for every number other than 1 and -1. It probably doesn't do what it's expected to do. How do we know? Is it poorly named, or poorly implemented?

Testing the wrong things

The print function's output is most likely not what we expect, but our tests still pass.


If we rely on coverage metrics, we might assume that we have 100% test coverage, but in practice, we may have very unreliable software that doesn't even work as intended.

In short: this way of testing tests that the code does what it does, not that it does what it should.

Then what?

The situation can be remedied, but not with numerical quotas. Instead, developers need education on what to test, how to test, and how to test well.

While this is a long topic, this article already shows some extremely common pitfalls that developers can - and need to - steer clear from. Coverage metrics leave management none the wiser: the real issue is hidden behind a smoke screen of existing tests.

Tuesday, March 15, 2022

Bugfixing team - good or bad idea?

In many organizations struggling with quality, a gut reaction is setting up a "bug fixing team," which has only one purpose: Cleaning up the myriads of known bugs in the software so that other teams can focus on new features.

There's a concept that "developers can go faster if they don't have to worry about the bugs in their code." This concept is a delusion, puts unrealistic expectations on the bugfix team, and will ultimately lead to disappointment.

Why bugfix teams are bad

Bugfix teams are a counterproductive workaround stopping the organization from solving their actual problems:

  • Developers don't own their work. They can fire-and-forget, because it's no longer their problem after delivery.
  • Developers don't fully understand how their code actually works, hence there's nobody who has deep knowledge of the inner workings of the product.
  • Developers don't learn how to write better code, because they don't have to work through bad code.
  • Technical debt continues to grow, because the Bugfix team will only work on known problems while others introduce more problems.
  • Building a new feature on a buggy baseline doesn't add to low quality - it multiplies.
  • The perceived progress of the delivery teams is an illusion, because it doesn't mean that the delivery doesn't contain a time bomb.
  • The Continuous Improvement process is subjected to quantity of output, which is the very reason why the problem occurred to begin with.

I have been part of Bugfix teams. It's a frustrating, ungrateful job and an uphill battle unless all other developers also take responsibility for the quality of their own work.

How bugfix teams can succeed

There is a way to set up a successful Bugfix team, however:

  •  The "Bugfix" team is a team like any other, but they can fully commit to - and focus on - improving quality and have no commitment on new features. And they get a spotlight in stakeholder reviews to demonstrate their improvements.
  •  All other teams practice a rigorous Stop-the-Line process and do everything in their power to not let low quality pass downstream. The policy is, "Bugfix team improves fundamentals, others stop deterioration and improve within the context of delivery."
  •  The Bugfix team responsibility rotates.

Technically, that will make the Bugfix team a "legacy rewrite" team rather than a "locate, isolate and fix the bug" team. Their mission shaping the future of the product, not merely dealing with its past.


My stance on the topic is, "no Bugfix team unless you can clearly explain how you're actually going to solve the problem that leads you to needing it."

You can't solve the problem of low quality simply by throwing money at it.

Friday, March 11, 2022

Test Automation Specialists - what a waste!

"Test Automation Engineers require someone who will write the test cases for them, and they can start automating right after the software is deployed onto the test environment."

It's 2022, and I just had this conversation yesterday. Seriously?

Overspecialization leads to Waste

If we work like that, we needlessly create bottlenecks, we test too late, our tests will be of low quality, and we will spend a lot of time on identifying, tracking and reworking defective deliveries. We produce a lot of work, but not quality.

In a well-functioning software organization, there can be no such role as a "test automation engineer" who is fed work by "test designers." 

Although it sounds "resource efficient," that approach generates massive amounts of waste in all categories of Lean Muda


When automated tests aren't written by developers, and only available once a software package is released, we end up with three kinds of defects:

  1. Product defects, i.e. things the product should (or shouldn't) do, but that weren't correctly implemented, which require another software update.
  2. Automation defects, i.e. things the test automation should (or shouldn't) do, but that weren't correctly implemented. Until clarified, these lead to significant communication overhead.
  3. False negatives, i.e. inadequate automation not catching existing defects. This is significantly more likely when automation isn't written close to the code, and might omit dangerous cliffs in the product implementation.


Whenever actors in a process change, there's a handover. At the point of handover, we induce delay, lose information and risk the introduction of defects. This makes our process slow and error-prone. When test itself becomes a source of error, we should stop and think.


Handovers also mean that we're moving artifacts: test descriptions, build versions and defects - without need. We also need to coordinate this motion, which means we induce additional meetings into our process, which also slows us down and adds non-value added overhead. Motion also leads to inventory waste.


As previously mentioned, un-automated tests will pile up as inventory, as will un-tested deliveries. When tests fail, the defect notifications are made available at a point in time when developers are working on other things. Hence, we are adding three queues to our process. Each queue contains work waiting to be done, and the combined length of all these queues is value delay for our customers.


As mentioned in my article on CI/CD industry benchmarks, the time required between when a developer makes a change, and when a developer receives feedback on whether everything is correct shouldn't exceed a few minutes, preferably just a few seconds. If automation begins upon delivery, this period of time is impossible to warrant. The delivered product has to wait a significant amount of time until it can produce customer value, and developers will turn their attention elsewhere.


Having different people automate tests and write productive code leads to "overprocessing," often called "gold-plating:" As mentioned in my article about the test pyramid, we should try to automate as close to the code as possible. When we're doing high-level tests which could instead be low-level tests, we make our test suite more complex, slower and less reliable than possible.Unit tests are extremely quick both to write and execute. Test automation engineers who automate black box/gray box tests will spend a significantly higher amount of work to write tests with poorer outcomes.


Since the amount of labor to create a product increment in server code and test automation are extremely hard to balance, the strategy of automating after the fact usually leads to developed product features piling up, waiting to be automated. As a consequence, the decision is often to release these without proper test automation coverage to flush the waiting queue. This builds up "technical debt" which deteriorates product sustainability.

Human potential

When developing software with multiple people, we act as a team. We can learn from each other, and we can align: Someone who can automate tests, can also write features. Someone who can write features, can also automate. As a team, we can align during planning "who does what," and fill our information gaps so that those doing the work have full information and don't need anyone else to fill in for them. Techniques like pair programming or code reviews ensure that even if one person makes a mistake, someone else will catch it before a defect even enters the system. It's a limiting belief to think that somehow people can't learn - we all can, if the conditions are favorable. Maybe not everyone will be the greatest developer, but we don't need to: we work within our ability, and grow our capacity a little every day.

To confine a test automation engineer to automating defined test specifications, and to confine coders to write code without understanding how to do that without defects - is an insult to our human intellect, and a very expensive one, at that:  All the above seven wastes cost a lot of money that we could save if we would just improve our collaboration, communication and skillset.

Lean Software Test Automation

Please, let me clarify. I don't believe that test automation expertise is a waste - the waste is actually hidden in the process, and how we use our talent.

A much leaner approach which avoids all of the above eight wastes is to educate and empower - use QA to help developers learn how to define the right tests, how to apply processes like Test-Driven Development and Behaviour-Driven Development, and guide them on their journey to deliver Zero Defect Quality. And in reverse, having developers upskill our test automation experts to help them deliver integrated pieces of value including working software.

The purpose of test automation in such an organization isn't to find defects - it's to maintain the high frequency of delivery of high quality products, and to serve as a living documentation for all behaviours of the product which is maintained as part of the development process without overhead.

Decision-making in an agile organization

A challenging question in Agile organizations is: "Which decisions should be made where?" - we quickly end up in a heated debate of "team autonomy versus command and control." A red herring - and a false dichotomy that misses the big picture. There is a better way.

Making decisions

Let us first discuss briefly about the three ways that decisions can be made in companies:


Traditional organizations may be most familiar with this type of decision. When something needs to be decided, a manager needs to be informed about what is to be decided, preferably also with some information on the consequences of various decision types. At a convenient moment in time, the manager will decide, and the affected parties will act based on the decision.

Depending on how information is presented to the manager, the manager may decide based on an unknown bias. Managers are often unable to fully understand the consequences of their choices. In turn, teams have to deal with consequences that may not even make sense to them, but they lack the power to change things. The system encourages currying favor over full transparency, and a "making things look good" is worth more than "doing what is right." 

A lot of time is lost in presenting information to management in order to prepare the decision, even when the decision is seemingly obivous. Revising the decision requires significant evidence as well, even after the negative repercissions are already visible. Hence, top-down decision on the work are rarely efficient, effective or even helpful. And that's why they are avoided in leaner organizations wherever possible.


Agile organizations, especially those centered around Scrum, emphasize team autonomy - and thereby, autonomous decision making. Many developers don't like managers interfering with their work, and prefer this way of making decisions. Some get very religious on the "autonomy" part, and will insist on teams getting their way.

Autonomous decisions are both feasible and efficient when the team operates in isolation: As long as it works for the team, we're good. When the team isn't happy with a choice, they can quickly revise it and improve.

Team autonomy sounds great, but isn't a feasible approach when multiple teams interact.
Let's say that team A would like to define a customer as firstName and lastName referenced by customerID, and team B would like to define the customer as fullName and title referenced by customerRefID: Who is right?
If A and B decide autonomously, the system won't integrate, so everyone is "wrong."
Should management decide?

That brings us to the third option, which requires willingness to compromise:


Let us redefine team boundaries to objective boundaries. People contributing to the same goal, working in the same context, or on the same products, need to collaborate, lest they get stuck dealing with friction rather than making progress.
In larger organizations, we have multiple teams. They might be planning, working and delivering independently - yet, at some level of abstraction, they share the same goal.

As an example, if we're working on an Online Shop, we benefit little if our checkout process is optimized at the expense of user registration: our total revenue might go down if we force people to provide payment data upon registration already. Neither the "Checkout," the "Payment," nor the "Registration" teams can autonomously decide which approach is the best - they need to collaborate!

Thus, a "federation" is born: People whose work overlaps for one reason or another can federate. A federation compromizes on local autonomy to optimize globally. We have some centralization, and some decentralization, and we apply a higher-ordered decision framework to determine both how, and what, we need to centralize.

A federation offers us fast and efficient team-level decisions, as well as sustainable and effective overarching decisions.

Guardrails of federated decision-making

A number of common pitfalls can render a federation ineffective:

  1. Not involving people who are affected by outcomes.
  2. Involving people in the discussion who aren't involved in the outcome.
  3. Forming decision queues.

This happens when we violate the general rule of thumb that any federation should decide as little as possible, and as much as necessary. 

The following decision-making flow can assist us in determining which decisions we would like to keep autonomous, and which are better to federate.

In sequence, we can ask three questions to determine whether we require a central federated decision session:

  1. Will the decision affect others?
    • We only need to involve those who are affected.
    • If we affect nobody outside the team, we don't need others to agree.
  2. Will the decision have long-term impact?
    • Easily reversible choices can be subjected to experiment, and inspecting outcomes.
    • Decisions that have a high cost of change require deeper discussions.
  3. Is the decision highly time-critical?
    • If there is a high cost of delay, "it's easier to ask for forgiveness than get permission."
    • If cost of delay is lower than cost of change, the decision should be made centrally.

As we know from governments, federation has a cost attached and easily leads to bureaucracy. Hence, with every centralized decision, we should inspect and adapt on, "What are the costs and benefits of centralizing this?" - and, "Are there things we could change so that we could do this autonomously?"

Thursday, February 24, 2022

Time to discard the "T-Shaping" model!

 A common concept in the "Agile" community is that of T-Shaping. Regardless in which form or fashion it is promoted, the narrative is basically this: People have certain skills, and if they are one-trick ponies or are too generalist, they need to form a so-called "T-Shape." Nonsense!

The concept of the T-Shape

A specialist is a person with a very narrow skillset (making that person an "I"-Shape) while a generalist has a broad skillset (making that person a "dash"-Shape). 
A broad set of skills plus one deep expertise is a "T", multiple deep expertises are "Pi." And then, no model couldn't be "improved" by adding complexity, so we get variations like "M" Shapes, i.e. non-generalists with multiple expertises, and "E" shapes who aren't only experts, who also have "experience, exploration and execution." - although that's clearly buzzword bingo terrain, because what kind of an expert doesn't also have these?

Even I have blogged about T-Shaping, for example, here.

With the model, we were moving the burden onto people: "You must form a T/Pi/E-Shape." Thats nonsense, because it's not like people wouldn't do that on their own volition. In fact, most people who find that they can't use their skills at work will spend their time acquiring off-work skills, such as, for example, learning an instrument: everyone is Pi-Shaped, the only question is if it helps the company.

And now, I announce the time to ditch this model in favor of another model that already predates the Agile Manifesto - "Psychological Flow", by Mihály Csíkszentmihályi.

Psychological Flow

Let's take a look at the model Csíkszentmihályi proposes: He uses the dimensions of "Challenge Level" and "Skill". The very assumption that people have "one" or even a very limited number of skills is already absurd. Consider, for example: breathing. Do you know anyone who doesn't have this skill? Depending on what would qualify as a "skill," people are experts in thousands of them.

Instead of thinking about skills as discrete variables with a discrete set of values (e.g., "none", "basic", "advanced", "expert" ...) - we could think of "skill" as a continuum of different, integrated topics on a continuum spectrum.

Most importantly, the psychological flow proposes a second dimension: the level of challenge, in relation to the skill. For example, asking a Chess Grandmaster to state how a pawn moves is like a relaxation exercise. On the other hand, someone who never cared about Chess won't even take an interest in this question, "why should I care?"

If you'd ask a senior project manager to take care of large, critical programme, that brings out excitement and a sense of, "I am the right person for this job, and I can do it." Their brain would immediately sort through potential approaches and how to make it a success.
A college fresher, on the other hand, might be anxious about where to start and what to do.
That's the basic concept.

Notice that neither the "challenge level" nor the "skill level" are measured on an absolute scale - they can be considered from the perspective of the person who is doing the work: Is this work "low challenge" or "high challenge," does it require "low skills" or "high skills?"

How is Flow related to T-Shapes?

Well, it is - and it isn't. Instead of asserting that a person has a certain skillset required to do the job, we reframe the skilling challenge:
  1. Is a task adequate to a person's skill level?
    1. We should not under-challenge people, lest they bore out.
    2. We should not over-challenge people, lest they become become worried or anxious.
  2. How do we ensure that people receive challenges which allow them to use high skill?
    1. High challenge, medium-skill tasks get people to become interested in what they do and that's how they grow.
    2. High challenge, high skill tasks bring the best out of people.
The challenge, hence, is to identify meaningful, highly challenging work which is at least within grasp of people: medium skills get people excited, high skills get people to perform at their best.
Failure in "T-Shaping" isn't on the individual - it's team management not ensuring people have sufficient challenge to grow and show their performance.
(note based on feedback: in a self-managed team, "team management" isn't top-down - it's what teams decide to do)

T-Shaping ignores Flow

The T-Shaping model makes an implicit assumption: that all the work in the expertise domain is of interest to a person, and that it's a good use of their skills. This isn't always the case. Part of the work may make a very advanced person fall asleep, while being quite challenging for someone new to the domain. Hence, the best way to distribute work in a team isn't based on a certain "T-Shape," but to ensure that people reach a flow state - that is:
A team as a whole performs best not when people exercise a certain "T", but when the work provides everyone with sufficient, yet not overwhelming, challenge.
We shouldn't upskill with the goal of acquiring an abstract "T-Shape" - that's a weird framing already. 
Instead, we should distribute work in a team so that everyone is excited to do what they do, while ensuring nobody is overchallenged and anxious or underchallenged and bored.
Whether the result is something like a "T-Shape," doesn't even matter - because the primary result is a highly qualified team whose members are comfortable taking on slightly bigger challenges every day. 

Let's forget the T-Shape.
Let's refocus on the question, 
"How can we distribute work within our team, so that everyone gets to spend the highest amount of time possible in a flow state?"

Wednesday, February 16, 2022

The different definitions of Agility

One reason why getting different people on board in an agile initiative is because they may not understand what's in it - for them. We can put the different perspectives together by looking at the different definitions of agility. This allows us to negotiate better with people who have a different focus in their own work and gain their support for change.

Everyday definition

"Move quickly and easily." - Cambridge Dictionary
Note the two vectors here: Speed and effort. This definition doesn't focus on externally imposed change. Although only implicitly, it is primarily concerned with the ability to reach one's goals.

Managerial definition

Acting according to the current situation - Peter Drucker
“The greatest danger in times of turbulence is not the turbulence: it is to act with yesterday's logic.” 

Change is only a problem when we're not able to think and act in a manner suitable to the new circumstances. We must be sufficiently flexible to adjust when something unexpected happens.

Financial definition

"Turn on a dime for a dime." - Craig Larman 
There are business opportunities every day. Many businesses can't capitalize on opportunities for two reasons: Either, the cost of grasping the opportunity outweighs the gains from the opportunity (i.e., a negative business case). Or, the window of opportunity expires before we can grasp it.

Technical definition

"Minimizing the cost of change for code." - Kyle Griffin Aretae

"Cost of change over the long term is almost the only thing worth paying attention to when working in code. It's more important than doing any individual feature requested most of the time."

The initial creation of code is marginal compared to the cost of maintaining or changing the code. We have high code-level agility if there is a low cost of change for our code, and low code-level agility if we are spending a lot of time, energy and money to change our code.

The different focus

Looking at this diagram, we see that no single definition is all-encompassing - and that there is only a small overlap between them.
Hence, we have to be clear what we are setting out to achieve, and how we would like to achieve it.
  • Do we want to increase sustainability and reduce effort? Unless we can tick these boxes, developers most likely won't care.
  • Do we want to become more adaptive and faster? That makes our initiative interesting for management.
  • Do we want to reduce cost and increase profitability? Otherwise, let's not assume finance will support us.
  • If we're not in it to get more done in less time, surrounding stakeholders - like Marketing, Sales or Customer Service, won't care.
We can't dogmatically insist that we want to do only one thing, like increasing adaptability, because we'd struggle to get anyone to support this. Instead, we can use these different perspectives to have deeper conversations as to what people need from a change initiative, and how they would like to become part of this change.

And - the Customer?

Frankly - as a customer, I don't care about your agility. 
I care that I get what I want, how I want it, when I want it. How you do it - your call.

Wednesday, February 9, 2022

The importance of Retrospectives

"Can't we just skip the Retrospectives when we don't have the time?"
While I am myself not a big fan of the Retropective events that I see in many Scrum teams - when considering skipping Retrospectives, we solve the wrong problem: Retrospectives are Scrum's engine of Continuous Improvment. What matters is not the event, but that the team is constantly taking active steps of improvment. Retrospectives just kick-start the mindset of improvement.

The case for Retrospectives

  • The purpose of the Retrospective is finding significant improvement potential. 
  •  Significant, from a statistical point of view, is 5% or above. 
  •  "5% or above" means, "Something worth at least 2 hours a week
  • Investing 2 hours every 2 weeks to find something worth 2 hours per week already paid off within a single Sprint. 
  •  A team improving by 5%, 25 times a year, will operate at over 300% of their original performance after a year - yes, they will be three times as effective as when they started!
  •  A team skipping half of their Retrospectives, doing only 10 a year, will have improved to 150% of their original performance after a year - give or take variation, it will appear as if this team hasn't improved and is almost at their original level.
  • A team having effective Retros every Sprint will visibly outperform a team skipping half of their Retros - to the point where they deliver twice the value per time. 
  • Or, stated differently - a year down the line, a team doing effective Retros will be worth as much as two teams skimping Retros, and as much as three teams without any effective Retros.

The Bang for the Buck

A team investing into effective Retrospectives is worth twice as much to the company as a team which values delivery over improvement.
Teams taking Retroespectives seriously lead to an organization needing fewer people to deliver the same value. Hence, less coordination. Hence, teams get more autonomy, because they don't need to fit into a management corset.
Hence, developers can spend more of their time doing what they like best: writing code, not sitting in meetings. That makes them happier. And happy brains are more productive.
Also, since developers in such teams are worth so much more to the company, they are worth every cent - a great argument for negotiating higher pay.

Effective Continuous Improvement makes everyone a winner: Customers, getting better products quicker. The company, getting more value without hiring extra people. Developers, who get better working conditions, and deserve higher pay.

Retrospective Antipatterns

We have already touched the first antipattern: Skimping Retrospectives. Every lost opportunity of a Retrospective is an improvement not happening, putting the team behind on their potential, sacrificing a lot in the future to gain very little right now.

Skipping Retrospectives usually happens because teams have ineffective Retros. Each Retrospective that didn't deliver a significant improvement outcome was a waste. Hence, teams need to figure out how to get more value out of their Retro. Hint for Scrum Masters - There's a surprisingly low correlation between form and effectiveness of a Retro.

The third antipattern is giving up too early on improvement: If there are impediments towards improvenent, these need to be resolved, rather than taken as a reason to not improve.

If you feel that Retrospectives don't make you better, then improving that is your highest priority.

True story

I don't like formal Retrospective events all that much, but I do like a good continuous improvement process (CIP). Retrospectives are just one way to do it. CIP can be done totally informal. I just want to tell you this story to see how Retrospectives can transform a team.

One of my teams had a 2-hour lunch break every day. This "break" included having a walk, and talking about improvements. 
After 2 months, we delivered in a week what others would do in a month.
Within 3 months, we finished a project we had forecasted to take roughly half a year. 
Spending only 6 hours a day at our desks.

That's the power of Continuous Improvement done right.

In the Post-Scrum Manifesto, I explain why active, continuous improvement is better than Retrospectives - and also, what you might be getting wrong about your Retrospectives at the moment.

Friday, February 4, 2022

SAFe Values - no real value!

Transparency, Built-in Quality, Alignment. Program Execution.
These are the four "SAFe Core Values." But - are they actually, "values?"

What are SAFe Values?

According to the official SAFe website, the SAFe Core Values are:
The four Core Values of alignment, built-in quality, transparency, and program execution represent the fundamental beliefs that are key to SAFe’s effectiveness. These guiding principles help dictate behavior and action for everyone who participates in a SAFe portfolio.
I would like to focus your attention to the highlighted terms:
  1. Fundamental beliefs: In order for "SAFe Values" to make any sense, you must buy into this belief system. If you don't share one or more of the underlying beliefs, the cookie crumbles and the "Value System" of SAFe becomes meaningless. Let's also mention that the idea of "fundamental beliefs" originates from religion - it doesn't coincide well with science.
  2. Guiding principles: What is a guiding principle? Let's examine the meaning of a principle: "a fundamental truth or proposition that serves as the foundation for a system of belief or behaviour or for a chain of reasoning." Here, we're pretty close to circular reasoning: SAFe Core Values are fundamental - because they are fundamental. A foundation isn't negotiable, because everything built on it collapses without that foundation. But - are these "fundamental truths" axiomatically true - or are they based on perspective?
  3. Dictate behaviour and action - "Dictate" is a much stronger term than, for example, "orient" or even "inform." Based on the fundamentals, you have only one course of action, and it's not open to negotiation or discussion: it's mandatory.
From a linguistic perspective, the SAFe values are beyond scrutiny and would be considered a totalitarian rule: You must believe them, and you must do what they say.

Fundamental beliefs dictating behaviours coincide neither with science - nor agility.

Without getting any further into this matter, let me first clarify that I have never, ever experienced a SAFe fanatic. I have seen my share in the Scrum community, but SAFe practitioners - by and large - tend to be very pragmatic. "Doing what makes sense" is high on the list, and hence, I would give both the idea of "fundamental" beliefs and the idea of "dictating" behaviour a break.

That's just half the matter, though.
The other half is - how these terms tend to be understood in a larger corporation.
Much of an enterprise system is built around the idea that transparency is a one-way street, alignment equals incorporating others' opinions, quality a matter of governance. "Program execution" - well, it requires setting up programmes. With a separation between coordination and execution.

Not-so-fundamental beliefs

A problem of SAFe's core values is that these very underlying beliefs aren't defined from an agile point of view - when a company introduces SAFe, they are taken as "fundamental." Management understands these terms in a certain way, and discussing a "fundamental truth" seems to be a waste of time, because - they're fundamental, and we already understand them. Hence, the crucial discussion, "What do these terms mean?" won't happen. Instead, the terms become a projection of status quo onto an agile organization.

If you start with these four key premises:
  1. Transparency: We require a chain of command giving clear orders, and we rely on detailed reports.
  2. Alignment: We must ask for the opinions of people not doing a specific piece work, and only do things they agreed to.
  3. Built-in Quality: We need some kind of governance telling people what their job is, and how to do it properly.
  4. Program Execution: We must set up large programmes which bind a lot of time, money and manpower.
... then congratulations: the core idea of "Agile" is already dead and buried.

Hence, we first need to discuss how we want to understand these terms before we can build an agile organization where these terms even make sense.

What's (a) Value

Unlike beliefs, values aren't "fundamental," "truths," or "principles."
Value, as defined in Oxford dictionary, is:
Value - how much something is worth in money or other goods for which it can be exchanged.
Note again, that there are two critical statements here: worth and exchange.
A value is about the "worth" of something, not a boolean attribute. 
When asking, "What's the value of this car?", you wouldn't expect "Yes" as an answer.

Value only exists when there is a metric and a conversion rate towards another entity, so that people can decide what kinds of trades they would make - and which they would not.

For example, let's assume we measure quality on a scale of 1-10, and you have a quality level of 5. That's merely a measurement: It's not a cross-referenced metric. If you want quality to have value, you would need to relate it to something else, such as "1 quality is worth 3 time."

The statement, "we must have all of built-in quality, alignment, transparency and program execution" would not define "core values." To have an actual value system, we must be able to make trades between quality, alignment, transparency and execution - and we must be able to determine which trade-offs are advantageous, and which aren't.

How much execution are you willing to invest into alignment instead? How much quality would you give for transparency?
These aren't values, unless you can answer those questions.

And for the record - if you'd answer, "None," then you have just discarded the value entirely.

You only have a "value" if you can trade for it.

Considering a SAFe value system

In order to turn "beliefs" into values, we need to be able to make trade-offs based on something. We need to state how much we are willing to give, in order to gain some of what we believe in.
The easiest way to make trade-offs is by investing more or less time or money.


makes a formidable value, since we can immediately relate it to money: We can determine the cost of poor quality (i.e., the failure to produce high quality) based on projected cost of failure and/or rework. This cost is so staggeringly high that quality has an extremely high value, and the price of reducing it is extremely high. Although the numbers for reducing quality rarely add up, we can do it, and clearly quantify cost, benefit, exchange rate and margins.


converts formidably to time - we could do something now, and show the outcomes. Or we could first align, which would mean that we will have no results until alignment is done. It also means that we're not earning money in the meantime. Plus, we're spending effort. Hence, we can assign a financial cost to alignment.
When we can say how many days an improvement / reduction of 1 point on our alignment scale will gain or cost, and how much money we gain / lose during that time, then alignment might become a value.


is very hard to turn into a value, because it's extremely hard to define.
What is transparency even - and how would the gain or loss of one point on our transparency scale convert into time or money? We could measure the cost of information inavailability, which in itself is only visible via second-degree indirection - we must peek at the delays incurred by waiting for information to become available, and at the cost of that time. We could also measure the cost of evitable, wrong decisions that were made because people made choices in the absence of existing information. We then also need to reverse the calculation, computing the cost and time required for producing information not required for decision-making ("information waste").
Companies capturing this kind of data are so rare that the measurement of transparency remains elusive.


simply doesn't make sense as a "value." How much time or money is one unit of "not doing anything" worth? How many would we want? Is there ever even a potentially valid scenario where having a plan, and not acting upon it, has a positive value attached? If so - we should immediately ditch that plan! 
And that's not even digging into the question whethere there's value in a "program," that is, a large-scale initiative. Skunkworks has already shown two generations ago that programmes are often more of a problem than a solution.

SAFe Core Values - a wishlist for Santa!

When we're talking about "SAFe Core Values", we're not talking about values at all, since we're not even discussing potential trade-offs.

Quality is the only "value" of SAFe that managers would actually consider trading off, despite being so ridiculously expensive that this isn't economical: The best quality has the lowest cost - "less costs more and brings less." It's absolutely something an economical thinker would want to maximize.

Alignment, as commonly understood, comes with a negative net benefit - "more costs more and brings less." So, it's not something of value. Why would we want it, besides clinging to a belief that it's somehow important?

Transparency is too elusive to be considered a value: Everyone wants it, but nobody can really say what, or how much, we'd want to trade for it.

Program Execution doesn't make sense as a value. It's boolean: If we want to do something, just do it. If we don't want to do it - why is it relevant?

Hence, SAFe's "core values" are nothing more than a wishlist for Santa - something that almost every manager in the world will say they want, and nothing they'd be willing to pay a price for. 

Anything for which you're unwilling to pay a price, has no value. It therefore can't be considered a value.

SAFe has only one real value: built-in quality. And that's the first ones most organizations kick out of the window.

If you want SAFe "Values", you'll need to do a lot of groundwork and figure out what it is that you actually want: You're not done with simply accepting them.

Wednesday, January 19, 2022

Team archetypes: basic setups

 "Which kind of team setup should we choose?" - a common question in many organizations with the luxury of having an IT department bigger than a single team. First of all: there's no universal best answer - the choice is often constrained by factors outside the teams' control - such as HR, legal,  company politics and so on. Irrespective of such details, let's explore what the archetypes are.

As long as there are only enough people for a single team, the question "which setup do we choose?" is - fortunately - moot: build a team and get to work. Approaches like Skunkworks, which predate software development, conclude that a single team is always less overhead than multiple teams, and the overhead can become a performance killer - down to the point where a single, effective team can outperform half a dozen teams struggling to get their act together.

This entire article is written under the premise that a single team isn't enough to get the job done, and that we already exhausted all feasible options of doing the same with fewer people - hence: there is an indisputable need to set up a multi-team structure.

Four Team Archetypes

Let's take a look at the team setup chart. For simplicity's sake, let's just assume that the only functional specializations are Analysis, Coding and Testing. The key points of the article don't change if we have further specializations, such as Frontend/Backend/Database development or include Operations. If anything, the problems caused by specialization would be exacerbated.

Component Teams

One of the most common setups for organizations with just a handful of teams is the Component Team: each team consists of the people required to deliver a single component. This works splendidly as long as there are only few components, and they are loosely coupled. In that case, each team can perform their work independently. It becomes an entirely different ballgame when components are tightly coupled, interdependent - or worse: co-dependent.

Key questions to ask when setting up component teams include:
  • Will each team have all the skills and means to complete the delivery lifecycle of their component? If the answer is "No," component teams will quickly find themselves blocked and unable to consistently deliver value. Proceed only if the answer is "Yes."
  • How close is the coupling between each component? If the answer is, "Tight", component teams will likely find themselves rendered ineffective. Proceed only if the answer is, "Very loose."
  • How dependent are the components on each other in delivering end user value? If the answer is anywhere on the scale from "Master-Slave" to "Closely interlinked", at least one component team will be a bottleneck, and overall delivery performance will depend on the constraining team.

Specialist Teams

The staple setup in corporations with hundreds, potentially thousands of IT people is the Specialist team: each team consists of specialists performing a single function in the software development lifecycle. In case of very large organizations, we often see a double specialization - each component having their own specialist teams performing only a single type of task. 
This kind of "industrialized, conveyor-belt delivery" process optimizes resource efficiency over effectiveness, and typically ends up with massive bottlenecks diminishing flow efficiency of value delivery close to Zero: Regardless of how many people are involved, "there are always too few people." The problem is less the amount of work than the immanent optimization favoring workload over results.

Key questions to ask when setting up specialist teams include:
  • Where will the bottlenecks be? You will have at least one bottleneck, and if it's not where you want it to be, you won't understand why your organization is so ineffective.
  • How do we keep flow across teams balanced? Managing flow in specialist teams requires understanding the intake, throughput and flowback rates of every single team. If these are out of balance across teams, work will get stuck.
  • How will people communicate? The classic Waterfall-style "communication by document" is slow, inefficient, ineffective and error-prone. Proceed only when you have a feasible solution for communication flow.

Feature Teams

The key reason for feature teams is to reduce the cross-team friction caused by delivering unusable component work which requires integration efforts at a later point in time. Feature teams minimize the handovers across team boundaries which lead to additional communication and waiting queues. 

Neither component nor skill boundaries will stop the flow of work from demand to delivery in a feature team. The way of working in feature teams is very natural - people sit together, do whatever it takes, and get the job done.

Key questions to ask when setting up feature teams include:
  • Which organizational impediments prevent us from setting up feature teams, and how do we overcome them? The barriers are often more centered around management, structure and contracts, not at shop floor level.
  • How do we keep team size low and still make sure people know what they're doing? Feature teams require a lot of initial learning as every team member is confronted with a vast amount of things they don't know.
  • Which engineering practices will we use to ensure that teams won't constantly step on each others' toes? If you have no solutions, you need to find these before proceeding.

Generalist Teams

The generalist team is often considered the holy grail of Agilists. A generalist team is multi-skilled both in software engineering, and in the product domain: each team consists of individuals who can exercise multiple functions in the development lifecycle, and who are able to work on all relevant components of their product. Generalists hardly find themselves in bottleneck situations, and are always able to contribute value. Setting up generalist teams has a massive learning curve, requiring continuous multi-learning. In return, generalist teams minimize the concern of "truck count," and they are able to flexibly take on any feature that maximizes value.

Key questions to ask when setting up feature teams include:
  • Where are currently our knowledge constraints? Generalist teams immediately expose where the number of individuals with either product domain expertise or specific lifecycle expertise are too rare to ensure each team has seed knowledge to get started.
  • How much specialization is really required? If you're working on teams where lacking deep domain knowledge becomes a life-or-death decision, generalization may not be your primary choice. These cases are rarer than we would think. Based on the Pareto Principle, 80% of the work requires 20% of the knowledge - and generalists can do that.
  • What does it take to set up generalist teams? How do we get started? Can we start right away, should we upskill feature teams or component teams? Do we need to re-organize entirely?
The most common concern towards setting up generalist teams is, "Not everyone can do everything." Indeed. It takes time and learning, and not everyone will specialize deeply in everything. There are two key points to ponder: the starting point, and the optimum point. 
At the starting point, we set out with people who may find themselves unable to contribute outside their specialization, and based on where the team's constraint is, that's what they need to learn first.
At the optimum point, team members can offer basic contribution wherever it is needed - and "wherever" isn't "everywhere." A generalist team is effective when there are no skill-related bottlenecks in the team, not when everyone is a master of everything. It could mean that a tester understands some basics of coding and can make simple changes by themselves - not that they need to establish profound coding expertise. 

What's the difference between generalist and feature teams?

Feature teams are a lower standard. We can easily set up a feature by putting an analyst, a developer and a tester into one team and giving them access to all the modules they need to work with.

Generalist teams should be feature teams. Only some feature teams are - or evolve into - generalist teams.

A generalist team consists of coders who can analyze or test, testers who can analyze and maybe write some code, and analysts who can also code or test. People who worked in smaller companies are often used to this way of working - people from a corporate environment are often unable to even grasp this concept as it's too detached from their reality.

How about Generalist Component teams?

Small teams of people, each of whom can do most of the work on their own components. This pattern is very typical in modern organizations opting for microservice architectures.

Dissolving specialization boundaries within teams is desirable to increase "truck count," and definitely useful. We minimize delays, handovers and information gaps within the team. On the other hand, the effectiveness of the overall development organization remains constrained by the lowest performing component team. Component team organizations can't solve this fundamental flow impediment, hence the teams' generalization ends up being a local optimization.

We can even find this local optimization working against us - the highest performing teams might create overload on other teams, further reducing the overall performance of the organization. High-performance generalist component teams might render the entire organization ineffective, despite best intentions.

What to choose?

In other articles on the topic of team archetypes, we will explore a little further what the implications of each archetype are. The topic is complex, hence there is no simple answer. The best answer is: "Caveat emptor." Know what you're opting for and what the consequences of your choices are.

What about Mix-And-Match?

Should every team within an organization have the same setup? Wouldn't it be better to mix-and-match? A few component teams doing bulk haulage, supported by a few specialist teams for Feature Analysis and End-to-End testing, maybe with a Task Force Feature Team for high urgency tasks? 

That's actually what we find in many organizations, so it's definitely a realistic scenario. Our question is less about "Can we do that?" than it's about, "Should we do that?" - and again: there's no simple answer. As a product matures and growth reaches a plateau, that's most likely what we're going to find. For emerging products, the suggested mixed setup is probably not going to provide the necessary performance to succeed. 

Where to start?

Try starting with the simplest setup, and only add complexity when inevitable.

And that simplest possible setup is a small number of Generalist teams. If you can, try that first.

Wednesday, January 12, 2022

The economy of incentives

People working in bigger companies often do things which don't really seem to make sense when looking at the big picture. And yet, they're often pretty reasonable in their choices. They are intuitively following basic psychological and economical principles. Let's explore.

The economy of needs, wants and incentives

Let's start out at the detail level of the individual. Each person has needs:

The need pyramid

Maslow's hierarchies of Needs, sometimes also called "Maslow's pyramid" is built on the theory that every human being has needs, and these needs follow a hierarchical order. This picture is already a simplification, more comprehensive models are abundant on the Internet. 
While each person has the same types of needs and the pyramid is the same, the level at which these needs are considered "satisfied" widely differ. 
One person might feel basically satisfied with a bowl of rice and a few cups of water, whereas another person requires a more special diet to  sustain. These are the basic needs, which must be met to ensure survival. People whose basic needs aren't met will not have a mind to think about other things, their primary concern will always be meeting these needs.
Once people are satisfied at the basis, they care for psychological needs - family, social ties, being accepted and valued.
With such a firm foundation starts the restless search for meaning in life - developing one's personality,  being creative, pursuing a cause. At this level, people look for transcendency.
Dan Pink mentions this in his book, "Drive" - without fully realizing that it's not just that the money must be off the table, but all basic and psychological needs. People who feel threatened for their physiological well-being or social status aren't looking for transcendence, so in order to set up an organization where people go to look for a higher purpose, there's a lot of groundwork to be done in taking care of people first.

From "Need" to "Want"

Unmet needs cause dissatisfaction with the status quo. This is also true for the future, because people think ahead.
We build our needs pyramid from the bottom, and whenever a lower-levelled needs turns to an unmet status, everything on top of that need gets out of focus. A starving person doesn't care for appreciation (many artists can tell that story.) A bullied person won't feel the office aesthetics. And so on. So, when a person has an unmet need, they want something, and action is required to satisfy the need (although it could be a different actor to serve the person in need.)
There are a lot of intermediary Wants - for example, money can be used to meet all kinds of need. When a person is hungry, they want money to buy food. Or drink. Or to pay the rent. Once basic needs are satisfied, they might invest that money to buy a token of wealth that meets their need for social recognition. And so on.
Other intermediary Wants, such as a promotion, could be more complex: Is it about the job title for prestige, is it about the presumed job security, about the additional pay, is it to rise the ranks to improve status? Maybe all - maybe only some. 
Or maybe the idea that the Want satisfies the need is an illusion?

The key takeaway here is - if there's a need, there is a want. Ignoring the underlying need will render attempts to satisfying a Want ineffective.


Incentives don't directly affect needs. They work because they trigger (both positive and negative) wants: things the individual wants, in order to meet needs - and things the individual wants to avoid, in order to not have needs unmet.
An incentive always stimulates at least one Want. 

Positive incentives

Positive incentives give people the ability to satisfy their needs if they conduct a certain action. The most common form of positive incentive is, "Do your job, get your paycheck." Even a simple "thumbs up" from a coworker can be an incentive to try and go the extra mile. 
The strength of an incentive depends much less on the nominal amount of incentivization - much rather, it depends on the level of unmet need. For example, you won't entice Donald Trump with a Thumbs Up, but the new team member who's not certain of their position in the team yet may be willing to go great lengths to finally get the lead developer to nod in agreement of something.

Negative incentives

Just like positive incentives, we can find ourselves subject to negative incentives.  For example, the negative incentive "skip dinner"  attached to overtime plays on our Want to not be hungry.
In society, we use negative incentives to deter certain behaviours, such as fines (which affect people differently, depending on their wealth.) 
Explicitly phrasing negative incentives helps people discover which courses of actions are desirable and which are undesirable.
Managers quickly forget that there are almost always some negative incentives attached to their words: Even asking for a trivial thing might leads to the person feeling their status in front of their peers is diminished - a negative incentive, which people try to avoid.

The incentive economy

An economy is defined by wealth - in this case, we define "wealth" as satisfied needs.
In the case of incentives, we're dealing with promises of future wealth, hence, a value proposition to the recipient of the incentive.

Passive incentives

"What could be a passive incentive?" - well, that's an incentive created by doing nothing. Taking an extreme example, when a police officer continues munching donuts while a robber demands cash from the store owner, that's an incentive for the robber to commit further crimes. We see much less extreme examples in everyday's business world as managers fail to acknowledge the successes and contribution of their teams, incentivizing individuals to either cut down on performance (if stress is affecting their basic needs) - or to start hunting for a better job.

The nefarious thing about passive incentives is that you literally don't need to do anything to trigger them.

Ineffective incentives

The next type of incentives we're looking at are ineffective incentives. A positive incentive which doesn't address a real Want is entirely ineffective - as are negative incentives which don't touch a relevant need. This is also the reason why a pay raise for a person who's already fully able to meet their basic and psychological needs is pretty ineffective, as Dan Pink in his work, "Drive" figured out.
The same is true for "fun activity at work" while people are worried about not being able to afford the rent: it affects a higher-levelled need while there are lower-levelled Wants.
We can try to manipulate people by suggesting that they do have a certain Want, a typical marketing strategy. Here we can quote Lincoln, "you can fool some of the people all of the time, and all of the people some of the time, but you can't fool all of the people all of the time." Eventually, people will realize that an incentive doesn't affect their needs, and they will ignore it. That is especially true for  things often called "non-monetary incentives."
Likewise, when a person finds alternative ways of satisfying their Needs, the Want disappears, and the incentive fizzles. For example, new joiners will stop trying to achieve the recognition of their boss when they feel that the recognition of their peers means a lot more. 

Hence, long-term incentives that have alternatives tend to be ineffective. 

Perverse incentives

The final category of incentives are perverse incentives - these are different from the other categories.
When we try to incentivize an action, we usually try to do that to get a benefit from what they do. The term, "perverse incentive" comes into play when people have the Want, but the intended incentivized action isn't actually what people to in order to meet their need, and so they go to do undesirable things. "Cobra Farming" is a notorious example of a perverse incentive.
The problem with perverse incentives is that they work extremely well - just not in the way that the incentive-giver intended. 
And there's another problem: Perverse incentives are extremely common in complex organizations where the relationship between cause and effect isn't clear.

Setting incentives without connecting to the recipient's reality often leads to perverted incentives.  
Top managers coming up with broad-brushed incentivization schemes for people at shop floor level often realize this only when it's already too late.


Bringing it all together - we have to understand the real needs and how they can be met. We must learn to go beyond merely talking about our Wants.
From there, we must learn how to take care of each other's needs in effective ways.

That allows us to become explicit on the incentives that let us build "Win-Win" scenarios.