Tuesday, July 07, 2020

SAFe: Synchronization vs. Decoupling in PI Planning

Recently, I put my foot in my mouth while tweeting. This turned out to be a good thing, not only because it was an amazing feat of dexterity considering my age and body mass, but also because it lead to an interesting conversation, and thus, an opportunity to think things through, and to learn.

I won’t recapitulate the whole conversation in this blog post, because you can easily look it up on Twitter. I’ll provide the tweet that kicked the discussion off though, and give you the gist of the conversation. I have invited everyone who was involved to read and review this blog post, so if I screw anything up, they can jump in and unscrew it again.

It started with me tweeting:

That started up a conversation with Henrik Berglund and Beatric During. It did not take many tweets until I wrote:

“There are plenty of things where SAFe has a very shallow implementation of important ideas. For example, they borrowed the idea of PI planning from Reinertsen, but ignored the limitations he pointed out.”

Beatric During immediately spotted something a bit off, namely the statement “they borrowed the idea of PI planning from Reinertsen, but ignored the limitations he pointed out”. I slipped up bigly there, because that was not a statement I could back up with facts.

A couple of years earlier, I had noticed similarities between a part of Donald Reinertsen’s excellent book The Principles of Product Development Flow: Second Generation Lean Product Development and the SAFe practice of PI Planning. That, and the fact that SAFe borrows several other ideas from Reinertsen’s book, had lead me to form a hypothesis that the idea of PI Planning was also derived from what Reinertsen writes in Flow.

Just to be perfectly clear: I really like Flow. Borrowing from it is a very good thing to do. The purpose of writing a book like this, is to spread knowledge around, so lots of people can use it.

I have used ideas from that book to help clients, and it has worked out great. I wish more people would read it, and use it.

The mistake I made was not forming the hypothesis. The mistake was presenting it as if it was a fact.

Eric Schön asked me to be more specific, so I tweeted the numbers of the specific sections I was referring to:

On the off chance that you haven’t memorized all the section titles in the book, I’ll provide them here:

  • F11: The Principle of Multiproject Synchronization: Exploit scale economies by synchronizing work from multiple projects.
  • F12: The Principle of Cross-Functional Synchronization: Use synchronized events to facilitate cross function trade-offs.
  • F13: The Synchronization Queueing Principle: To reduce queues, synchronize the batch size and timing of adjacent processes

Section F11 uses project reviews as an example of how you can increase the frequency of project reviews by reviewing multiple projects at the same time. In SAFe, this is done through biweekly System Demos, and, every three months, through a PI System Demo.

Section F12 uses reviews as an example of an activity that can benefit from synchronization between functional departments.  If you have functional teams, working on functional requirements, you would get the same kind of advantages as Reinertsen describes for departments. SAFe uses (usually) weekly Scrum of Scrum meetings, and during PI Planning, a Management Review and Problem-solving meeting to resolve dependencies and make cross-function trade-offs.

Note that I used the word “functional” several times in the previous paragraph, because I will get back to that later.

In section F13 Reinertsen states:
“If we synchronize both the batch size and the timing of adjacent processes, we can make capacity available at the moment the demand arrives. This leads to a dramatic reduction in queues.”
This is also congruent with how SAFe uses syncronized Sprints, demos, Scrum of Scrums, Product Owner Synchronization meetings, and other artifacts, to synchronize batch sizes and timing of teams working in the same Agile Release Train (ART).

The mistake I made when I tweeted, was to assume that my unproven hypothesis, that SAFe has gotten its ideas from Reinertsen’s book, was a fact. All the evidence is circumstantial. The practices in SAFe may have been derived from other sources.

At this point, Donald Reinertsen joined the conversation, and pointed out that the similarities do not in any way prove causality. He did agree though, that the basic principles are the same.

While I agree completely with the principles listed above, I also believe that there is a bit more to it than that. Let’s check out what Reinertsen wrote about in those other sections I mentioned in my tweet:

  • B13: The Principle of Batch Size Diseconomies: Batch size reduction saves much more than you think.
  • B14: The Batch Size Packing Principle: Small batches allow finer tuning of capacity utilization.
  • B15: The Fluidity Principle: Loose coupling between product subsystems enables small batches.

