DEV Community: Francisco Ortiz

Little's Law: improving the lead time by reducing WIP

Francisco Ortiz — Wed, 01 Jun 2022 06:57:39 +0000

Improving the delivery lead time is a goal for every organization. In this article, we will explore Little's Law, a mathematical theory that relates lead time to the amount of work in progress and to the team's throughput.

Little’s Law

Little’s Law comes from queueing theory. It states the following:

“The long-term average number L of customers in a stationary system is equal to the long-term average effective arrival rate λ multiplied by the average time W that a customer spends in the system.”.

Algebraically, the law is: L = λW

Little’s Law is present in every queue. Some examples where it appears are:

Number of customers in a store
Number of messages in a queue
Number of user stories in a product backlog

In this article, we will focus on the last use case: the number of user stories in a product backlog. Considering the product backlog as our stationary system, we could define the Little’s Law as:

The average team’s delivery lead time is the number of work-in-progress tasks divided by its throughput.

where:

Lead time is the average time a task spends in the backlog.
WIP is the average number of in-progress tasks.
Throughput is the average amount of work a team can complete in a certain period of time

From the formula, we can see that we have two options to improve lead time: reduce the amount of work in progress or increase the throughput.

Reduce Work In Progress

Work in progress (WIP) refers to the work that has been started but not yet finished. When we set a WIP limit, we are forced to prioritize and select the tasks to implement. If the WIP limit is reached, nobody is allowed to start new work. Instead, all people should help to finish the ongoing work.

As John Cutler explains here, limiting WIP is hard. We usually have the goal of having everyone busy, and any other choice is considered ineffective. In fact, any other decision seems counterintuitive.

With Little’s Law, we have mathematical proof that reducing WIP is a better strategy if we want to finish our work early. We don’t want resource optimization, we want to optimize the flow in the queue. We want to stop starting and start finishing.

How to reduce WIP

Do fewer things: this may look obvious, but it forces us to make decisions and discard some ideas. Otherwise, we will have a never-ending backlog and a lot of pressure to start new work. Steve Jobs said: “People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully.”.
Pair / Mob programming: pair/mob programming is also an excellent approach for reducing WIP. Instead of assigning one task to each developer, try to solve the problem together. As we said, our goal is to complete the task as soon as possible, not to start as many as possible.

Increment throughput

In Kanban, throughput refers to the amount of work delivered over a certain period of time. Example: the number of tasks a team can complete on a weekly basis.

While the current amount of work in progress can be reduced instantly, increasing the team's throughput is not as simple. There are no immediate actions that produce a better team performance. However, there are some decisions that can improve this throughput in the long term.

Improve the team's technical practices: practices like trunk-based development, automatic testing, or continuous delivery improve the software delivery performance, so the throughput will increase.
Improve team’s autonomy: teams should be autonomous to complete a task. When a team needs to wait for external dependencies to complete their work all the time, the lead time is really affected. This topic was covered further in the Cross-Team Communication: avoid dependencies post.
Work in small batches: by working in small batches, we can quickly validate if changes have the desired effect. If not, it lets us make the proper corrections. As a result, we avoid spending a lot of time working on a bad solution so we improve the throughput.
Hiring more people: this always can be a valid solution. However, remember to be careful, as the team throughput does not grow in the same way as the number of people in the team. The more people in the team, the more needed coordination for the team to perform well. If the required coordination is too high, the team throughput can decrease when we add more people to the team. That’s why we have some rules like the Two-Pizza Teams.

Summary

When working on any queue, we should keep in mind that the goal is to optimize for fast flow, reducing the lead time as much as possible.

In this article, we have seen Little’s law, a powerful and simple mental model that establishes a relationship between the lead time, the number of in-progress tasks, and the team throughput. In order to have the shortest lead time, we should try to reduce the number of work-in-progress items and increase the throughput.

We have focused on a product backlog queue, but remember that this model is valid in any other queue. If you are optimizing a process that involves a queue, consider simulating your use case with this law.

What is your experience with Little's Law? Please get in touch and let me know.

Book review: Modern Software Engineering

Francisco Ortiz — Thu, 31 Mar 2022 07:07:30 +0000

When I read a book, I don't always take the time to reflect on what I learned. My purpose in writing these articles is to share a quick summary of some books I find interesting, along with some opinions and learnings I am taking from them.

My first choice is a book I just finished last month: Modern Software Engineering by Dave Farley.

