DEV Community: David

Let your team make errors

David — Sat, 24 Apr 2021 17:05:55 +0000

"Teamwork is the ability to work together toward a common vision. The ability to direct individual accomplishments toward organizational objectives. It is the fuel that allows common people to attain uncommon results." --Andrew Carnegie

If you asked me what was my biggest error as CTO, I would say it was managing my team too much. I guess you could call it micromanagement. It is not an excuse but from one day to the following I took a lot of responsibility and I got crazy with my teams. I wanted to control everything, I assigned every issue, I tracked all the work in progress, I was aware of any problem. All this every day until I gave up.

I realized I was doing it badly, I made the most common error that everybody starting with Agile makes, not trusting my team. You don't need to worry if they are working harder or if their decisions are the best or… no, no, no, you must focus on product quality and goals accomplishment. Let them make mistakes! If they make the wrong decisions, if the code quality is poor the throughput will be affected because to make changes will be more expensive and the todo list will be polluted with bugs, the team will note it and you too, and together will have to seek for solutions. If the team is not able to reach a sustainable pace, you will have to help them. You should be next to the team when they fail and they deliver zero value to the rest of the company or the client. But that is all.

Some important thing: you must share a common vision with your team, you must agree on common goals for the iteration, you must provide support for every problem and the most important you must work with professionals not with children pretending to be professionals and believe me this is the most difficult thing, but without it to have a trust relationship with your team is impossible and that is the base of everything else.

SCRUM can't fix your broken culture either

David — Sat, 24 Apr 2021 17:05:10 +0000

I was having a coffee with some mates, we were pointing at all the things we can't stand in our company. This is more a drill since our boss is unable to take action based on our complaints. It's a way to mitigate our frustration.

Suddenly from the bottom of the room, we heard: "Why are we not using SCRUM? it will resolve all our problems, won't it?". After a quick silence, everybody started to discuss if we are using SCRUM yet, why and why not and all this kind of stuff that really bored us.

One of the worst thing SCRUM, and Agile by extension, have brought with them is the idea that practices and rituals can fix your broken culture. From my view, to believe that some processes described in a book are going to solve problems which you can't fix is a very naive idea. In this particular case is an example that this person has understood nothing.

To make SCRUM work you need to build a culture based on confidence in every member of the team, between client and team and business people and team. Before that, you need to build a multidisciplinary team of professionals and again that is not the goal, but it is the vehicle to achieve our goals. Even with a team, even with a trusted relationship, the application of SCRUM can still fail. You have to lay the foundation before you start to build.

The good thing about Agile is it could help you to build these kinds of teams and relationships. You can use the practices and rituals described by the people behind the acronym and get some success but the most important thing is to interiorize the agile principles and to understand the gist of these practices and rituals, in this way you will be able to adapt them to your context.

In this industry, there aren't silver bullets nor shortcuts and you will have to deal with other people.

"It's much easier to convince the processor to do what I want than some people." Marko Poutiainen

Divide et impera

David — Wed, 01 Jul 2020 12:47:52 +0000

I would say the most important thing I learnt during the time I spent studying the Engineering degree was the "divide et impera" principle. I strongly believe this is one of the most important skills a developer must have.

Always when I am struggling with a problem it turns out that it hides more than one problem. And this is something I usually see, many bad designs, disfunctional teams, micromanagement, etc. All these are faces of the same coin: the inability to divide problems. When you try to solve a complex problem that in reality you are not applying the best solution and you come out with a partial solution that in the end is going to bring you more problems.

It is very common to mix problems of very different natures. This way we have problems that hide a mix between technical, management and client relationship difficulties. Sometimes you are able to divide these problems but don't have the courage to face them and you try to solve a disagreement with the client by offering a technical solution. You can do it but sooner or later it will just end up biting you.

Always you say we don't have time to do this or that, you are adding a new and different problem to the current one. Time is not a technical problem, time has nothing to do with finding the best solution to a problem, time is a management problem and you should solve it negotiating with the client, reducing scope, etc. You shouldn't look for a worst technical solution to save some time. Don't get me wrong, sometimes you have to acquire some technical debt but you must be aware of that decision and pay it as soon as possible.

In my experience, breaking down problems and selecting the best solution for each one ends up being the best and straightforward solution.

A private conversation

David — Wed, 17 Jun 2020 15:00:38 +0000

I have the bad habits to share everything with my team, expose my problems, ideas, advices anything through a public channel whatever tool we have chosen. However, I can understand that for some people, shy people, it could be a bit hard so I do my best when someone initiates a conversation in a private channel with me and take any excuse to move the conversation to the public channel. That is fine and is part of the process to build a team. What I wasn't expecting was that making all this information public could be overwhelming or even annoying for some people, usually people that hold high positions in the organisation.

I was thinking about that, about the reasons why it is so frustrating for these guys and the reason that it is gaining more weight is that they prefer to hide the dirty laundry. The motivations could be multiple but, in my opinion, it is an attempt to hide their own incompetence, if they are not able to fix the problems that arise in these conversations they choose to swipe them under the carpet.

Privacy is good, I am a big defender and a practitioner but when it comes to building a team it is really bad. Communication is key, in a remote team even more important and to hide information leads to misinformed people, and misinformed people usually make errors. I am not going to boring you with a long list of mistakes my team and I are doing all the time thanks to following strongly this bad practice but I am sure you know what kind of errors I am talking about.

The path to building a team is painful and frustrating and sometimes fruitless but it is worthy, so if you are in my skin right now, I strongly encourage for you to continue doing what you are doing. I believe it is a big improvement and remove some waste on the way but, don't fall into the same pits you are trying to fix, to give an example is a great mechanism to settle down a new practice, again communication is key, so be open with your team and all the people affected by this change, explain why you think it is important, listen to them and please share with us how is it going.