Section B13 explains non-linear effects that makes transaction and holding costs skyrocket as batch sizes grow. Reinertsen writes:
“Our calculated optimum batch sizes are likely to be too large. In the presence of the hard-to-quantify large batch diseconomies, it is important to aggressively test our assumptions about optimum batch size.”
Section B14 says that if we want to use people and resources effectively, we need small batches. Reinertsen writes:
“Smaller batches inherently help us get better resource utilization with smaller queues.”
Section B15 is particularly interesting. It says that to work efficiently with small batches, we need to reduce dependencies between them. To quote Reinertsen again:
“If we want to start testing subsystems before the entire system is designed, we need to create independently testable subsystems. As we reduce dependencies, we gain flexibility in routing and sequencing.”
Note that this has implications for the SAFe program organization: Teams cannot work independently of each other if they work on subsystems that have dependencies. At the risk of seriously overquoting, here is Reinertsen again:
“This illustrates the extremely important relationship between product architecture and development process design. Once a product developer realizes that small batches are desirable, they start adopting product architectures that permit work to flow in small, decoupled batches. These loosely coupled architectures, with stable interfaces, enable us to work in parallel on many subsystems. We can work in parallel with low risk, if we are confident that the work we do will ultimately integrate well at a system level.” 
Before putting everything together, I’ll add one more piece to the puzzle. This is a reference I ought to have included in my tweet above, but in my tweeting frenzy, I missed it:

  • F10: The Synchronization Capacity Margin Principle: To enable synchronization, provide sufficient capacity margin.

We need a capacity margin to synchronize. That means the benefits of synchronization come at a cost. This should not be a surprise.

Imagine you have two people running a long distance race. There are five checkpoints along the way, and you want the runners to arrive at the same time at each checkpoint, and at the goal line.

You may think this sounds a little bit weird, but that is what the synchronization mechanisms in SAFe do. Synchronization, in this case, would enable you to have each checkpoint open for a shorter time, and it would enable the runners to exhange information, and plan the best route to the next checkpoint. It would also slow down the runners. Before each checkpoint, the fastest runner would have to wait for the other runner to catch up.

Suppose one runner is the slowest on stretches one, three and five. The other is slowest on two and four. Over the course of the race, both runners will have to slow down, waiting for the other.

Imagine you have twenty runners, and twenty checkpoints. It’ll be a slow race. Replace the runners with software development teams, and the race with a SAFe program.

I’ve been measuring team velocity, and variation in team velocity, in almost every software project or program I have worked in for the past fifteen years.

Team velocity varies a lot from sprint to sprint. Study a team over a significant course of time, and you will see that the difference between lowest and highest velocity in a sprint, may be a factor twenty, or even more, for a normally functioning team.

If you have ten teams in an ART, it is a good bet that at least one team will be really slow each sprint. If you have a lot of dependencies, it is likely that other teams will have to wait for that slow team, every sprint.

What do you call five slow sprints, and a two week capacity buffer? A Program Increment.

A Program Increment is three months long. That means you get pretty large batches. If B13 holds true, and reducing batch size saves much more than you think, then large batches will cost you much more than you think. Those large batches will also prevent you from doing the fine tuning mentioned in B14.

How can you see that you have a problem with too many couplings?

For starters, look at the Program Board. If you have many pieces of string connecting work items done by different teams, then you have a problem.

You should be aware that the board does not tell the whole story. Some years ago I created a system for real time detection of dependencies, and delays due to dependencies, and found, among other things, that what you see on the Program board is typically less than 25% of the dependencies you have in a single PI.

For a very rough estimate of how many dependencies you have between subsystems, count the number of strings, multiply by four, then multiply by the number of PIs you have had in the program.

I created a graph of such an estimate in a program where I worked. It was a red mass of strings, where you could not even see individual strings, except in the periphery. I have come to understand that this is normal for SAFe programs. Few people are interested in reducing the number of dependencies, because few people are aware of the impact.

How do you solve the problem with slow progress?
Reduce batch size!

How do you do that?
Reduce couplings between teams, so they do not have to wait for each other.

How do you do that?
Reduce couplings between software subsystems.

How do you do that?
That depends.

Sorry, but my experience is that the answer to that last question is different for different organizations. I have seen organizations where legacy IT infrastructure causes hard couplings, where inability to grasp object oriented programming principles cause hard couplings, where the organizational structure causes hard couplings, where the requirements model causes hard couplings, where the organization’s own process experts cause hard couplings, where the architects cause hard couplings, where KPIs and OKRs cause hard couplings…Usually, there is more than one problem at the same time.

Everywhere I have been, the problems have been of known types, with known solutions, just not known in the organizations beleaguered by the problems.