As a frequent viewer of the Continuous Delivery channel, I had some doubts about reading this book, since I’m already very aligned with Dave Farley’s ideas :). Finally, I decided to read it and I enjoyed it. Modern Software Engineering is a book for anyone working or aspiring to be a software engineer. It presents a series of related ideas, advice, and technical practices that can have a significant impact on the quality of our work.

What is Software Engineering?

The book starts presenting software development as an engineering practice. This definition has always been something controversial for me, as we have sometimes separated the word “engineering” from software development. As Dave Farley says, this separation comes from the attempts of our industry of treating software development as a production line, designing waterfall processes where there is no discovery, learning, or experimentation. Software engineering is a different problem. Software is not a production problem (physical things with a high cost of replication) so we need to use different tools for software development: testability, experiments, continuous delivery.

Taking these things into account, Dave presents the following definition for software engineering:

“Software engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems in software”.

To master software engineering, we must become experts at learning and experts at managing complexity. Software development requires continuous discovery and learning, so that's why we should master the learning part. To do this sustainably, we must manage the complexity of our systems.

Optimize for learning

Software engineering is a complex and creative discipline, a continuous exercise of exploration and discovery. In many cases, we don’t even completely understand what we are building so it’s very important to explore our customer's needs, try to figure out how to solve the problem presented, or try to discover new tools to improve our work.

So, to master software engineering, we should focus on improving our skills of exploration, discovery, and learning.

To highlight the importance of continuous learning in software development, I also love the driving metaphor from the Extreme Programming book:
“Driving is not about getting the card going in the right direction. Driving is about constantly paying attention, making a little correction this way, a little correction that way”

To optimize for learning, the book presents five behaviors to consider:

Working iteratively
Feedback
Incrementalism
Empiricism
Being Experimental

The main idea is to work on small steps, collect feedback, and adjust. We usually fail to guess what users want. According to some studies, two-thirds of the ideas that come from top software companies fail to produce the expected value (here you have examples from Microsoft or Amazon). If these companies are making mistakes, then we will too :) So the important thing is to test our ideas effectively so that we can discard the bad ones as soon as possible.

This part of the book also reminds me of the DevOps Handbook book, with the Three Ways of DevOps:

The first way: System thinking
The second way: Amplify Feedback Loops
The third way: Culture of continual experimentation and learning

Optimize for managing complexity

As a company grows, if we want to be able to scale, we need to manage the complexity of our systems.

We can start to work on a small idea without taking design decisions but, if our system grows and we want to scale beyond a single team we need to consider these ideas. Otherwise, we will end up with big-ball-of-mud systems, a huge number of bugs and technical debt, etc.

The book presents other five ideas to manage complexity:

Modularity
Cohesion
Separation of Concerns
Information Hiding and Abstraction
Managing Coupling

Tools to support engineering in software

In this block, Dave Farley examines some of the ideas discussed throughout the book, exploring them in more depth and showing some practical examples.

The presented ideas are:

Testability
Deployability: remember, deployable != releasable
Controlling the variables
Continuous Delivery

I also liked the part about disruptive organizations from this section, where he presents the “**BAPO versus OBAP” **model.

With the OBAP model, companies first fix the structure, departments, teams, and responsibilities. They then decide on a business strategy, architecture, and processes based on those constraints.

Instead, the first step in the BAPO model is to identify the business vision and goals. Then, work on defining an architecture and processes that help to achieve that architecture. The final step is to pick an organizational structure that supports the necessary activities.

OBAP: organizational structure > business vision > architecture > processes
BAPO: business vision > architecture > process > organizational structure

Summary

Modern Software Engineering book presents a good set of ideas, advice, and technical practices that we can apply to improve our work.

All the ideas are related. Using the presented ideas to manage complexity (modularity, cohesion, separation of concerns...) you will be able to create systems that will help you learn faster (through rapid feedback, small iterations, experimentation, etc.).

Analyzing the book, my feeling is that Dave Farley has got a mix of the Extreme Programming and the DevOps Handbook books in a single book so I would recommend it to anyone working in the software industry.

Pair Programming - Why you should try it

Francisco Ortiz — Wed, 23 Feb 2022 19:38:28 +0000

Pair programming is one of the most important practices from Extreme Programming. Although it is a well-known technique, it is rarely used in our industry.

