What is the difference between a great development team and a group of developers? A team is something more. The members of a team share something - a motivation, vision or direction, enabling them to pull together. They have a common understanding of how to move towards the next goal. And while a group of random developers need to spend a lot of energy on communication, a well functioning development team has a foundation and a culture that makes much of the daily interactions implicit and understood. This enables them to focus precisely on solving the software problems, increasing the efficiency substantially.
How, though, can you create such a team? A lot of development teams have at least a few developers who would rather work on their own, and have clear boundaries for receiving and completing their tasks. And for these developers, it can be hard to see the immediate (and the long term, for that matter) benefits of the efforts required.
Before I continue, I should say that I do think it is very important to respect these attitudes, in that not everyone is particularly enthusiastic about "touching base", keeping in touch with "stakeholders", and all that jargon that often follows what we are about to discuss. Stay humble in your efforts, and try to persuade and convince rather than impose or coerce. Remember that in order to succeed, some emotional investment is needed from every single team member.
A common understanding
The foundation for any great functioning team is a common understanding of your shared goals. Let each team member share their understanding of the team goals, and investigate any nuances and differences in this understanding. Additionally, it can be beneficial to discuss each team members individual preferences with regards to their workday. Use this process to distill some goals that the whole team sees as important.
Refining the question of importance
For each of these goals, start asking "why?" and "how?". For example, one of the most obvious, over-arching goals is "delivering value", which again can be refined into e.g. "producing code" and "fixing bugs". If you keep going at this, and keep questioning the answers you meet along the way, you might end up with some more interesting answers. Ideally, you should continue with this until you arrive at some clear, actionable answers, such as "follow a template for issue reporting", "start morning status meetings with a quick check-in on our mood", or "writing clear commit messages, referencing issues". These actions, or procedures, will be the building blocks of your workday.
By being explicit in what daily actions are directly delivered to your goals - and exactly how - the team can gather around a common understanding of why things are done the way they are, which will have all sorts of beneficial effects. It is a lot easier to follow procedures if you can clearly see the reason they exist. Additionally, it allows the team members to gain ownership of the procedures, as they are part of their creation.
It gets worse before it gets better
A lot of the actions discovered in this way might seem corny, unproductive or just stupid, especially to team members that were not part of discovering them. And while I can appreciate them now, I remember being pretty annoyed when my team first introduced super strict commit messages. The biggest hurdle with improving almost anything is that it gets worse before it gets better. You can't really be a fan until you've experienced the rewards they yield. If you meet massive resistance, it might help to set a time limit, and review the actions together in a few weeks time.
Note that all of the procedures and actions you might come up with are subject to discussion, and few will be objectively superior. Still, it is important not to get caught in apathy, because objections can be found for every suggestion.
The checkbox pitfall
A lot of organizations, when deciding to "implement DevOps" or "become agile", have a very shallow approach where they focus on ticking boxes, rather than understanding the goal of each action that they implement (Forsgren, Humble & Kim, 2018, p. 6). I'm sure most of you have experienced this yourself, spending half an hour on an incredibly inefficient meeting where you have to stand up for some reason, or prefixing tasks with "As a user I would like to" followed by something completely technical, such as "update the API to handle downstream changes". I've touched on this in a previous blog post, but I want to reiterate the importance of avoiding this pitfall. Not only will it make your effort to transform your team futile, but it will instill a distrust and skepticism among the developers towards any further improvements to your development process.
Keep your spirits up
The process of building an effective development team is extremely important. Supported by a company wide generative culture, it is one of the most important contributors to company success within the software industry (Forsgren, Humble & Kim, 2018, p. 24).
Creating a great development team usually takes both time and commitment from every team member, and is only possible through constant effort and a supporting company culture. Don't be discouraged if you don't see the results right away, and take comfort in the fact that even failed efforts may have lighted a spark in a young, impressionable developer!
Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps Building and Scaling High Performing Technology Organizations. IT Revolution Press.
