Teamwork is not the last part in software development. Why?

Well, my experience is not that big, but i can say for sure - bad teams build bad software. And these bad projects have similar traits.

No leadership

Have you ever worked in small SCRUM-like team where everyone’s impact seems to be equal? I’m going to tell you one thing: the impact is equal because no one is doing their job. Like everyone is doing 0 job.

0 job * 10 members = 0 result.

Chaos, unhandled tasks, ego-harm, very poor decision making, low quality of made tasks. In Ukraine everyone talks about SCRUM, but no one uses it as it should be applied to our cases. Strong technical leaders just to control what is going on at project, just to make everything clear, just to code super-complicated parts on their own. This way also sets the habits for the rest of the team. People learn by example. Technical leaders have to set the example for others to follow, they have to lead the team. Actually, most of programmers I’ve met just can’t go on their own, they simply need a leader who will tell them what to do and how to.

Responsibilities

As I mentioned before, people need to know what they have to do. Otherwise, they will just pass the bucks and blame each other, so our developing process is going to be much longer.

That’s great to give people opportunities to do their work as they want to do. Just as SCRUM says. But they must be professionals for such way of team-work. Give them opportunities that have a high level of expectations.

Test or die

No one likes to do unit testing, integration testing, not even “have you ever launched it on your machine” testing. Actually the code gets copypasted from StackOverflow, compiled on local machine with some simple inputs, just thinking “god please make this work”. Well, that’s how software is made for now. As a result you get fucked-up product with one billion of bugs and unhandled edge cases. Write tests, fella.

Toxic members

Probably, I am super toxic person.

You can be good at writing code, but bad at communicating with other people. You have to change. Or die.

We are not in 2000X, now big player companies provide service of making software. Software is made by people to people. P2P. Just make sure that you don’t have toxic players in your team. Or atleast try to handle them properly, they are not made of glass, chill.

Sometimes people become toxic because of lack of leadership, communication, programming skills etc etc etc. Sometimes they are just burned out and don’t want to make maximum impact. And sometimes they are just toxic and you just have to live with that, there is no way of changing them.

Perfect is the enemy of good

There are a lot of cases of good startup ideas that fail at doing their product perfect for the first release.

Actually, they need to write something like user-stories, which will help them to define Minimum Viable Product. Implement it, write small amount of code and good tests for it. Release! Then get feedbacks, catalogue feature ideas to implement, compare it to user-stories. Priotirize them, implement in value/time order, test.

If you don’t go this way, you may end up with unrelevant half-made product and a team full of hate because they won’t see real results of their work.

Did you ever had such troubles in your project? Does your current project has one of this traits?

You are in trouble, but don’t panic. I suppose, the best thing about trouble-handling in team is communication. Just sit and listen what your team members think about these problems. Make a solution map? If this won’t work, then get a new team. Otherwise you will end up building crap and hating enterprise programming like most of software developers in Ukraine do. :)