How To Avoid TOXIC Team Culture In Software Development

Software

development

is a complex thing, sometimes the

software

we create can be simple and easy, a basic and vulgar website can be easy to write, but still, if we think about the sociotechnical dance that is required to create even a system simple like this, it is still a complex task. A complex act that, in a company environment, will at least require the collaboration and coordination of many different people for all that interaction to work effectively, is never simple; What shapes

software

and technical decisions is how we behave and interact with each other. All of this adds up to the work patterns we adopt and our default behaviors when we want to do things, the

development

culture

of our organizations, so what do we really mean by development

culture

in this sense and how do we create an effective culture that is our today's topic Hello, I'm Dave Farley from continuous delivery, welcome to my channel.

If you haven't been here before, hit Subscribe and if you enjoy today's content, hit Like too if you ask a Devops expert to explain. My bet is that it will be a matter of seconds before they mention the word culture. The Devops playbook defines an approach called calm, which stands for culture automation, measurement, and efficient sharing. I'd say you can make a strong case for all of these actually. By dealing more with the cultural than the technical aspects of how we approach our task, including the automation part, I believe that what we really mean by culture in this sense is the set of beliefs, principles and values ​​that guide our behaviors, which that defines what we do. what we do by default or as someone once said cultures what we do when no one else is looking these are the things that really characterize the approach we take to software development and these things can help or hinder us in our goal of creating great software.

Therefore, it is important for the success of your

team

or organization to direct your development culture toward more effective default behaviors. So what does that goal look like? What are the things that seem to make

team

s more successful and how do we lead something so complex and flexible? defined as the culture towards a more effective end of the spectrum, let me pause and say that thanks to our sponsors, we are extremely fortunate to be sponsored by equal experts and both companies offer products and services that are extremely well aligned with the themes which we discuss here every week, so if you're looking for excellence in continuous delivery and software engineering in general, click the links in the descriptions below to check them out in his book Creating a Software Engineering Culture.

Carl Vas defines three essential components of an effective engineering culture that I completely agree with. We want the personal commitment of each developer to create quality products. Organizational commitment of managers to foster an environment in which software quality matters and the commitment of all team members to continually improve each other Insight from this The book I liked the most was that, although you can learn from others, we cannot buy or really import software engineering culture from anywhere else, the culture Your organization's development process is unique, it's something we always create for ourselves, so you're always involved. grow your own software engineering culture, whether you do it consciously or accidentally, create an effective software development culture, then it's part of the job of what it takes to do a good job of software development, in terms More generally, this has an impact on the way we organize our work. how we hire new members for our teams, how we acculturate them, and how we communicate what we believe is good in our organizations and teams, as well as how we establish and improve the disciplines we adopt to help us be more effective in creating great software there. large differences between the effectiveness of good and bad development cultures some are quite

toxic

others are actively useful and result in the efficient creation of a better and more effective software development culture also deeply linked to and influenced by broader organizational cultures The Western model of organizational culture divides organizations into three groups: pathological bureaucratic and generative teams that do well in creating good software based on DOR metrics fall into the latter category here in terms of organizational culture, so That is the most sensible and credible goal for most organizations to create based software. in the data, but if it's not there yet, how can you start to change the culture that you have for your team, just for your organization?

There is no simple answer to this question, as far as I can tell, this is always somewhat complicated. full of nuances and difficulties, but there is one tool that I think helps enormously and which we will talk about a little later today. The problem here is that, to a large extent, culture is really about the habits we adopt that frame how we approach and understand. We do our jobs, and as we all know, habits are very difficult things to fundamentally change. The hallmark of those well-regarded generative cultures that predict high performance in software engineering teams is that they focus primarily on goals and outcomes rather than processes and mechanisms.

I rely on people to actively participate and take responsibility for their own work and adapt the way they approach their work, constantly looking for ways to improve even when they are already doing well. This is what continuous improvement really means. In this context, there are several common barriers in my experiences that limit people's willingness to start acting this way, although often managers and managed people also assume that it is the managers' job to tell everyone else what to do. and how to do it for knowledge jobs like software development. I think this is a big mistake, at best it's only half right to begin with, why on earth would you as a manager want to spend a lot of time, effort and money hiring smart people and then telling them exactly what to do? , ideas on what to do?

I could be wrong, isn't it much more sensible to hire smart people and then give them the freedom to act smartly, adapting as they learn what works best? Even telling people what to do is not really correct, at least not at the level of specific tasks or behaviors, what is much more important is to try to be clear about what the goals and results are that we intend to achieve in this way, Our smart people can be creative in trying to achieve the goals that really matter rather than simply offering an arbitrary guess about a solution we came up with earlier, whether the goal of our software development is to make more money or recruit more customers or improve the latency of our system, let's make it clear that that's what we're looking for and maybe even say how much more money, how many more customers and how fast we would like the software to be instead of defining some arbitrary assumption about a solution that can or not achieving the things we wanted to achieve in the first place if the goal of our software development is to make more money or recruit more customers or improve the latency of our system.

