Sunday, April 07, 2019

Simple Simulator: T-Shaped vs. I-Shaped Developers

Imagine that you are a manager charged with staffing a new development team. You have important choices to make: What kind of developers do you want? Specialists? Generalists who can do a bit of everything? A mix? Is it worth it to pay more for developers who are a bit more skilled?

Division of Labor vs. T-Shaped People

Most companies I've seen over the years focus on cost. When it comes to developers, that means the default behavior is to get the cheapest ones. That means neither depth of skill, nor range of skills makes much difference. For a developer, having a wide range of skills can even be a detriment, because managers do not know which narrowly defined role to put the developer in.

On the other hand, anyone who has even a passing familiarity with Lean, and know a little bit about agile beyond Scrum, has probably come into contact with the concept of T-shaped people.

Most companies develop and organize people according to the Division of Labor principle, the idea that you can increase efficiency by separating tasks into narrow specialities, so that workers can also specialize. This is an important idea. Without it, we would have no industrial revolution, and our world would look very, very different.

The problem is that while the Division of Labour principle works, it can be pushed too far. If the work requires understanding context, if it requires choosing an optimal solution from a wide range of possibilities, if every solution creates new short, if it is work like software development work, or management, then Division of Labour can cause as many problems it solves.

Nobody can learn to do everything, so we should not, and cannot, abolish the Division of Labour principle altogether. What we often need to do, is to shift the balance a bit.

That is where T-shaped people come in. The idea is simple: Train people in more than one speciality, so that they can work with more than one process step. This allows a team to shift more people to the current bottleneck in a process. It also gives each person a better understanding of the context of their own work, and the consequences of the choices they make.

The Simulator

I recently created a very simple simulator in a spreadsheet to illustrate the effects of narrowing down developer skills too much.

In software development, including agile software development, it is very common to have teams of developers divided into two main groups: front-end developers, and back-end developers.

Other teams consist of full-stack developers, individuals who know both front- and back-end development. Of course, being a full-stack developer requires a passion for the work, and also a significant investment in training. Full-stack developers are a good example of T-shaped people: People with a growth mindset, trained to do more than one thing, and usually not afraid to tackle new types of tasks.

Many companies balk at paying for training full-stack developers. The added costs are obvious, but the benefits are a bit more abstract.

The simulator is designed to make the differences between having specialized developers and full-stack developers a bit more visible.

Simulation: Differences in performance between T-shaped and I-shaped developers
The picture above shows a run from the simulator. The thick gray line shows the productivity of a team consisting of full-stack developers. The thick yellow line shows the productivity of a team that is identical, except that the developers are divided into front- and back-end developers.

The productivity is measured in stories per sprint, not story-points per sprint. Each story requires both front-end and back-end development.

The two thin dotted lines represent the productivity of the front- and back-end developers. Both team simulations use these numbers to calculate the productivity of the whole team, but they do it a little bit differently:

For the full-stack development team, since all developers can do everything, the numbers are just added together.

For the front/back-end developer team, a story is not finished unless both groups of developers have the capacity to work on it in a sprint. Thus, the total capacity of the team in a sprint, is the lower of the capacities of the two groups, multiplied by two. Thus, if the front-end team can work on four stories, and the back end team can work on three stories, the total capacity is calculated as 3x2=6 stories.

In the initial run, both front- and back-end developer groups can produce 1-10 stories per sprint. The actual capacity is generated by a random number generator. If you have ever measured team productivity, you will know already that in real life, productivity can vary a lot more than this from sprint to sprint.

It is obvious that the full-stack development team is consistently faster than the front/back-end team, but what does that difference mean? Are full-stack developers worth the investment or not?

The simulator calculates the average velocity of the two teams. It also calculates the standard deviation for each velocity graph, and the difference in efficiency between the two average velocities.

Of course, the results will vary from run to run, but I've found that with this initial setup, a difference of about 30% is about normal.

What this means is that if you have to spend 30% more to hire and/or train full-stack developers, it can still be a good investment.

In other words, if it requires one day per week to develop and maintain the skills of full-stack developers, the company is likely to come out ahead financially.

This, of course, is when front- and back-end capacity is, on average, perfectly balanced. What happens if we double the capacity of one of the groups, for example the front-end developers? Well increase the capacity of the full-stack team with the same amount. For example, if the teams had four developers each, we would increase team size to six developers.

Looks like the difference in capacity between the two teams increased. What is going on?

The average velocity of both teams went up, but the velocity of the full-stack team increased more. The difference in efficiency increased, which means the team with front/back-end developers is getting less value per developer.

This makes adding more developers to a team a dicey way to increase productivity, especially since process bottlenecks move around a lot due to the inherent variation in the work. No matter which kind of specialist you add, it will be the wrong kind of specialist a significant portion of the time.

