In this post I will focus on the approach that is vital for becoming a high performing team. And I do not mean the particular process or framework that the team follows, but the set of spoken or unspoken rules, habits and agreements that is used by the team to structure their work across development, testing, releasing and gathering feedback from the customers. There are some common problems here that I would like to highlight.
Lately, I have been asked, what exactly do I mean, by ‘high performing software team’. For me it is the team that is capable of delivering the right software, to the right target and at the right time. By the ‘right software’ I mean one with the complexity and fidelity that match the current stage of life of the product. The ‘right target’ means that we are constantly delivering to the ‘user’ that can help us validate the idea at a given stage — more about it later. And delivering at the ‘right time’ indicates that we are thinking how our delivery can impact the business now, with the current shape of the product versus how the impact would change if we deliver later, with an ‘improved’ version of the product.
One of the key learnings for me in the past years is that a lot of the software teams fail to match this definition. In fact, all of the teams are inefficient in some way (captain obvious — I know), but from my observations, there are some common inefficiencies that are shared by many teams that make them struggle to become the best versions of themselves.
Working both in software house and as a freelancer comes with a great benefit of being able to meet and cooperate with many different teams and spotting those common patterns. I absolutely love this aspect of my job and I think that it provides me with many growth opportunities that I would otherwise not be exposed to. I have learned that solving those inefficiencies and helping teams become high performing ones is what drives me the most in my daily work and is my preferred way of impacting the business. I have categorised them in three categories: approach, tooling and software.
There might be multiple factors conforming to the long development times, but I would like to focus on two of them — low feasibility of the service (on logical or UI/UX level) and delivery of a service that does not fully fit the solution requested by business. Surprisingly, it has to do with a team approach a lot. Why? How many times have you seen teams follow this flow: drop requirements (business), create UI and UX (product designer), create some tasks (project manager), estimate, start working on them, go back with the feedback regarding the feasibility? It is bad enough if we follow this flow just for one big feature, but I have seen teams working like that on entire systems. It makes the team in this terrible spot, when someone (business owners, product designers) put in significant work to prepare those requirements and they might not be willing to go a step back and adjust them — thus team has to either spend additional time on implementing things that could be avoided, or even fails to deliver proper solution at all.
How can we, as a software team, contribute towards reducing the development time and succeed at delivering the right value at the right time?
It is also very common for the teams (and sometimes entire companies) to focus too much on what they have envisioned as the ‘final’ version of the product or the feature and some artificial deadline for delivering them. Sometimes it happens on the technical level as well — you must have heard ‘let’s rewrite this system from scratch’ more than once. This can have huge, negative consequences for the entire business. We are effectively going for big bets with our ideas, rather than validating them as soon as possible, which can help us adjust the direction. In the worst case scenario (i.e. in startups with short runaway) this can easily be a business killer, as we will usually not have enough money to sustain such a late pivot. You might think that this has nothing to do with single team, as it might be ‘higher level’ decision, however, software team can support more iterative approach in following ways:
How many times have you seen an engineer spending a week or two, without showing anything to the rest of the team? Or heard ‘I am working on task X, I have no blockers’ for the fourth day in a row during a status meeting? And then, on a fifth day, you would hear from other engineer ‘I will be reviewing code from task X’ because the amount of changes produced within those 4 days was unreviewable? One more case, specific to the frontend platforms, would be ‘I have finished Y, but it cannot be tested or viewed — backend is not ready’. Or ‘I have finished Z, but it cannot be tested without Y completed’.
It is surprisingly common, yet we tend to accept it, giving up on the opportunity to feedback each other’s work on a daily basis or unblocking other team members (i.e. allowing QAs to test even without backend work finished). Adjusting our approach this way could be potentially saving a lot of time and money in the long run.