Let's make it clear that that's what we're looking for, maybe even say how much more money, how many more clients, and how fast we need the software to be to achieve our goals. If we know the goal, we can often organize our work to test our ideas more quickly and easily, so in goal or results-oriented cultures we want to be very clear about what we believe is desirable. The result should be, but we want to foster an environment that allows our smart people the freedom to discover and explore possible solutions that can achieve those results and to find the ones that best achieve our results rather than trying to give them some. detailed step by step guide based on our assumption of what the solution might be, of course this is all complex and nuanced, particularly for large groups there is the added difficulty of touching all the cats and pointing us all in the direction correct, so that at least they share some of the most important higher-level goals that frame everyone's choices, so open communication is another hallmark of these generative cultures, this results-oriented approach is essential for teams of high-functioning engineering in terms of software, so this goal orientation is really about being clear about what our users need to achieve with our software, we need to be customer-centric, as the old school extreme programmers would have said, so

avoid

technical stories,

avoid

task-based planning, avoid user interface-based specifications of our applications and instead we should aim to indicate what our users need to achieve with our software.

The user really wants to achieve it, not how they achieve it, and the next thing we need to do is work in a way that allows us all to see as clearly as possible the impact of our decisions and our choices. We need feedback and we need it fast, so we need to optimize development cultures where, to the extent possible, everyone can see the consequences of their choices and actions and everyone has the freedom to change things to make the team's job better. who are responsible easier and better. That's what team autonomy is really about. We want people at work to see the impact of their choices, allowing them to reflect on what works and what doesn't, and then improve it.

Surely we need guidelines and limitations within which people can work. we operate, but within those guidelines we want people to feel and be responsible for their own work ideas, as you build them, as you execute them, they are just one aspect of this type of culture in the highest performing organizations, the teams They are fully responsible for their work, they choose the direction of the products they work on, they choose the technical approaches that make the best sense for them, and they are also responsible for the behavior of the system in production according to the Westr model.

Fortunately, most organizations are not pathological, although some certainly are, but in my experience, most organizations are also not the most effective generative model, most organizations seem to default to bureaucracy, nor the worst nor the most effective option. Choice There seems to be an inevitable appeal to the idea of ​​standardizing and formulating many of these things. create some kind of production line as a rigid process to regularize everyone's work. This is actually a pretty poor approach to the kind of creative knowledge work that characterizes most software development. The move that most organizations and teams need to make then tends to be from a more bureaucratic way to a more generative culture.

This means greater autonomy for development teams and means that those teams and the people who make them up must also take on more. responsibility for your work and the decision making that surrounds you, one of the many difficulties to overcome here. is that the people who do the work are often not used to that kind of responsibility or freedom to act, they are looking for someone to give them permission to do things all the time, but we need to encourage them to take more ownership and, in to a certain extent, Help them greatly to develop their autonomy skills.

My experience is that almost everyone loves it once they've experienced it, but most people are wary at first. It simply doesn't work to simply tell people to be autonomous. I guess it would be surprising if it was strangely counterproductive if you told me I was self-employed. I'll be sitting there with my arms crossed mentally thinking that you don't mean it because if you did, I'm going to go on vacation for six months in exchange for money, so one of the tricks to generating greater autonomy is to define the limits within of which autonomy should work. You can do whatever you want, but we have to follow the rules.

You can do what you need, but. You must stay within this budget. One of my old computers used to have a ruler. We could break any team rule as long as we could convince two of the people that it was a good idea to do so in that particular development culture. Convincing people was actually quite a difficult task because we all took the responsibility of doing great work very seriously and we mainly believed in the rules. The other tool to help us achieve changes like this, although I think it is often undervalued, is programming inpairs, in particular pair programming combined with regular programming.

Frequent pair rotation. The goal is for everyone to work with everyone else on the team on a regular basis. The teams I worked on used to rotate pairs every day. We can debate the efficiency and effectiveness of pairing in code creation another time, but my point today is the impact this promiscuous pairing strategy has on development culture. My experience of working in several high-functioning development teams with and without pair programming and introducing pair programming to the teams as part of a strategy to help them improve their development. The culture is that pairing is one of the most powerful tools to change the culture of development that I know of.

Firstly, there is the obvious advantage that everyone can see how others work in more detail, good and bad. This gives everyone the opportunity to adopt the things they want. like it or to solve a problem that they would otherwise be stuck on getting ideas from other people, it also allows them to see that this is not just my problem, everyone is suffering from this problem, so maybe that gives them the idea that it's okay worth investing more time. To fix it, it's also easier to make the decision to fix something like this if you have someone else who agrees with you.

There is also a natural, low-key social pressure in a couple setting to do a good job that you don't want to give up. side down on your partner, so it encourages a slightly more disciplined approach to things without being annoying or dactic in doing so. The seemingly subtler aspects of pair programming in combination have a profound impact. I once worked with a large offshore team working on a complex system when I met them, they were working in a sort of flabby scrum process, the planning process was broken and very task oriented, with each task assigned to a specific developer by managers outside the development team, even outside the country, this meant that in effect, each development developer represented a person-sized piece of information about the software, if the developer looking after component had worked on component Pairing had an almost immediate impact by breaking down single-person silos, but also by promoting a more disciplined and consistent development approach.

Across the team, this is felt by all of us. I think the team had broken free and as a result. He was ready to take greater responsibility for his own work and the quality increased as a result driven primarily by the simple act of encouraging people to work more collaboratively in pairs. There are many other advantages of pair programming, but in my experience it is the only one. The most powerful tool for unlocking and promoting the kind of successful generative development cultures that data shows predict success. If you'd like to find out more about Peir PRI, why not check out my free practical guide on the subject?

Thank you so much. Lots to look at and if you enjoy our stuff here on the Continuous Delivery Channel, consider supporting our work by joining our Patreon community. That has many advantages and you can also learn more in the links below, thanks again. bye