As the saying goes..

This is undeniably true, but there is also no WE in TEAM either. However there is a ME (sort of).

So what does this mean? Does it mean that the team is less about individuals or groups of individuals and actually about thinking what you can do to help the team? Well yes it does actually, but what it more likely means is idioms are pointless.

But there is a serious point hidden in there about the way we deal with our own ambitions and desires while working as part of a team. For me this comes down to Ego. Thinking back to my college psychology course, the Ego effectively represents the selfish part of the individual, which is concerned only with the individuals own desires and needs. It looks to manifest the individual’s base desires (which come from the Id) and isn’t concerned about the social and cultural rules governing us (that’s the Super Ego). This isn’t a psychology blog though so excuse any worryingly inaccurate statements!

Anyway, what’s this got to do with software development? Well, I think there any many times when working in a software team that the Ego seeks to take control and to be the best worker and team member you can be, then you need to try and swallow your pride, check your Ego and do the best for the team.

I’m going to list a few examples from my experience.

I’ve always been and I’m always going to be a tester first so one practice that I’m a big proponent of is a test first approach. This might be Test Driven Development, Acceptance Test Driven Development, Behaviour Driven Development or some other technique but the key is that the test scenarios are created and defined up front and that in some way they define the requirements of the feature you are implementing. This kind of approach has lots of benefits for the team, for example:

However a test first approach does not come easy to many software engineers, especially if you’ve been used to non test first for a long time. Consequently a lot of people will be against the idea and potentially be concerned about trying it. This is the Ego talking. If there are benefits for the team, then as an individual you need to be prepared to try it and potentially adopt it.

I think it is fair to say that software development has in the past been a practice that can be done by many individuals working on single items, then putting them all together. More and more these days though, teams are working with a model that allows multiple people to work together on the same feature. This kind of collaboration can have short term and long terms benefits to the team, a few of which are:

• Multiple people working on a feature means the knowledge of the feature is shared with more of the team
• Individuals can learn techniques and practices from other team members
• Team members can build relationships quicker
• Code reviews can be done during the pairing
• “Code Blindness” can cause problems to be missed – more eyes makes this less likely
• Allows a tighter focus on the scope and requirements of the feature

There are many different levels and types of pairing (I might do a separate blog on this actually) including developer/tester, developer/developer, shared controls, single controls, remote sharing and so on. All of them have differing benefits but the similarity between them all is that the benefits are generally focused on helping the team.

This kind of working does not come naturally to a lot of people and it is very easy to avoid doing it because it does not sit well with the way you work or your personality. But this is where you need to check your Ego. It’s not about you as an individual but the team. If your team can benefit from adopting these approaches then you should be prepared to support and promote these ways of working.

There are many different aspects to developing a feature for a piece of software from the initial creation of the feature/epics/stories through to the deployment of the software in to live and the monitoring of it going forwards. Consequently there are many tasks that a self reliant team will need to complete in order to say a feature is Done. I can’t list every one as that will depend on the team, product and company however a few common ones might be:

• Creation and refinement of the stories
• Creation of and execution of automated checks
• Maintenance of and execution of existing checks
• Modifying the existing pipelines
• Updating the monitoring
• Updating the infrastructure (manually or via code)
• And…writing the product code

As an individual you may prefer some of those tasks over others but you have to put this aside to complete the tasks that best enable the team to complete the work they have committed to. You may also find that individuals are better skilled at some of those tasks than others however if that’s the case then you will always have blockers and single points of failure within the team so what is the best way of helping the team? It’s by the weakest person for that task taking it on, pairing on it and learning as they do it. In the long term the team will massively benefit from this approach. As an individual this could be frustrating when you know this isn’t the quickest way to complete a specific task but this is again when you should be checking your Ego and doing what is best for the team.

When working within any software development team, no feature is adding value to the customer until it’s been Done. Whatever your definition of this is, it must meet it to be delivered to the customer.

With that in mind the focus of the team should always be delivering done or completed features to the business. Anything else will not give the business a return on investment yet. Therefore the team should always have a focus on “working from the right” or looking to do what they can to complete features before they start new ones. As an individual it can be hard to buy in to this mindset because it’s hard to work with others to complete something that is already started. It’s much easier to start something new; but that’s the Ego talking…

I’ve listed above a few common scenarios where it can be easy to do what’s best for the individual instead of the team. I feel I should declare that not all of the above approaches are ones I like to do as an individual either but I do support them due to them generally being better for the team.

I fully appreciate there are occasions when a principle cannot be followed and pragmatism must come in to it. For instance you can’t always have an individual working on a task to upskill themselves. I do believe this is generally best for the team, but if it’s the end of a sprint for example and you need to get something out, then maybe that’s not the best time for it.

You must absolutely be pragmatic when deciding how the team works and when considering what practices and techniques you as an individual will choose to promote within the team.

For me, it always comes down to one question you should always be asking yourself and if you can honestly answer with ’the team’ then it’s likely you are doing the right thing: