1. The Commiters Triangle
Here we’ve illustrated a conceptual view of three of the capabilities we usually have in a team that builds and delivers software in a continuous manner.
An equilateral triangle is perfectly balanced and the way we work as a team should be too. The way we co-operate, provide reciprocity, and behave altruistically towards each other is vitally important in understanding how our work affects each other so that we can maintain the balance of the triangle.
What we want to highlight here is the importance of being aware of and understanding the work your teammates and other teams contribute. Several paradigms such as pair programming exist to foster a collaborative atmosphere within a discipline however we like to take this concept and apply it to an entire team rather than just a single discipline. We’ve found that development velocity increases and the amount of re-work and defects significantly decreases by ensuring that everyone has a chance to perform or be mindful of someone else’s role. There’s no better way to build empathy for your teammates by literally walking in their shoes. We encourage developers to write automated tests and check-in infrastructure code. Automated testers similarly should be involved in configuring or constructing their own test infrastructure and development code, whilst DevOps should be involved not only in ensuring everything runs smoothly but must also understand how developers and automated testers build their systems.
We strive to reduce the silo mentality and propensity to ‘throw it over the wall’ that often naturally evolves in a team. We’re not suggesting that everyone needs to be an expert at everyone else’s role – rather we are suggesting that by understanding and contributing to the work the rest of your team does, you will be able to perform your primary role with much greater clarity and empathy.
This doesn’t just stop at intra-team culture though. Following this mindset of ‘walking in each other’s shoes’ is vital for projects with multiple teams too. The propensity to develop a silo mentality increases as more teams become involved on a project and for a large group of cross-functional teams (some people call these ‘tribes’), sharing information, performing cross-team code reviews and testing each other’s work become fundamental ways of sharing understanding and knowledge.
We realise that there are many more parts to a team that builds software such as a business representative/product manager/product owner. We’re not trying to exclude these people from the conversation at all. They are vitally important. What we’re trying to highlight is how to shift the mindset from the siloed individual components of ‘Build’ -> ‘Test’ -> ‘Run’ to a more cohesive orchestration that enables people to learn, discover and be productive. Ideally your product or business representative would be involved in all three corners of the triangle. Or perhaps we could turn our triangle into a 3-dimensional pyramid with the business as the capstone. After all, if your business representative doesn’t know how the sausage is made, why on earth would they recommend anyone eats it?
2. Own your change all the way to production
Writing some code in the morning and pushing it all the way through to production by the afternoon is truly one of the most empowering ways of working as a developer. But pushing code into production can often seem like being pushed into a pool when you don’t know how to swim. A good continuous delivery pipeline should act as both a safety net to catch you, and a flotation device to stop you drowning if you do in fact fall in. We’ve designed the principles of Connect with this in mind. The key here is to discourage the silo mentality. Any issues with the pipeline or tests related to a particular Pull Request (PR) are the responsibility of the PR owner to see it go live to users without any issues.
3. Pipeline issues are team issues
When you work in a continuous delivery environment, you can often find yourself in a position where you’re spending most of your day maintaining the cohesion of the integration build (aka keeping the pipeline green). It doesn’t have to be like this though. Keeping your build pipeline green is a team issue. Support your teammates in helping them get code out the door. They need to take responsibility for their PR (point 2 above), but this doesn’t mean they don’t need your help.
4. Mistakes are OK as long as you learn from them
We want to foster a working environment where mistakes are not seen as flaws, instead they are encouraged. The best way to do this is to make the average cost of a mistake as low as possible and to then make lots of mistakes. This doesn’t mean you can ignore the issues that caused the problem; if there is an underlying root cause, then your team should discuss it and fix it.
Continuous delivery is all about providing a way to fail fast. As long as a mistake can be quickly found and rectified, then its cost will be extremely low. A mistake that’s found early in the development process costs orders of magnitude less to fix than one that makes its way through to production and into the hands of your users.
There is plenty of commentary and research on ‘no-blame’ and ‘just’ cultures. A just, no-blame culture is certainly something we should strive towards achieving. The obfuscation that occurs in a culture of blame is destructive not only to the organisation but also to the morale of its teams. Admitting you’ve made a mistake and fixing it quickly is much easier if you know you’ll be supported in resolving it and then preventing what caused it so it doesn’t happen again.
5. No dicks, don’t let anyone take things too seriously.
Sad as it may seem, most of us end up spending more time at work with our colleagues than our family and friends, so it’s important to create a healthy environment that encourages good, honest communication where people aren’t afraid to ask questions. This includes mutual respect for each other, keeping things in perspective and helping ensure everyone feels motivated to come into work each day. Condescending and arrogant attitudes are not welcome in any team, so if your personality type can sometimes drift into this space, make sure you have some strategies for keeping it in check and don’t be offended if teammates raise it with you. Putting yourself in someone else’s shoes can be one of the most difficult things to do but there’s no better way to build empathy within your team than by encouraging this.
6. The team is the people not the place
A team should be able to be productive no matter where its team members are located. By using a variety of different communication technologies it should make little difference to productivity whether a team member is in the same physical location as other team members.
Face-to-face communication is always preferred. Body language and subtle cues are vitally important to the communication process so even if you do spend a lot of time working remotely with each other, make the effort to get together as frequently as possible. Human beings after all are social animals and building rapport amongst your team is all about encouraging interactions and transparency. Technical problems in software development are always the easiest to solve. Software is generally a deterministic process; dealing with people, not so much!
7. It’s the team’s responsibility to upskill new members
When someone joins a team we want them to feel welcome and to be provided with all the tools and knowledge they require in order to become a happy and productive member of the team. Sadly it is often the case that when someone is onboarded they are pointed towards documentation and expected to ‘get up to speed’ as quickly as possible. This doesn’t work. The team needs to take responsibility for onboarding the new member. The new starter should be introduced to all team members and stakeholders and the the other team members should always have an open door policy to help out with tool setup and any knowledge gaps that the new member has. Sit down with a new member, get them involved and show them what you’re working on. Encourage questions and make sure you check up on how they’re going.
8. Listen. Let everyone talk – not everyone is an extrovert
Extroverted people always bring enthusiasm into the team but we must also teach them to acknowledge the good things that quieter peers can bring to the table. The key to encourage introverted people is to make them feel comfortable enough to contribute – remember, an introvert will always be listening and thinking about what’s going on. Sometimes introverted team-mates might find email or chat apps more comfortable communication mediums. Respecting our own needs and the needs of each other matters. Both introverts and extroverts must acknowledge each other’s strengths and do their best to work with them. As the saying goes, if you don’t know what the extrovert is thinking, you haven’t listened and if you don’t know what the introvert is thinking, you haven’t asked.
9. Good, lightweight process
When it comes to releasing software to our customers, it’s important to ensure a high performing team has just enough process to enable their work, but not so much that it gets in the way. Good process helps talented people get more done. Bad process tries to prevent easily recoverable mistakes. It’s also important to be aware of “rule creep”, so you should always review and constantly justify rules. Don’t let one incident create bad process, address the cause without creeping the rules.
“Bad process tends to creep in, (preventing errors just sounds good), we try to get rid of rules when we can, to reinforce the point. Netflix
10. Don’t just listen to us – make up your own!
Part of what makes a team successful is their ability to continually question and evolve the norms that govern their working relationship. Good teams will take a set of principles and apply them to their work; great teams can build on those principles and will acknowledge their own shortcomings and continually strive to make their working environment truly high-performing. We don’t attest to these principles being a silver bullet. Take them, pull them apart, rework them into your own and let us know how you get on and what you come up with!