One reason is that many people view pair programming as an ineffective technique. In terms of effectiveness, there have been many attempts to measure the performance of software teams. The problem is that they tend to focus on individual productivity: how much code people write, how many hours people work... They focus on outputs instead of outcomes.

However, software development is not about how fast we can write new code. The goal of any organization is to make money. To make money, companies need to reduce the lead time to increase production feedback.

In this article, we will see how pair programming accelerates production feedback. We will also discuss some other benefits of pair programming, and why it is such an important practice in software development.

Hopefully, you'll decide to try it out :)

Benefits of pair programming

It's important to be aware of the benefits a new practice should provide before you start using it. You can then evaluate if it's working, motivate yourself to keep doing it, etc. We will explore some of the benefits of pair programming in this section.

Team relationships

In 2015, Google wanted to discover if there were any common factors among its best-performing teams. They conducted over 200 interviews on more than 180 teams. What they found was that “who is on a team matters less than how the team members interact, structure their work, and view their contributions”.

Software development is a team activity. The communication that pair programming requires often leads to a stronger sense of team identity and better relationships between team members. We enjoy our success together when things go well. When things go wrong, it is also less painful for the team if they are together.

Knowledge Sharing

This one is the most obvious benefit of pair programming. When we do pair programming, every piece of our code is known by at least two people. A few immediate advantages at this point are:

Bus Factor problem is dramatically decreased.
Taking holidays whenever we like does not affect the team's activity. Team initiatives are not dependent on a specific person.

Furthermore, remember that the whole team is constantly exchanging knowledge. Eventually, everyone on the team will grow dramatically. In my opinion, there is no better strategy to spread learning than pair programming.

Efficiency

Let’s go with efficiency. When we are working on a new feature, our goal is to deploy the new changes into production as soon as possible so that we can get feedback about them. As we saw in the article on feedback loops, fast feedback has many benefits. We would like to work on small steps, committing changes very often.

In addition to having fast feedback, we want to maintain a high level of quality within our code. To keep this level of quality, we often do code reviews before deploying code to production. A second opinion is always useful. There are several ways to conduct these reviews:

Asynchronous code reviews: Asynchronous code reviews prevent us from committing changes to production continuously, so our goal of having fast feedback is broken. Additionally, asynchronous code reviews result in a lot of wasted time and interruptions due to multiple context switches. The screenshot below illustrates this clearly, from Dragan Stepanovic’s tweet:

Synchronous code reviews: to avoid interruptions and context switching, we can force our code reviews to be synchronous. However, what if we commit our changes very frequently in very small steps? We would need to interrupt our colleagues many times. It would not be effective. To have fewer interruptions, we would end up with bigger changes, which is something that we don’t want.
Pair programming: we have continuous code review with pair programming. As all the code is developed in pairs, the code review is not a separate step. All the code goes to production as soon as it’s committed.

So, as a summary:

To work on small steps, asynchronous code review is not an option.
With synchronous code reviews, we need a lot of coordination between the team members and we end up with bigger changes.
Pair programming allows us to work on small steps, getting fast feedback of our changes without compromising the code quality, as the code is continuously reviewed. Pair programming is the most effective way to work if we want to do continuous integration and continuous delivery.

If you are interested in learning more about the different types of code reviews, I recommend reading Edu Ferro's post on code reviews.

Quality

Collaboration generates more ideas than working alone on a problem. The more ideas we have, the easier it is to find better solutions, resulting in better quality.

Knowledge sharing also affects this quality. As the team grows due to this sharing, the overall quality of code increases.

Onboarding

Since pair programming improves knowledge sharing and team relationships, it is really useful when onboarding new team members.

New people will gain a much better understanding of the business domain, the code, and the entire organization with pair programming.

In addition to this, software development is a team activity. A new team member changes the dynamics of the team, as people need some time to get to know each other. Pair programming accelerates this process as people are constantly collaborating.

Communication skills

Communication is an undervalued and very important skill for software developers.

Pair programming forces us to share and discuss our ideas with our colleagues, instead of implementing the first solution that comes to our minds. To convince people to implement our ideas, we must explain them clearly, so our communication skills improve.

Summary

According to the DORA Research, practices like continuous delivery, working on small batches, and having a learning culture are predictors of higher software delivery and organizational performance.

With pair programming, we have seen that production feedback is faster, team relationships are stronger, and knowledge is spread easily within the organization. Additionally, we will improve the code quality, make a better onboarding process, and improve our communication skills.

