Books for Software Engineers: Nature-Inspired Ways to Scale Software Delivery (Interview with Yaron Perlman, Author of "DevStreams: Scaling Software Delivery. Naturally.")

You know kanban. 

You’re familiar with the scrum framework to its last detail. 

You’ve heard it so many times, you’ve considered changing your second name to Agile. 

How about DevStreams?

This fresh paradigm aims to increase efficiency in software delivery while helping individuals realize their full potential, all by getting inspiration from structures that appear in nature. 

Yaron Perlman, author of the book DevStreams: Scaling Software Delivery. Naturally. talks about the main ideas behind the DevStreams paradigm and book. He sheds light on the connections between nature and successful developer teams, and shares how DevStreams can help organizations and individuals at the same time. 

This blog post was written based on episode 80 of the Level-up Engineering podcast hosted by Karolina Toth. 

This post covers:

• Defining DevStreams
• The paradigm
• The book
• Main ideas of the book
• Nature and software delivery
• Fractals
• Evolution 
• Chaos theory
• Letting go
• DevStream’s impact
• On a company-level
• On an individual level
• What companies benefit most from DevStreams
• Implementing DevStreams
• Overcoming challenges
• People who want to stick to their roles
• Ensuring balance between team members 
• Common objections regarding DevStreams
• About Yaron Perlman

What is DevStreams?

DevStreams: The paradigm

DevStreams is a nature-inspired paradigm for scaling and dealing with the challenges of software delivery, from developing software to making it available for users and providing customer care. In terms of scaling, DevStreams addresses scaling software both in terms of value, volume and velocity - introducing more features, fixing bugs and so on. DevStreams is also focusing on DX (development experience) and EX (employee experience), and takes employees' daily routines and satisfaction levels into account. 

The inspiration for all these aspects comes from nature. If we look around, it’s the most successful complex system at scale. My thought behind DevStreams was, why not look at nature and try to adopt some of the solutions that have been evolving over millions of years to use it for software development as well?

In this new structure I propose, organizations are not divided into different departments, but into streams, resembling how rivers work. A stream consists of 2-7 members and is an integrated self-contained and autonomous unit. Within a stream, you have people who do DevOps, QA, development - in short, everyone does everything. In these microorganisms, there is space for movement, iteration and diversity. They’re not independent from each other, but less dependent. 

In a DevStreams organization, the most fundamental unit is the stream itself, not the individual. You look at a stream as a whole, and it’s supported by six pillars, each representing a different aspect of the operations. There’s a seventh element in this paradigm, too - the fact that there are no rules. Each stream’s circumstances are different, so it’s impossible to make generalizations. 

DevStreams: The book

My main inspiration for writing a book about DevStreams came from looking at structures and dynamics that I find in nature. When I look at software delivery organizations, they’re working on delivering value, and it can be seen as a flow - a flow of value and a flow of energy. 

When you look for something similar in nature, you’ll find it in rivers and streams, but also in the stars and galaxies. Interestingly, when you zoom out, certain areas of stellar gas where stars are born look like rivers. When you look at a lightning bolt, it looks like a river. It all suggests to me that there must be something fundamental in the structure that deals with flow in a very efficient way. 

Although I write about software, the book is about maximizing your potential both as an organization and as an individual. It’s what nature does: it doesn’t like to waste. It’s what humans mimic in the economy as well: there are fluctuations, mass layoffs or hiring sprees depending on what will maximize efficiency and talent. 

What are the main ideas of your book?

Nature-inspired tips for software delivery

When you look at nature and software delivery, there are some interesting similarities in terms of minimizing waste and increasing productivity. 

Fractals

In terms of structure, fractals dominate software delivery. They’re everywhere in nature, too - in rivers, tree branches, in leaves, even in the way lungs are built. It’s the same structure: self-similarity over scale. 

Evolution

As for processes, evolution is the most important idea. 

Traditional project management processes can be rigidly structured. Take the agile methodology, for example: you have sprints with pre-defined goals, and you follow this structure over and over again.

In DevStreams, our way of handling processes is called “evolution through mutation”. If we were to build a new feature, I’d look for something that is similar to what I’m trying to create and introduce small changes, eventually mutating it to the outcome I’m looking for. It’s the same concept as MVP, but reduced to the feature level. MVC is the minimum viable change to introduce something new. It’s important to keep MVCs reversible, so we can go back and change things if something doesn’t work. 

The butterfly effect

DesStreams also takes inspiration from the butterfly effect within chaos theory; the notion that if a butterfly moves its wings in China, you would see a big tornado in the States. It’s the concept that as we introduce small changes, they take us to areas where we didn’t plan to get to in the first place. 

We like to be organized, to plan things ahead and fulfill them, but nature doesn’t work that way. It lets things happen. There’s a certain direction, but the details are not set in stone. In DevStreams, we focus on doing simple things and gaining momentum by them in a similar way.

Letting go