A simple simulation like this is highly useful as an aid to thinking things through, it is by no means a substitute for thinking.

For example, there are an infinite amount of different factors that can affect the productivity of a team. Won't that make the simulation invalid? No.

First, many of those random factors will affect both teams equally. That means the velocity displacement will be equal for both teams, which means the difference in velocity between the teams will remain the same.

Other factors will have quite different effects on the teams. For example, assume that each team has four developers. The front/back-end team has two front-end developers and two back-end developers. If one developer falls ill, the full-stack team has lost 25% of capacity. Thefront/back-end team has lost 50%, because it now has a narrow process bottleneck.

Overall, the full-stack team is a lot more robust. Not accounting for that in the simulation, actually biases the simulation in favor of the front/back-end team. 

This means the full-stack team is easily more productive even though the simulation is actually biased against it.

What about the standard deviation bars? Do they have anything significant to add to the story? Yes, but I am saving that for another blog post.

Wednesday, October 18, 2017

Why HR Can't Hire Pilots

I wrote a rather lengthy article about serious flaws in the recruitment processes used by most companies on Linkedin. The article is named Why HR Can't Hire Pilots.

Before I published it, I asked a few people, HR people and managers to read it and provide feedback. Despite the article being rather controversial in its conclusions, they liked it.

Tuesday, March 22, 2016

Five Scrummaster Toolbox Podcasts