Give it a try.

Using the DevOps second way to improve the product development process

Francisco Ortiz — Tue, 18 Jan 2022 19:43:27 +0000

All the DevOps principles and practices can be derived from the “Three Ways of DevOps”:

The first way: Flow/Systems Thinking
The second way: Amplify Feedback Loops
The third way: Culture of Continual Experimentation and Learning

These practices are well covered in both “The DevOps Handbook” and the “Phoenix Project” books. In this post, we will look more closely at a concept mentioned in “the second way”: feedback loops. From the “Three Ways of DevOps”: “The second way is about creating the right to left feedback loops. The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made”.

What are feedback loops?

In simple terms, a feedback loop is a process where the outputs of a system are used as inputs again.

Feedback loops are always running in the background of our lives. The human body is dominated by a variety of feedback loops: there are processes that ensure a proper balance of everything, from the amount of water in our cells to the number of hormones that we release. They are not only present in human biology, but also in the center of human behavior, where the outputs of many processes influence many of our decisions.

Of course, feedback loops are also present in product development. Through this post, we will explore how we can shorten and amplify these feedback loops and use them to improve our product development process. First, we will see the two types of feedback loops.

The two types of feedback loops

As we said, a feedback loop occurs when a change in something ultimately comes back to cause a further change in the same thing. Depending on this further change’ direction, there are two different types of feedback loop.

Reinforcing feedback loop

Further change is in the same direction. By increasing the value of a variable in the first entity, the value of the second entity increases, which causes the value of the first entity to increase even more. We can see it as a loop of accelerating change.

Compound interest is a classical example of a reinforcing feedback loop: imagine that you start with 100€ and get paid 10 percent interest each year. After one year, you’ll have 110€. The next time around, you get paid 10 percent interest on 110€, so you will have 121€. The loop will go on and on.

Reinforcing feedback loops can be great for building good habits or achieving peak performance in something. Of course, they can amplify the impact of bad behaviors as well.

Balancing feedback loop

Further change is in the opposite direction. In this case, an increase in value in the first entity causes a decrease in the second entity, which in turn leads back to a decrease in the first entity. A loop of this type causes the system to stabilize at a point where there can be no more change.

An example of a balancing feedback loop is a thermostat. Suppose we set a target temperature of 23 degrees. The lower the current temperature the greater the temperature gap. The greater the gap the more heat that flows into the system. That increases the temperature, which leads to a smaller temperature gap. It keeps going down until the gap is zero, where the system has reached the target.

Balancing feedback loops can be very effective at moderating bad habits.

Feedback loops in product development

During the product development process, we turn ideas into products, measure how customers respond, and adapt our product based on that feedback. Here we have the most obvious feedback loop in product development: the process of collecting customer feedback continuously and improving our product based on these insights.

But there are many other opportunities to get feedback before we put our software in front of customers:

Testing: each time we execute a test, we receive feedback about the test result.
Merge: when we merge our code with the main branch, we receive feedback about possible conflicts.
Code review: when more people see one piece of code, there is feedback about possible improvements.
Deploy: every time we deploy new code to production, we receive feedback about how it performs. Examples: how the system works with that new feature, possible incompatibilities with other features.
System monitoring: we continuously have feedback about the system’s health (dashboards, alerts, etc.).
Release: every time we release a new feature, we receive feedback about how it is used by customers.
Product instrumentation: we receive continuous feedback about the actions that customers are doing in our product through product instrumentation tools.

As we go through all these steps, from the moment we write the first line of code to the moment we know whether a feature is being used, the results we receive shape our next decisions, creating a feedback loop.

Shortening our feedback loops

Each action has a delay between doing it and receiving feedback. The longer this delay, the slower we can react. Additionally, long delays in receiving feedback lead to other problems such as:

A lot of wasted time on bad assumptions.
We make a lot of wrong decisions because of the impossibility of seeing the effects of our actions. Think about that shower faucet with a long delay: you always end up frozen or burned :)

Some examples of this:

Working in a separate branch for a long time: we may then discover that the main branch has changed and it is not compatible with our code.
A single developer works alone for a long time and the code is not compatible with the team practices: once the problem is found in a code review, all the code has to be rewritten.
We don’t talk with customers before implementing a feature: we work for a long time on implementing it. Then, the feature is not used by any customer.

