Many times we find that we have to solve problems and work in teams (developing software solutions) and we do not have the structure or methodology to do so. In this article and the next one we are going to talk about how we have to compose and organize our work team, both from a purely functional and philosophical point of view.

The idea is to dedicate today to theory, and the next episode to practice. As I know that theory is always a bit more boring, I promise to go fast today so that we don't get too bogged down.

Everything I say from here on is intended to achieve software development solutions, although it could really become applicable to other types of businesses or structures. 

The first thing to say is that I like to work under the Lean UX paradigm. I am not going to go into deep detail about what is the philosophy and framework of Lean UX, but those of you who read me regularly will know that I use Lean methodology in almost all projects and you can imagine the main virtue of this system: avoid waste, that is, devote all our effort in improving and adding value to the product.

So, going back to Lean UX, let's first talk about its three pillars. This is a little bit more philosophical, but I want you to get a sense of where Lean UX is coming from and where it's going before we get into the meat of today, which is to talk about how we can organize our team to solve a problem.

First pillar: design thinking

Design thinking has many definitions. If you search the internet you will find many different ways to explain what it is. As I always try to be practical and not get too lost in concepts, I will define it in a simple way: design thinking is a way of creating solutions using designers' sensibility and methods.

Here I leave it, at least for the moment. May the purists forgive me, but my intention in a post is to try to explain things in a simple and quick way, so that it is well understood. I know that the design thinking The course is not my intention to deal with it now.

Second pillar: agile software development methodologies

As with the first pillar, I will limit myself to a simple definition. Agile development methodologies are a series of methods or practices that allow us to create software solutions with multidisciplinary teams. These solutions are designed to adapt to changing environments and prioritize communication over documentation.

In common words: they are techniques for creating software that allow us not to be rigid when it comes to changing developments, adapting to the needs of the project as they arise.

Third pillar: Lean Startup

Lean Startup is a methodology for business and product development that seeks to reduce risk and waste through rapid cycles of creation, measurement and learning. It is based on the idea of launching a minimum viable product (MVP) as soon as possible to validate hypotheses with real users, obtaining continuous feedback that allows iterating and adjusting the product in an agile way. The approach promotes controlled experimentation, constant adaptation and decision making based on data rather than assumptions, making it a key tool for entrepreneurs and innovative companies.

Well, these pillars give us an idea of the origin of everything we are going to tell you below. Let's look at the principles that will govern the organization and work structure advocated by Lean UX.

Principle one: multidisciplinary teams

We usually divide teams by disciplines. Developers, designers, marketing, management, quality control... It is very important to stop thinking in those terms and consider all those who will be involved in the development of a solution as a single team. 

I know this sounds complicated, but I can attest that it works. Normally these teams go for “free”, even seeming to have different goals from each other. They almost see each other as the enemy or rivals. I've heard thousands of times that of “these designers do not realize how difficult they make it for us.” o “these developers limit my creativity”... When everyone pulls in one direction, both the product and the members of the different teams suffer in the end.

We have to sit everyone down and make them understand that they are, in reality, the same team. A team composed of people with different specialties but with the same goal. The problems to be solved have to be evaluated and attacked as a whole, not by departments. This would take a whole course and I am not going to expand more here, but it is necessary to make it clear that it is necessary to work together, understanding that it is necessary to satisfy the needs of the product, and that they have several legs: usability, design, programming, marketing, quality control, etc, etc, etc. 

Principle two: small and dedicated.

It is smart to limit the size of teams working exclusively on a project. The size should not exceed 10 people, although this is flexible depending on the product or service we offer.

Lean UX also considers that members should be co-located, that is, in the same place. My experience tells me that this is ideal, but it is not absolutely essential if we have the necessary tools, predisposition and responsibility to work remotely.

Principle three: progress equals results, not delivery of documentation.

Exhaustive documentation is a thing of the past. When I started in the development world we followed very inflexible methodologies (such as Metric 3) that are based on having the whole project very well documented and analyzed and following the script to the letter. In modern development, except in very specific cases, this no longer makes sense. 

It is better to progress by delivering work than by delivering documentation. This work will help us learn and will affect future developments, so trying to have everything documented is too much speculation.