The nice people who do the Oikosify Scrummaster Toolbox podcasts, asked me to tell you that they, very sensibly, I think, have split their interview with me into smaller parts. (When I get going on a topic I am interested in, well...let's just say we had a long talk.)

So, if you care for your sanity, I recommend you listen to their other podcasts.

If you think sanity is overrated, or if it is just too late for you, here are the ones where Vasco Duarte interviewed me:

Tonight, when things have quieted down, I will listen to a few of their more recent podcasts. They've got material there I am very interested in. :-)

Friday, March 18, 2016

The question nobody dares to ask about strategy

Picture by Henrik Mårtensson

I originally published this article at Linkedin Pulse:

When I transitioned from my work as a developer and systems architect into working with leadership, strategy, organization, and process improvement, I had a lot to learn. Naturally, I read a lot, I joined interest groups, and I asked questions. I soon discovered that there were some questions that, though very important, were never asked.

The reason for not asking important questions is usually embarrassment. If I know I am supposed to know something, but I don't, then it is embarrassing to ask. Short term, it is often easier to hide the lack of knowledge.

The downside, of course, is that if one does not ask, one does not learn. If nobody asks, nobody learns, but everyone believes everybody else knows…
This can create a downwards spiral, where nobody knows anything about something, but everybody is to busy hiding their lack of knowledge to notice.

I found that in business, strategy is one of those somethings. I found that nobody dared to ask a very fundamental question about strategy. I also found that the lack of an answer caused confusion, lack of direction, lack of cohesion, cost a lot of money, caused poor working conditions, stress, unnecessary layoffs… I could go on, but you get the gist of it.

What was the question? A very simple one really:

What is strategy?
When I got interested in business strategy, I found business books about the topic confusing. Terminology was defined in rather loose terms. The definitions did not help me in any practical way. There were many different definitions. Some authors even dismissed strategy as a useless waste of time.

I found this difficult to understand. Strategy is important in Game Theory (which deals with business problems, among other things), it is important in Chess, a military organization cannot survive a war without strategy, in ecosystems, animals and plants have survival strategies. Why would business, which is obviously a strategic, competitive game, be any different?

Strategy is the answer to a Question!

I did find one business definition of strategy that worked for me. It is from the Theory Of Constraints:
Strategy is the answer to the question "What for?" 
Tactics is the answer to the question "How to?"
In other words, a strategy is a structure consisting of an ultimate goal, and a set of intermediate objectives that, if achieved, will lead to achieving the goal.

The definition also made it clear that for each goal or intermediate objective, there must be at least one corresponding tactic.

Viewed through the lens of that definition, strategy and tactics in a business context made a lot more sense than it had before. The definition works for all strategic games, not just business. It also clearly separates strategy and tactics. Most other definitions tend to muddle them, and get lost in fuzzy lines of reasoning about different scale and scope.

Confusing Strategy & Tactics

Unfortunately, while strategy and tactics as useful concepts started to make sense, the business strategy documents I read made correspondingly less sense.

For one thing, I found that most of the strategy documents I read weren't strategy documents at all. They were filled with material on how to do things, with zero information on why these things had to be done in the first place.

Many strategy documents were actually tactical documents, masquerading as strategy documents. When I found tactics in strategy documents, I used to go looking for actual strategy, but most of the time, there simply was no strategy to be found, just a random collection of things to do, with little cohesion, or even working against each other.

The Emperor's New Clothes

Other "strategy" documents were hilariously obfuscated. Some were obfuscated so well that neither I, nor anyone else, know what is actually in them.

One company I had worked for had got "help" developing a strategy from a rather large consultancy. When I had a look at strategy documents from the consultancy, I found them difficult to read. Suspiciously difficult! So, I ran their documents through a readibility calculator, and found that the language was so complex you needed a doctor's degree in English to figure out what the content was.

Nobody could read and understand the darn things, and everybody was too embarrassed to say anything about it.

What's the use of having a strategy nobody can read and understand? Apart from confusing competitors, not much.

Keep it Simple!

Personally, I like to express strategies as diagrams, instead of with text only. Diagrams make it easier to build a coherent, and easy to understand, overview.

My favorite method, The Logical Thinking Process, (yes, I know the name is cringeworthy,) is pretty good. I get the overview, and it is also easy to dig down into more detail when necessary. There are plenty of other useful methods around, but one has to do a bit of research to find them.

A Game of Interaction and Isolation

It is useful to have more than one perspective, so I did not stop with the Theory Of constraints view of strategy. I found very useful material in a military strategic framework, Maneuver Conflict, by Col. John Boyd:

Strategy is a game of interaction and isolation!
How is that useful? Well, if you know that you want to strengthen interactions between yourself and your allies (including customers), and isolate your enemies from each other, then you can check if that is what you are doing.

I found that remarkably often, it isn't. Companies use organizational structures explicitly designed to reduce the interactions of its employees, often because they reuse old organizational designs, without knowing the original purpose.

Conversely, companies do a lot of stuff that separates them from their customers, and drives the customers into the arms of competitors. For example, I can no longer make a phone call to my bank without giving them a password, over the phone, before I even get to talk to somebody. If I were not already a customer, I would not be able to call them at all.

Strategic principles

In addition to having a clear definition of strategy, it helps to have a set of basic principles of strategy. I mean really basic, so basic that they are relevant to any game of strategy. That is something Maneuver Conflict provides, but business strategy frameworks rarely do.

36 Stratagems

Speaking of principles, I have found old Chinese texts, like The Art of War, and 36 Stratagems, to be very useful. They provide insight, and they can be used as idea generators. No wonder that Chinese business people study them.

I'll do a follow up article about 36 Stratagems soon. There are stories to tell. :-)

Note: The 36 Stratagems article will take awhile. Might even end up becoming a book, so please don't hold your breath waiting for it.

Sunday, December 06, 2015

Review: Exploring the Practice of Antifragility

I wrote a review on Amazon for Exploring the Practice of Antifragility.

I am republishing it here:

First disclosure: As of the 5th of December 2015, I am a contributor to this book! I do not have a financial stake in it, but I do wish the book to succeed, because I believe the idea of antifragility to be important. I won't review my own contribution, of course, but stick to the things I have read by the other contributors.
Second, Exploring the Practice of Antifragility is itself antifragile! The book is a Kindle ebook, and like all Kindle books, it can be updated with new material from time to time. This means the book itself can evolve according to pressure from the environment, i.e. reviews and sales data can actually make this book better over time.
Thus, if you buy the book, think of a way to improve it, and write about it in a review, your wish might come true. While this is possible to do with all Kindle ebooks, I do not think too many of them make good use of it. When Si Alhir, one of the editors, told me about the book having planned updates when he invited me to participate, I found this to be a very attractive feature.
Third, the book also features another very important property of antifragile systems: Variation!
The book is an anthology, with essays written by very different people, who have very different backgrounds, and who do very different things. This means you won't be interested in everything, but, if you are interested in antifragility, there will almost certainly be something in it that you find very interesting.
Fourth, the book was practically useful to me! Two years ago I began building an antifragile organization. We are now more than 350 people. One of my book projects is a book about the organization, and I have struggled with explaining, in a simple way, the difference between the antifragile organization, and fragile organizations in the same domain.
Todd Nilson solved the problem for me, writing about Nicholas Taleb's triad schema. It was exactly what I needed. I can borrow the idea, adapt it for my own book, and it will work beautifully.
Si Alhir made the connection between antifragility and the OODA decision loop from John Boyd's Maneuver Conflict, which I find interesting, because the antifragile organization I am deeply involved in, directly uses many ideas from Boyd.
Again, Boyd's ideas are echoed in Todd Nilson's: "…the purpose of the community trumps all else."
I also enjoyed reading Elinor Slomba's piece about sustainability, connectivity, and diversity, and how to use simple free tools to collaborate over the Internet.
Valuable ideas I can use in my own work. Highly useful.
Also, Slomba's ideas about cascades the properties of aggregated and distributed systems are practically useful to me. I recently released a book about reducing lead times in the book publishing business. The method I wrote about, and use to write my own books, applies the same ideas. Slomba has given me a slightly different perspective, which will help me express the ideas in a simpler manner in my own books.

So, I give this book five stars, because it actively uses the ideas it proposes, because it will get better over time, and because it was practically useful to me immediately when I read it.

Wednesday, December 02, 2015

The season of the jolly speedwriter!

Bokomslag Skriv och sälj! (e-bok)

I've been speedwriting again! This time about how to write and publish a book very fast:  Skriv och sälj!: Skriv och sälj en bok på 14 dagar (Write and Sell!: Write and sell a book in 14 days) is out on AdlibrisBokus, Dito, and Bokon.

Actually, speedwriting is a misnomer. I am, have always been, and always will be, a slow writer. The idea with Write and sell! is to reduce queue and wait times in a book production process, the same way we can reduce it in software development processes (Agile), in product development (Lean Product Development), and in manufacturing (Lean, TOC).

I am digging down to the queueing theory with this one, and going with it all the way to what to do, and how to do it.

Writing and publishing the book took only nine days. I had planned to do it in 14 days, but the gods of time buffering were on my side this time around.
Writing and publishing the book took only nine days. The reason why the lead time was so short, is that I utilized Little's Law:

t = I/T


t is the lead time
T is the production rate
I is the average number of items in queue

I managed to stir up a bit of controversy in two writer's communities on Facebook when I published the book.

People are assuming that I worked my butt off to produce faster, i.e. increase T in the equation, and that they would have to kill themselves trying to achieve the same productivity.

Of course, I am much lazier than that! I chose to reduce I instead.

How did I do that? Well, one way is to write shorter books, but as it turns out, you do not have to. You can use load balancing instead!

That is right, the magic stems from applying heijunka to the authoring/publishing process. Heijunka has been around since at least 1948. All I did was to apply it in a new context.

I did a bit more than that. I took three other equations from queueing theory, network science, and TOC (specifically from Throughput Accounting), and worked out how to apply them too. If you are interested, well, it's in the book. (Badger me if you are really, really interested in an English translation. The main reason I am not translating the book is sales. Right now it is easier for me to build book sales in Sweden. Sigh!...That's in the book too.)

