Top 5 challenges of building an effective software team
/1. Finding the right people for your team
This is without doubt the hardest challenge. Finding skilled software professionals is hard, but find the people who work can work together is even harder. Although this is the hardest there is no way around it. The success of any software project depends on one factor - how good the team behind it is. We know this from our experience in working with 100s of software projects over the past 18 years, but research and data in this area also shows this fact. In their comprehensive study of software project failures published in Software Development Failures: Anatomy of Abandoned Projects Ewusi-Mensah, K. showed that factors related team composition and team dynamics comes up very high in absolutely every single software project that has failed in their group. Similar connection with team related factors are found in other studies too. A good summary can be found in a paper titled core factors of software project success.
Table comparing softwre project failure causes from paper: https://www.researchgate.net/publication/330290988_Core_Factors_for_Software_Projects_Success
You need to focus both on the skills of the individual resources and the fit of the resource between each other to find the right team. A mix of skills is very important, so as you are composing the team work on looking at individual potential candidates and map out their skills - both technical and soft skills. Find a balance where you have various technical skills spread out along with the soft skills. An example could be that for a web development project in .NET you should look for people with core .NET programming skills but also add people with database, javascript, UI/UX skills. And again on the soft skills front you should have some members of the team who are good communicators, some who are good mentors and some who can run a debate well.
2. Getting your software developers to communicate effectively
Once you have the right team your next big challenge is to setup a system, a workflow and a culture where commutations happen in a flexible and free form way. You want multiple channels of formal and informal discussions. You’d want formal structures like team meetings and brainstorming sessions coupled with informal channels like a talk in front of the water cooler. At Kaz a great place for informal communications is the team’s own break space - we call them ip - interaction points. Sometimes it’s a veranda with some chairs where team members take their tea/cigarette break and has a chance to discuss something that’s bugging them (sometimes its about the the project too!).
It’s vital that your team should communicate effectively. Many a great software team has produced failure by the fact that the management made it too difficult to communicate - maybe with too many formal meetings or too few.
It’s hard to suggest a winning formula that works for every team as every team is different, every project is different. And add to that mix the WFH and remote work you have an even more complex problem. Work with your team to make sure there is effective discussions happening. Check back regularly on the health of that communications.
3. Developing a process that works for everyone on the team
Once you have the #1 and #2 sorted out you are half way there. The rest is pretty standard operations setup but it’s still super important to get things right. The top thing on the operations part is setting up the workflow.
A software development workflow involves all the nitty gritty steps of getting the software requirements, specifications, planning, distribution of work and then getting that work done in phases. The catchall word for anything related to software development workflow these days seems to be “agile”. But saying “agile” is not good enough. Setting up a workflow - if it’s driven by the concepts of the agile methodology that’s great - is important. Again, the thing to remember is that every team is different, every project is different and every company is different. The “agile” that’s right for you might be different from the “agile” of a different team or company. Plan the workflow that fits with your circumstances. For example, if you working on startup’s proof of concept project and entire future of the startup depends on showing this POC fast to it’s investors so that they can get some funding to actually build the thing - having a complex process for creating and tracking tasks that has to be reviewed at multiple steps is going to be a disaster. You’d want a process that is fast, relies mostly on verbal communications and commitments and almost no red tape. The opposite would be true if you’re working on upgrading an existing ERP that a large number of customers relies on it’s day to day work and single breakdown can lead to a lot of trouble fore everyone.
4. Creating an environment where every member of the team feels valued, respected, and included
In the mode of efficiency and engineering that software projects tend to push us we forge that at the end a team is a just another group of people. They are no different than other groups of people in our daily lives - each with their own needs and desires. It’s vitally important that in the hectic pressure of the the project, the need to find great resources and in creating efficient workflows we don’t forget the fact that the team members individually and the team collectively needs to feel valued and respected.
The worst offender in this space is the high handedness management teams sometimes use to operate with development teams. They somehow feel that they need to command and control the teams - which just doesn’t work in the creative and intellectual space that software development projects work in. It’s important to we aware of this danger of detachment from reality and keep honest reviews on the company’s attitudes and processes to make sure that the team feels happy and motivated. Remember that in software a demotivated team is directly equal to a failed software - there is no mid point in this equation.
5. Balancing what's best for your company with what's best for the team
The last point is a delicate one. You might have the best resources, you might have a streamlined process with a healthy team motivation in place but you are still operating within a business. A business has priorities and typically it’s about money and short term goals. These priorities will always clash with your team’s health. Short term goals will mean over working the team, it might mean a burnt out team and it also might mean that team members pushed around various things in their project (something that developers hate). It’s not an answer to say that I don’t care about the goals of the company - as those very same goals make the ends meet and get the funds for everyone to live. And on the reverse it’s also not an answer to say that we’ll sacrifice the good of the team to make the goals of the company work. There has to be a balance somewhere. The team will have to compromise on certain things (e.g. maybe a special impossible deadline for funding) and the company will have to compromise on others. If you get the balance right you’ll have a wonderfully efficient team in place.
OK, lots of heavy stuff. Let me finish off with a stolen Dilbert :)
