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