Now, instead of trying to push people to learn, I intend to work with those who are curious and willing to try something new, and with those who are interested because they already know. Part of that tactic was to create a Facebook group for those interested in reduce writing and publishing lead time.

We'll see what comes of it. There is certainly more "speedwriting" ahead.

I haven't figured out what to call it yet, since it is not really about speed. I am pretty sure the original, Japanese terminology will not fly with writers. No, I need something else...

Smartwriting, anyone?

Saturday, November 28, 2015

Tempo! is available at Bokus, Bokon, and Adlibris

Bokomslag Tempo! : Praktisk strategi, organisation och ledarskap i en kaotisk tid (häftad)
Click the picture to buy Tempo! from Bokus.

Tempo! has finally got distribution in Sweden! The printed version of the book is now available on Bokus, and Adlibris.

In addition, companies hiring me for consulting work, can buy Tempo! from a special web shop, at a considerably reduced price.

When I wrote Tempo! my intent was to write a practically useful business strategy book in Swedish. I did not want to tell other people what to do with their businesses, that is for them to decide, but I wanted to help out with how to do whatever it is they want to achieve.

I had seen too many companies where good, smart people just ran into a brick wall when they tried to make things better, not just for themselves, but for everyone in the organization, and for their customers.

Tempo! is illustrated with more than 100 diagrams and photos
Originally, I wanted to write a book about a practical method for developing strategy. I felt there was a lot of need, because I have seen many companies where strategy and tactics are confused, and where the relationship between strategy, tactics, and organization are ignored.

This can lead to a world of hurt when the organization tries to do things it is not designed to do, or when it tries to do two or more contradictory things simultaneously.

Another thing I wanted to provide was a means of clear, unambigious communication. Far to often I have heard people say "We want to work towards the company goals, but we don't know what the heck they are!"

So, what do you get with Tempo!? Basically three things:

  • The basics that every manager, and preferably everyone, in your company needs to know about how people work, how processes work, and how your organization works. Expect some surprises here.
  • A strategic framework, Strategic Navigation, that is basically a civilian adaptation of John Boyd's military Maneuver Conflict framework.
  • All the methods and tools you need to make it work. 
    • Crawford Slip lets you gather and organize information from large groups of people very quickly
    • TLTP, The Logical Thinking Process, lets you find root causes of problems, find solutions, and then build the project plans you need to fix them.
    • Process Behavior Charts, a tool that helps you make sense of otherwise very difficult to interpret data in reports.

The material has been thoroughly researched, used in practice, and proofread by some of the best management experts around, including Bill Dettmer, Chet Richards, Don Reinertsen, and many, many others.

Now, with a much better distribution network than before, I do hope more people will find Tempo! useful.

If you read the book, feel free to drop me a note, and tell me what you think of it, if you found it useful, and if you have any suggestions for improvements.