To avoid these problems, we need to adapt our processes in order to have feedback loops as fast as possible. Remember, from “Three Ways of DevOps”: “The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made”.

Let’s look at some practices that lead to shorter feedback loops.

Unit testing

Unit testing is the first feedback loop that should be established on any project. Rather than running the whole application, you’re running smaller parts of code (test suites) designed to be fast. With unit testing, you can have feedback about your work in seconds.

Next, you can shorten and increase the number of feedback loops even more by practicing test-driven development (TDD). One of the biggest benefits of TDD is that you run your code often. As you write the test first, you’ll automatically have rapid feedback every time you save a new change. For me, this fast feedback is one of the main reasons to practice TDD.

Pair/Mob Programming

Apart from the advantage of improving your knowledge by continuously explaining problems or solutions to someone else, pair/mob programming is a powerful loop technique that provides peer feedback in seconds. By having people work together, the feedback they give each other is immediate and easily applied.

As an alternative to pair/mob programming, you can conduct synchronous code reviews. You’ll lose other benefits of group programming, but we will avoid long feedback cycles.

Trunk based development

With trunk-based development, we have continuous feedback about the compatibility of the newly developed code with the main branch. We are committing new changes to the main branch continuously so we avoid long feedback loops and painful merges.

Trunk-based development is a key enabler of the next practice, continuous delivery.

Continuous Delivery

Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes, and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.

Decoupling our deployments from our releases means that we can deploy more often, so we will have more feedback. Feature toggles are a great tool to do this.

Work in small batches

Work in small increments. Then deploy those small increments to production. Remember, the more time we spend working on an idea without getting feedback, the more probability we have of working on bad assumptions.

Amplifying our feedback loops: look for virtuous cycles

When we talk about amplifying feedback loops, we are looking for loops where each iteration of the cycle reinforces the previous one: reinforcing feedback loops.

When we get reinforcing feedback loops in a positive way we get a **virtuous cycle. **We can see an example with the level of automated testing on our product and the team's confidence.

As our product is more tested, the team will have a greater level of confidence when doing new features. Each iteration of the loop reinforces the previous one, and the levels of confidence and testing are rising continuously. This is why we want to amplify feedback loops.

However, we have to be careful, as the same positive feedback loop can also run in reverse order, creating a vicious cycle. Here, a bad situation feeds on itself to make it even worse. We can see an example below, with the technical debt and the code quality:

The more technical debt in our project, the more quick and dirty code we will produce. This feedback loop will be continuously running unless we stop it.

Conclusions

Feedback loops can be a powerful tool in our product development process. The more positive feedback loops we have, the greater control of our system and better customer satisfaction, some goals that we all want to achieve.

However, we have also seen that there are negative feedback loops that can produce some vicious cycles if we don’t identify and stop them.

The intent of this article was to assist with creating and identifying feedback loops in the product development process so we can:

Amplify our current positive feedback loops, reaching virtuous cycles.
Stop our current negative feedback loops, removing the vicious cycles.

This way, we can move from letting feedback loops shape our decisions in an invisible way to designing the feedback loops we want and need. Rather than being victims of feedback loops suffering vicious cycles, we should be architects of them and benefit from virtuous cycles.

From Software Engineer to Product Engineer

Francisco Ortiz — Tue, 21 Dec 2021 18:43:14 +0000

The product development process consists of two different activities: decide what to do and decide how to do it. The part related to "the what" is called product discovery and the one related to "the how" is the product delivery.

Traditionally, software engineers have not participated in the product discovery part. The business team makes decisions, product owners convert those decisions into requirements for the software engineers and they implement the given solutions, called user stories.

This is what Marty Cagan defines as a feature team.

The success of these teams is measured by the number of user stories they complete within a given period of time.

But this is not the best approach to do product development. The purpose of a product team should not be just to deliver new features given by business requirements. The value of a product is not just in the number of features (the output), but in solving the right problems for the customer (the outcomes).

In Accelerate, we can see the following capabilities as higher organizational performance predictors:

Whether teams have a good understanding of the flow of work from the business all the way through to customers, and whether they have visibility into this flow, including the status of products and features.
Whether development teams have the authority to create and change specifications as part of the development process without requiring approval.

As a result of this paradigm shift, a new role is emerging within software engineers: the product engineer.

What is a product engineer?

Product engineers are software developers with a lot of interest in the product that they are working on. Apart from implementing solutions, they want to understand why problems deserve to be solved, how people use the product, and participate in the decision-making.