We tend to think that feelings and emotions don’t have a place in a professional setting - especially in software. The assumption is that everything needs to be measurable and data-focused. 

Within DevStreams, there is space for people to trust their intuition. I encourage them to understand their feelings, reconnect with them and bring it into their work environment in a way that is valuable and natural to them. 

How can the ideas of DevStreams improve an organization’s life?

Scale effectively

DevStreams enables scaling software delivery more effectively. By adopting certain concepts, we can increase volume and velocity at the same time, maximizing efficiency just like nature would. The main motivator for establishing DevStreams is to challenge traditional, less efficient ways of working, and creating more efficient processes from your already existing resources. 

If you make your current employees more motivated and engaged, they’ll also be more productive while feeling satisfied in their roles. And it’ll all come naturally, because DevStreams focuses on building autonomous units.You as a leader will still give them directions, but they’ll manage themselves.

Empower your employees

In terms of individuals, introducing DevStreams can help them expand their horizons. They don’t need to stick with the tasks listed in their role descriptions - they can try themselves in different areas instead. 

Some people work better when there’s a level of diversity in their tasks. The idea of working in a strictly structured environment, doing the same tasks until retirement scares many workers. Water becomes stale if it’s not flowing. Similarly, if we don’t move from one place to another, we sink. 

DevStreams gives developers the space to fulfill their potential and explore what they’re really capable of. They get to experience different challenges while working with more people, constantly learning about themselves and from each other. 

What kind of companies would DevStreams be ideal for?

The paradigm can be beneficial for any type of company, because it challenges the stereotypes we associate with certain types of teams. For instance, some people don’t feel comfortable in large organizations, because they like to be recognized. Others appreciate the complexity of a large firm.

However, in DevStreams, even the largest organization is just a big river. A big river looks exactly like a smaller river, just at a different scale. You can focus on finding your ideal stream without worrying about company size, because it’s not about the organization anymore, but the overall environment that you’re joining. And any company that adopts the DevStreams paradigm is going to have the same type of environment. 

How to implement DevStreams in your team

If you’d like to introduce DevStreams to a small team, reading the book and getting familiar with the paradigm are good first steps. Then you can take a look at the pillars mentioned, see what makes sense for your team, and try to adopt them. See how it goes. Break the silos between people. Let your frontend developers do some backend or some DevOps. Maybe let them try customer care. In smaller and newer organizations, there is usually more space for experimentation like this. 

For bigger companies built in a more traditional way, we can introduce DevStreams through a  program we call Journey Seeding. Think of it as planting. We assemble one stream and help them through their initial months working together. When they get the hang of DevStreams, we split them into two streams and bring more people to each - eventually, the entire organization transforms. 

Challenges of implementing DevStreams

People who want to remain in their roles

I’ve met various people who wanted to keep their original positions without experimenting with new areas while their organization wanted to introduce DevStreams. This situation can work out well, because in some cases, companies do need people who are focusing on just one single area instead of trying multiple ones. 

For example, I’ve worked with a few data scientists who didn’t want to do anything else besides being a data scientist. Luckily, the organization needed their expertise full-time, so they weren’t assigned to any particular stream, but acted as consultants in all streams. This way, they could retain their area of expertise while streams could also make progress.

Balancing work within streams

The important thing is to create an environment where people find themselves through experience. There could be areas they’re amazing at, but they’ve never had the chance to try themselves in something outside of their comfort zone and get into the growth zone. People in the stream can also learn from each other - ideally, each member is stronger in an area than others. 

In terms of individual versus team accountability, the whole stream takes credit and responsibility for the outcomes. We’re not blaming individuals for a system failure, but let the entire stream work together on finding a solution. This turns mistakes into learning opportunities for the entire team, and takes off some of the pressure individuals feel about their tasks. 

What are some of the misconceptions that you have encountered towards DevStreams?

After publishing the book, some VPs told me they liked the concept, but didn’t find it realistic to have streams where everyone does everything proficiently. My answer is, how do you know? Have you tried it?

When you start experimenting with the paradigm, you'll see that it’s not that far-fetched. Especially with today’s technological advancements in AI, it’s easier to pick up new skills than it was a year ago. We have so many tools available to make our work more effective, and our technology landscape is changing rapidly that it really merits a new paradigm. 

DevStreams isn’t the ultimate solution, and that’s not what the book is about. It’s about thinking differently and understanding that breaking the status quo is not simply okay, but very much needed. It’s about knowing we can get out of our comfort zone, reinvent ourselves, question what we do and think outside the box. And when we do all these things, amazing results will come. Naturally. 

About Yaron

Yaron’s passion for programming began when he was just a child. He went on to study computer science and mathematics and started working in the industry afterwards. He has co-founded and led a couple of startups and gained experience in various roles over the years, including project management. Over the last few years, he’s been an independent software solution vendor and has been focusing on consulting for various companies who have software delivery challenges. 

In his free time, he plays the guitar. He’s also a pilot and volunteers to fly people with medical needs.