Principle four: one team focused on problems and one team focused on solutions

We will create two working teams. One will focus on problems and the other on solutions. 

Troubleshooting equipmentThis team needs to identify problems to be solved in the market. They would be the people who have contact with customers, interviewees or early adopters. From there, they will learn about the problems they encounter and will therefore be in charge of transmitting to the solutions team what issues need to be addressed, as well as their urgency.

A problem team detects needs in the market, as well as the needs of its customers. Those needs need to be solved, but it is not up to the problem team to choose how they are solved, but simply to find them and transmit them to the solution team.

Solutions TeamThis team receives hypotheses about the problems detected and is in charge of devising solutions and executing them. Normally here we have developers, designers, marketing experts...

It is not uncommon for some people to be on both teams, depending on how we have structured the workforce and their roles.

There are people who do not like the name of the company. problem equipment y solutions team, The problem team, as they believe that there may be misunderstandings. You know, it may appear that the problem equipment is a Problem and that the solutions team is the Solution to it. Personally I think this can be fixed by simply explaining well what functions each team has, but you can also change the names to any other, such as Team 1 and Team 2.

Principle five: elimination of waste

You already know that Lean is a philosophy of not wasting business resources, neither in time nor in money. The mentality of our team must go accordingly. We should not tackle anything that is not really useful when it comes to adding value to our product.

Principle six: small batches

It is easier to be efficient when we set small goals. We may be presented with problems that, on the surface, may appear to be large, but more often than not we are able to break that large problem into smaller ones. If we have large batches of work, that means more time for implementation, designs and a long etcetera. It is better to compartmentalize.

Principle seven: continuous discovery

We need to have regular conversations with our customers/users, find out what they do and how they do it. This gives us the opportunity to learn continuously, which will make it easier for us to make improvements on the product (remember that in Lean the product is not only what you sell, but also the business model that surrounds it). This also gives us other advantages, such as the opportunity to validate new ideas about our product or service.

Principle eight: common understanding

Let's give all the information to our work team. The more they know, the more they can intervene in decision making, the more they will consider the product as their own, and the more efficient they will be. In addition, it will improve inter-departmental relations, since we will all be in the same boat, with the same knowledge and objectives.

Principle nine: anti-models

We have already talked about the importance of having a united group with common goals. It is important not to have people in the team who consider themselves to be at a different level than the others. These people are usually called gurus, stars or ninjas. They have no place here because they tend not to share ideas or knowledge. We have to be like a beehive, everything works as a team and individualities have no place here.

Principle ten: externalization of work

We mean being able to present our ideas to others in some way. We need to be able to work with tools that help us to make our thoughts or ideas easily representable to the rest of the group. Whiteboards, post its, handouts, online tools like Miro, Figjam... It doesn't matter. What we are looking for is for our idea to be shareable with others, so that they can give their opinion and get inspired.

Principle eleven: learning instead of growth

This is something I struggle to make my clients understand. When you conceive a business idea, it is very difficult to grow it while learning about it. In the early stages of a business, you have to focus on learning. Then the growth will come.

Can you imagine how risky it is to scale an idea that we don't have enough information about yet? We need to learn about our product, about our customers, about the entire business model... With that information we can grow more solidly in the future.

Principle twelve: permission to be wrong

This is one of the principles I like the most. It's very common for your team to feel self-conscious about expressing possible solutions to problems because they think they might be making a mistake - of course they might be making a mistake! Of course they might be!

We all make mistakes, from the first to the last. The fear of being wrong should not intimidate us, we must be confident and expose all those ideas that we believe can lead us to the resolution of a problem. Maybe our proposal will solve the problem, or maybe it won't, but it will inspire someone else to find the right solution. Or maybe it will help us to see the problem from another perspective... All opinions are valuable, no matter how absurd they may seem at first.

Working in a team: then...

Good. Now that we have the principles clear, we can move on to the fun part: what group techniques to use to solve problems. As I mentioned at the beginning of the article, this is covered in the next one. If you don't want to wait, you can continue reading about work methodologies and how to manage stress in the tech sector. here.