From my point of view, these are the main capabilities of a product engineer:

They understand the product

Product engineers want to understand the "why?" behind all things. They want to know how and why the product is successful.

How is the company making money?
What problem does the product solve?
Who are the users? How much do they pay?

The more engineers know about this, the better decisions they will make for the company.

They have product ownership

In the same way that they have ownership of the code that they ship, product engineers have product ownership. As we said before, product engineers participate in the whole value chain, from the decision-making to validating business metrics after the release.

They do not consider the work as done when a feature is released, that’s the moment when they actively start to follow up if the feature is meeting the expectations. If that is not the case, they attempt to figure out what went wrong and iterate on another solution.

They work as a team

Product engineers see product development as a team activity, where each team member provides a unique skill set and expertise to the team. They have good communication skills, having a strong relationship with the product manager, who is also part of the team.
Rather than having two separate teams (product and engineering) in charge of the discovery and delivery parts respectively, they work as a single product team, trying to resolve the customer problems together.

They offer new ideas and tradeoffs

As they understand how the product and the business work, they are able to bring new ideas and tradeoffs to the table. Some examples:

"We think we can improve the speed of our site in an X% using the technology Y. This would improve the metric Z in an N%".

"We could also test this other solution to solve problem X, the product impact would be similar and the engineering effort is extremely smaller".

They have empathy with users

They care about the experience the users are having with the product, making sure they are getting the expected benefit from it. They have access to all available business and user metrics and they are curious about this.

Technology is a means, not an end

They are software developers, but they don’t see the software as an end. They are focused on providing the best possible experience to the product users and software is useful in achieving that goal.

They don’t choose technology because it’s cool, they make those decisions based on the problem that they are trying to resolve.

They are proud of what they do

Product engineers are aware of how their work affects users. They are proud of the product they build and how it impacts their customers' lives.

They are ordinary but empowered people

We are enumerating many different capabilities of product engineers, but they do not have to be extraordinary as individuals. Instead, they are ordinary but empowered people.

They are empowered with all the necessary business context to do their job. The company needs to provide it. Otherwise, it’s difficult for these people to do their job.
They are empowered because they work as a team: there are many different skills and experiences in a product team. As a result, all the team is empowered with all these skills to resolve the business problems.
They are empowered with trust: because of this teamwork, people establish a huge level of trust in their teammates. This is really important to do their work properly.

Summary

Product engineers are a key ingredient to building a successful product. We have enumerated some capabilities that these people share:

They understand the product.
They have product ownership.
They work as a team.
They offer new ideas and tradeoffs.
They have empathy with users.
Technology is a means, not an end.
They are proud of what they do.
They are ordinary but empowered people.

We have also found that these people cannot excel without the proper company context, since they must understand the business that they are working on. Even though this isn't the most common scenario in software companies, I think that product teams are on the rise within our industry.

If you work for a product company: Do you consider yourself a product engineer? Do you have the proper environment to do your job? It would be a pleasure if you contact me and share your experience.

Cross-Team Communication: Avoid Dependencies

Francisco Ortiz — Wed, 01 Dec 2021 19:13:07 +0000

The delivery lead time is the time it takes to go from a customer making a request to the request being satisfied. So, improving this time should be a goal for every organization. A major decelerator for this delivery flow is that the different teams in an organization have been traditionally working in silos, with a ticketing system as the unique communication channel. This is tragic when you have some team dependencies, which is something that usually happens.

To tackle this problem, a simple solution emerges in most cases: Increase the communication between the different teams.

But, is this solution enough? How does the "increase communication solution" scale when the company grows? We will explain some of those things in this article but, as a spoiler: having proper team interactions is a complex problem, and complex problems rarely have simple solutions.

How cross-team communication scales

Having good cross-team communication and good collaboration is necessary. Also, when starting a product, the most effective way to work is having strong horizontal communication between individual team members, asking each other for help any time they need it. There are no blocks, features don’t have idle time so the lead time does not suffer.

However, this type of communication doesn’t scale well. When we have team dependencies that require continuous communication between the different team members, the delivery lead time for any feature can be affected as the number of members in the organization increase. Let's see with a figure from the Brooks Law:

As we can see, as the number of team members increases, the possible communication lines' growth rate is very high. If this communication is necessary because the teams are waiting for external dependencies many features will sit idle, teams will have context switching until they get the responses they are waiting for, etc.

