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.
My observations
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.
Development time that goes over the roof
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?
- Engage early - talk to the business owners and designers, make sure we provide them with the information regarding the feasibility of the solution they are proposing and time-savers whenever we see them (maybe we don’t need to implement custom mailing system and other solution can achieve the same outcome with less time and money spent).
- Demo the work we do, from week one - so the stakeholders, can see their ideas brought to life as early as possible, can feedback on them and adjust the direction if needed, as early as possible (you don’t get this benefit if you choose to report the progress on some tasks, or worse - don’t talk to the stakeholders at all over the course of development).
- Release the work we do, from week one - so the stakeholders can not only see their ideas, with our commentary, but can also ‘touch’ them - which helps them even more in understanding what the end customer will see and feel, when using our product (it is hard to verify whether the UX we have designed is ‘correct’, just be watching the video of the system, presented by some developer).
Delivering value to the users in big chunks
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:
- Make sure that deployment and release are two separate processes - so it is easy for the business to make a decision to go with what we currently have deployed, hit one or two buttons and release the feature to the users.
- Allow business to target releases towards a subset of our user base (maybe the decision to release is not a ‘big’ one, if we can release to 2% of our users).
- Use the tooling that allows you to comfortably work on ‘unreleasable’ features and still continuously deploy current work to the users, so the 2 points above are possible without changes in the codebase itself.
- Feedback ‘product’ decisions and suggest the solutions we can apply, to validate our work with users as soon as possible (maybe we don’t need the ability to login through socials from day one, considering implementing them will take two weeks more?).
Lack of individual members progress visibility within the team
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.
How can we, as a software team, be more agile when it comes to our daily work?
- Introduce a high level of granularity into our work - don’t think about the entire feature that will be the final result of our work, but rather focus on smaller parts that we can deliver on a daily basis.
- Make sure that this granularity is applied on a level of entire ‘sub-functionality’ - rather than delivering networking layer, ui layer and logic layer as separate chunks, deliver credentials inputs, terms and conditions acceptance, login happy path and error handling - as each of those could be considered a fully functional feature on their own.
- Apply such granularity not only on the stage of creating the code responsible for handling those functionalities, but also in your testing flow (make sure that those bits of work can be deployed and tested by the manual testers or other team members).
- One more time - have the right tooling and software, that make working in such a way possible.
Keep it agile
Such a clickbait of a paragraph, I know, but bear with me for a few more words. ‘Agile’ as a term has been used in the EB and marketing content so much over recent years, that we have gotten overfed with it, however, if you look in the core principles from the agile manifesto, you will see such sentences: “Deliver working software frequently […]”, “Business people and developers must work together daily, throughout the project.”, “Working software is the primary measure of progress.”. They are over twenty years old, yet they still remain so much up to date and the approach I have conveyed in this post, attempts to bring those ideas to life - I strongly believe that conforming to this approach, is the first, major step towards becoming a high performing team.
Tooling and software
I have mentioned it earlier, but I would like to emphasise it again - you need to have effective tooling and a codebase that allows you to work this way. Otherwise, even with all of these ‘good’ practices in place, it might be hard to introduce this approach in the daily development, and as a result, the team will still struggle to become a high performing one.
So how does one build a high performing team after all?
It all starts with the approach of the team, make sure that it has some of the key traits I have mentioned. Keep a high level of collaboration with the product - make sure team’s work can be viewed and touched. Ensure that every single developer within the team works in small iterations, so the feedback loops are small. Make it easy to deliver value to the users - split release and deploy processes, make those decisions safe by making it possible to target a certain percentage of the user base.