While I cannot give you a solution tailor made to fit your organization in a blog post, I can give you a very general guideline:
Decouple when you can, synchronize when necessary! 
SAFe does tell you to decouple, it is just that the emphasis is almost exclusively on synchronization. What little information there is on decoupling gets lost.

I believe there ought to be way more emphasis on decoupling, and I believe people must be trained to understand the trade-offs involved.

Unfortunately, in many organizations, that means you need to retrain managers, developers, and architects…and many of your SAFe consultants.

What do you think? Comments are welcome.

Tuesday, January 07, 2020

Taking Flight for 2020

Chrononauts V: Taking Flight by Henrik Mårtensson
It's early in 2020, and I think it is appropriate to make a personal retrospective of the year that was. I am not quite as certain it is appropriate to publish said retrospective, but then again, if I decide not to publish it, I'll probably never get around to writing it.
For me, 2019 has been a very good year, both privately, and at work.

Let's get the personal stuff out of the way first. I haven't blogged much in this blog, but that is mainly because I have been busy, with work, and with other things.

My hobbies, like digital art, may not seem to have much to do with my work on process and organization improvement, or my forages into Scrummastery, but actually they do.

Almost everyone I know who is a really good software developer, or leader, or manager, does have some sort of interest in creative arts. Some play instruments or sing, others write, draw, are into photography, or some other creative activity. Of course, that creative activity may also be programming, building stuff, mathematics, or something else.

I'll connect the dots between art, software development, and leadership throughout this post.

The Things I did When I Didn't Work

Arachnophobia II: The photo that didn't look like a photo, but was, sort of. Models: Petra Brewitz and Peter Markusson.
I have blogged quite a bit at my art blog, and I blew past 100 published works at ArtStation. I managed to get excluded from the Planket photography exhibition because my photos didn't look like photos, but then I got included again when I explained why my photos looked like they did. I was experimenting with a modernized version of pictorialism, a photographic style that was popular up to the 1920´s.

That was a lucky break, partially because it is fun to exhibit my pictures, and partially because the head of the Volvo Photographic Society saw my work at the exhibition, and invited me to visit Volvo to talk about photography, which I did, in the company of a good friend, and collaborator in some of the art projects I perpetrate, Petra Brewitz.

The invitation to hold a presentation at Volvo, gave me an opportunity to talk about something photographers, like many managers, tend to overlook: Teamwork!

Even better, it gave me an incentive to think through what I know about teamwork, and to think about the things I know I do not know.

I've worked in the software business for longer than I care to admit in a blog post. One of the things I have learned, is the importance of teamwork.

When I took up photography as a hobby, it was natural to apply some of the lessons I have learned at work. One of those lessons is:
If you want to do something a bit complicated, you need a team!
At the presentation, I wanted to show that the pictures I make, not made by me alone. They are the result of teamwork. Therefore, I asked Petra to come with me, so that the audience could get a perspective that is different from mine, and so they would see that I work with other people, instead of just hearing me say it.

Photographers and models are often stuck in a severely outdated model of work relationship: The photographer is the authority, and responsible for both ideas and technical implementation. Models are expected to do as they are told, and not much more than that.

That isn't much fun, especially not for the models. It is not the road to making great pictures either, because it limits the range of ideas you can work with. It also severely cuts the ability to solve problems along the way.

Let's take the picture above, Arachnophobia II, as an example. Petra Brewitz, the model to the left, is from Öland, and has an interest in Öland history, including viking history. She is also an amateur photographer (and a programmer, though this is less important for this story).

The past four years, Petra has invited a small group of photographers to exhibit photos together in Borgholm, a city on Öland, during the Borgholm Harvest Festival.

It is because I am a member of that group of photographers, I shot the photo of Borgholm castle seen in the background.

Petra and I were originally working on a viking/Fantasy themed photo session together. At that point, the idea was to create a picture with two vikings fighting a dragon.

Peter, to the right in the picture, is an experienced model. One of his hobbies is live roleplaying. That means he has a lot of great ideas about Fantasy themed pictures. It also means he has something I sorely lack: medieval weapons and armor.

Between them, Petra and Peter have lots of knowledge about viking history, and Fantasy. They also have quite a bit of useful props, like swords and armor. I contributed my knowledge of, and interest in, Fantasy, a basic idea and storyboard, the background picture, some skills at 3D compositing, and a 3D model of a giant spider, which I had bought, because, you know, you never can tell when you are going to need a giant spider.

We all contributed, and the picture you see would not have been possible if we had not, all of us, contributed ideas, props, equipment, time, and quite a bit of work.