So... what should we do?

Define your team interaction modes to remove dependencies

As we said, good communication is necessary and good. But the problem here is not the communication quantity, but the quality. We need to define the team interactions in a way that removes team dependencies as much as possible, removing the communication at all where it should not be necessary. From Accelerate:

"In teams which score highly on architectural capabilities [which directly lead to higher performance], little communication is required between delivery teams to get their work done, and the architecture of the system is designed to enable teams to test, deploy, and change their systems without dependencies on other teams."

The Team Topologies book approaches this communication problem, defining four fundamental team topologies and three team interaction modes:

The team topologies are:

Stream aligned team: aligned to a flow of work from (usually) a segment of the business domain.
Enabling team: helps a Stream-aligned team to overcome obstacles. Also detects missing capabilities.
Complicated Subsystem team: where significant mathematics/calculation/technical expertise is needed.
Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams.

About the interactions, they present the three interaction modes below:

Collaboration: teams work together for a defined period of time to discover something.
X-as-a-Service: one team provides and one team consumes something "as a service".
Facilitation: one team helps and mentors another team.

Depending on the team topologies, they propose to try an interaction mode or other.

When you want to apply these concepts, there are no right or wrong answers without knowing the specific team context. But checking your current team interactions and evaluating them is a good starting point. Some examples:

In my current company, Audiense, the stream-aligned teams needed a "collaboration interaction" with the systems team each time they wanted to create some infrastructure components, such as a new queue, event topic, etc. The stream-aligned teams didn’t have this infrastructure creation part within their development process, so that collaboration was always at the end of the feature development, leading to some blocks. Since some months ago, the Platform team has created a service where the different stream-aligned teams are able to create that infrastructure components writing some code, and the components are automatically created in the CI process. That interaction is X-as-a-Service now, and we have removed that dependency. We now have other parts where we are doing the same, but that dependency was causing many blocks.

For similar cases: does it make sense to have a collaboration interaction mode for a long time in parts where you can afford an X-as-a-Service one?

If you usually need to wait for some people to make some decisions: does it make sense? Can you remove that dependency by having a facilitation interaction mode during a specific time?

Those are the type of questions you should ask yourself.

As always, approach the problem as a continuous process, taking small steps to improve your current situation:

Evaluate your current team dependencies and their interaction modes.
Take the blocking dependencies first so features don't sit idle any more, these dependencies are your current bottleneck.
Update that interaction mode and remove that dependency.
Find the next bottleneck.
Start again.

Do you have any experiences applying these interaction modes between your teams? Please, contact me and share it!

References

Software delivery performance. Four key metrics https://itrevolution.com/measure-software-delivery-performance-four-key-metrics/
Brooks Law: https://www.leadingagile.com/2018/02/lines-of-communication-team-size-applying-brooks-law/
Accelerate: https://itrevolution.com/accelerate-book/
Team topologies: https://teamtopologies.com/
Why I hate the phrase “breaking silos”. Charity Majors. https://charity.wtf/2021/08/27/why-i-hate-the-phrase-breaking-down-silos/

How I created my blog with Gatsby, Netlify, and Plausible.

Francisco Ortiz — Wed, 24 Nov 2021 19:19:37 +0000

This post was originally posted on my blog.

If you want to remember something, write it down.

I’m starting a blog. After some time of doubts (pondering about if it’s worth it, thinking that people have already covered all the topics I will want to write about) I decided to give it a try. It was because of three principal reasons:

Get deeper into some topics I like: I think writing things down leads to better learning.
Help other people.
Improve my communication skills.

That said, I will use the first post to explain how I created the blog.

The first decision: where I should publish my content?

I was not sure about owning a domain name or publishing content on sites like Medium, Dev.to or Hashnode. After some research, I decided to publish on my own domain. It brings some benefits:

The first one is simple, I own it: I can choose and customize whatever I want.
I remove a dependency with a third-party platform.
I can still publish the same content on other platforms and redirect people to my personal blog. We have to take care of not hurting the SEO because of the duplicated content here, but we can solve it with canonical URLs.

After making that decision, I will explain why I chose the tools below to create the blog.

Gatsby

Gatsby is an open-source framework based on React that helps developers to build websites.

I’m not experienced in Gatsby at all, making this blog was my first experience with this framework. After being checked some other tools like Hugo that also met my requirements, I decided to give Gatsby a try, as I'm more familiar with its ecosystem.