In my professional life, I am sometimes lucky enough to be a part of teamwork like that, but it is usually confined to a single team, or lateral collaboration, when teams work together.

Only in the rarest of cases do I see the teamwork extend vertically, throughout all levels of the organization. There, collaboration tends to end, and managers often have the mindset of photographers.
Cat and Mouse. Model: Cassandra Högfeldt
Arachnophobia II got me into the Planket exhibition, but it was Cat and Mouse that got me the presentation gig at the Volvo Photographic Society. I had printed the picture on a large canvas, making it the centre piece of my pictures at the exhibition. Cat and Mouse is the result of a collaboration with Cassandra Högfeldt, a model that contacted me after seeing some of my earlier pictures.

I had been planning a series of Lost World themed pictures, and Cassandra, with her combination of modelling experience and military background, was the perfect model for a set of gritty, yet beautiful adventure pictures. We worked on three sets of pictures during the year.

Here too, we used ideas from both of us to push the pictures as much as we could. And, it would not have worked without Cassandra's arsenal of daggers, gun props, and other equipment. I supplied sabretooth tigers and other creatures, and a variety of prehistoric environments.

Again, without collaboration and teamwork, including quite a bit of problem solving, the pictures we made would not have been possible.

At Work: Developing the Dependency Jar

The Dependency Jar is used to track dependencies in software development programs.
Over the past few years, I've seen some interesting changes in how software is developed at many companies.

Software has become more complicated, and is now developed not by one team, but by many teams working together.

This creates new challenges. Twenty years ago, the problem was how to enable people in a team to work effectively together.

Solutions at the time, like RUP, The Rational Unified Process, which was neither unified, nor very rational, sometimes helped, but just as often wreaked havoc in software development projects.

The trouble was that RUP was a toolkit, actually a fairly good one, but companies kept mistaking it for a process, with predictably unpredictable results.

To be fair, the word process was right there in the name of the thing, so if one was sufficiently disinclined to actually read what the RUP documentation said, and perhaps a bit stoned, it was possible to mistake RUP for a software development process.

When agile methodologies arrived on the scene, in my case in 1999, it felt like I was being delivered from software development hell. Finally, we had a way of working together that actually worked. I was a developer at the time, and we used Extreme Programming.

Then, of course, companies shied away from the difficult bits in agile, like writing code that worked well and was easily maintainable, and focused almost exclusively on the human interaction bits, and went with Scrum. It was a bit like removing two of the wheels from a car in order to go faster.

Still, what we got was way better than RUP, even if it did not quite spark the revolution in software development, and business paradigms, that the pioneers envisioned.

Nowadays, most companies I work for actually have pretty good teams, and understand how teams work very well.

But, and it is a big but, all the old interaction, communication, and software design problems are still there, they just moved to the space between teams.

Agile methods were designed for single team projects, and do not deal with multi-team problems very well. That left a big, gaping methodology hole, and methodologists were of course eager to develop new methods to cover it.

SAFe is the New RUP

Most companies seem to have chosen SAFe, and guess what, SAFe is the new RUP!

I have worked with SAFe for a couple of years now, used it in practice, and studied the documentation. Like RUP, SAFe is a collection of ideas from many different sources. The original ideas are often good ones, but SAFe uses only part of the ideas, and leaves out anything that is difficult to implement, or difficult to sell.

I'll give you just one example. It is a thing that has cropped up over and over again the past couple of years:

SAFe uses quarterly events, Program Increment planning meetings (PI Planning), to synchronize multiple teams working together. This is an idea that probably comes from Donald Reinertsen's excellent book The Principles of Product Development Flow.

In his book, Reinertsen wrote:
If we synchronize both the batch size and the timing of adjacent processes, we can make capacity available at the moment the demand arrives. This leads to a dramatic reduction in queues.
-Reinertsen, Donald G.. The Principles of Product Development Flow: Second Generation Lean Product Development (p. 189). Celeritas Publishing. Kindle Edition. 
That is perfectly true, and that is what PI meetings do. However, the SAFe authors skipped other, equally important parts, like this one:
If we are trying to coordinate the simultaneous processing of multiple items, then our schedule will be determined by the arrival of the most limiting item. We need sufficient schedule margin to ensure this item does not delay the entire group. 
Think of an airline with multiple commuter flights feeding a larger long-haul flight. Since some of the commuter flights may arrive late, we must allow a safety margin for passengers to connect to the long-haul flight. The more feeding flights we are trying to support, the more margin we need.
Reinertsen, Donald G.. The Principles of Product Development Flow: Second Generation Lean Product Development (p. 187). Celeritas Publishing. Kindle Edition. 
What that passage means is that the benefits of PI meeting can be killed off if you try to coordinate too many teams.

In other words, very large PI meetings suck!

SAFe also managed to ignore that synchronization is not always what you want to do:
Once a product developer realizes that small batches are desirable, they start adopting product architectures that permit work to flow in small, decoupled batches. These loosely coupled architectures, with stable interfaces, enable us to work in parallel on many subsystems. We can work in parallel with low risk, if we are confident that the work we do will ultimately integrate well at a system level.
Reinertsen, Donald G.. The Principles of Product Development Flow: Second Generation Lean Product Development (p. 127). Celeritas Publishing. Kindle Edition. 
Working in parallel is way better than synchronizing, if the software design and organizational structure permits it.

In practice, an optimal solution usually requires figuring out what you can do in parallel, and what you have to synchronize.

Unfortunately, SAFe encourages using synchronization as a generic bandaid, so companies do not have to improve software architectures, or change their organization.

This has grown popular, partially because it can alleviate problems in the short term by shoveling the serious problems into the future, partially because it is an easy recipe to follow, and does not require learning, thinking, or changing paradigms.

The downside is that it locks companies into obsolete software architectures and organizational structures, which makes both the software and the organizations increasingly fragile and vulnerable to the change that goes on in the world around them.

Which brings us to the picture of the glass jar, the Dependency Jar, above. I needed a very simple tool to track dependencies in teams, between teams, between teams and the organization around them, and between teams and external actors.

SAFe has a tool for predicting which cross-team dependencies that will have an impact on development during a Program Increment, i.e. a quarter.

I wanted something that could give me a record of the dependencies that actually have an impact during development. I also wanted said tool to provide me with information I can use to break dependencies, and decouple teams.

That would give me a way of helping clients hands down beat competitors that rely on SAFe and synchronization.

Turns out you can do that with a glass jar, a pen, and Post-It notes...and some other stuff.

Exactly how do you beat SAFe? In terms of popularity, I won't even try. In terms of having a more effective process that delivers more value than SAFe does, faster than SAFe does, and with better return on investment than SAFe does, that is doable, in many, many ways.

If you are curious about how to do it with a glass jar and Post-It notes, you will be able to read about it in this blog, this year. I spent more than a year figuring out how to do it, and I am still testing and developing various ideas, so I am in no hurry to spill the beans.

More Work: Simple Simulation of the Real Cost of Open Offices

There is a widespread belief that open offices are the way to go if you want a lot of people to work well together. This belief is not supported by research. There is plenty of research that shows that open offices make people feel awful, and loose productivity.

As it turns out, you can translate the research data about productivity loss into economic terms. You can also calculate the savings in office space you can make by having an open office plan.

That makes it quite easy to construct a simulator that lets you check whether the cost savings outweigh the productivity loss, or vice versa.

That can give a company valuable information about what kind of office design to go with, or whether it is economically beneficial to switch from one type of office to another.

That is one of the things I did last year. I'll save the details for a future blog post, but I'll tell you I am amazed by how many companies that have only considered one side of the equation, and because of that made the wrong economic choice.

I'll give you a hint though: In most cases, the right economic choice turns out to be the choice that is also best for the people working at the company, and we have known what that choice is since at least 1979, when Christopher Alexander published The Timeless Way of Building.

Summing Up

Inventing a new practice, the Dependency Jar, that enables companies running large software projects to visualize, mitigate, and even eliminate, dependencies, reduce the need for synchronization, and help organize in ways that support the things they want to build, and coming up with a model for calculating the true cost of plan offices, that is pretty good for a year.

Personally though, I am even more happy about developing as an artist. Well, some sort of pseudo-artist, at least. I do not work the way most artists do. Instead I combine whatever skills I have as a photographer, with my skills as a process developer, and my skills in building and leading teams, to create the kind of pictures I am interested in. On an intellectual level, I know that in art, it is the results that count, but emotionally, the fact that I break a lot of rules about how to create art, gives me a horrible case of impostor syndrome.

Perhaps I should also mention that most of the work I've done, has been perfectly normal consulting work, and that the thing that sets it apart, is that I have had the opportunity to work with some really great people.

2020 has arrived, and I am looking forwards to seeing what it will bring. A lot!

Arrival, a.k.a. T-Rex Rider, by Henrik Mårtensson

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 problems...in 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.