You can start from scratch, but if you also don't have previous experience with Gatsby, I would recommend checking the available Gatsby starters: https://www.gatsbyjs.com/starters/. Once there, there are many options that you can pick.

In my case, I initialized the project with the gatsby-theme-minimal-blog starter.

gatsby new minimal-blog LekoArts/gatsby-starter-minimal-blog

After that, you can run the application and start modifying it with the commands below:

cd minimal-blog
gatsby develop

You will have your site accessible at http://localhost:8000.

Customization

Once you have started a new application, you can easily customize the page as you want if you have some concepts about web development, as it uses React, HTML and CSS.

If you are using a Gatsby theme, they have the concept of shadowing, which makes the customization really easy. This feature allows replacing any file in the theme src directory with your own implementation. As an example:

Imagine you are using a theme called some-theme and it has a file called some-theme/src/components/post.tsx.
If you want to replace that component with your own implementation, you just need to create a new file in your-blog-directory/src/some-theme/components/post.tsx. From that moment, your own implementation will be rendered instead of the default one.

SEO friendly

SEO is really important if you want people to find your website. Apart from making your site fast for search engine crawlers, Gatsby has some useful plugins to improve your implementation from the SEO point of view. Some of the plugins that I'm currently using:

gatsby-plugin-sitemap: it automatically creates a sitemap for your site every time you launch a new build.
React Helmet package: it adds metadata into the web page, which is very important for SEO.

Netlify

Once we have the content for our blog, we need to host it somewhere. I had experience with Github pages for hosting some pages before, but I decided to try Netlify and I finally chose it. It provides some advantages:

Continuous deployment: After adding some build settings in just a few clicks, Netlify deploys a new version of the blog every time I push a new change to the repository main branch. Also, it provides other features like deploy previews, rollbacks, or split testing. I'm not currently using all of these features but they can be really useful.
Domain configuration: it provides a really easy configuration for a custom domain name. Also, you will have an SSL certificate for free.

Although Netlify is a paid tool, all these features are included in the free plan, which is the one I’m currently using.

Plausible

I want to have some available analytics from the first moment. After trying Google Analytics, I think it’s a bit overkill for my use case.
As there are many data I don’t understand, I have a continuous feeling of not taking all the value that it provides.

After some research, I found Plausible. It provides simple analytics with some easy-to-understand dashboards. Also, at least from my point of view, it has some important advantages:

It is an open-source tool, with an open product roadmap driven by its community.
Because of providing only some simple analytics, it has a very small script so it does not affect the web speed so much.
Adblockers does not affect Plausible: it does not track any personal data or use cookies so Adblockers usually do not block pages with the Plausible script.

You can find a Plausible demo here.

So, being a software developer, I had a very good experience with these three tools so I recommend any of them if you are
in the situation of starting a website.

What do you think of this blog stack?

If you think it can be interesting for some other people, feel free to share it with anyone you want.

DEV Community: Francisco Ortiz

Little's Law: improving the lead time by reducing WIP

Little’s Law

Reduce Work In Progress

How to reduce WIP

Increment throughput

Summary

Related content

Book review: Modern Software Engineering

What is Software Engineering?

Optimize for learning

Optimize for managing complexity

Tools to support engineering in software

Summary

Related content

Pair Programming - Why you should try it

Benefits of pair programming

Team relationships

Knowledge Sharing

Efficiency

Quality

Onboarding

Communication skills

Summary

Related content

Using the DevOps second way to improve the product development process

What are feedback loops?

The two types of feedback loops

Reinforcing feedback loop

Balancing feedback loop

Feedback loops in product development

Shortening our feedback loops

Unit testing

Pair/Mob Programming

Trunk based development

Continuous Delivery

Work in small batches

Amplifying our feedback loops: look for virtuous cycles

Conclusions

Related content

From Software Engineer to Product Engineer

What is a product engineer?

They understand the product

They have product ownership

They work as a team

They offer new ideas and tradeoffs

They have empathy with users

Technology is a means, not an end

They are proud of what they do

They are ordinary but empowered people

Summary

Related Content

Cross-Team Communication: Avoid Dependencies

How cross-team communication scales

Define your team interaction modes to remove dependencies

References

How I created my blog with Gatsby, Netlify, and Plausible.

The first decision: where I should publish my content?

Gatsby

Customization

SEO friendly

Netlify

Plausible