Article originally posted on InfoQ. Visit InfoQ

Many people in the software industry – especially on the testing side of things – have often been asked, “So, what’s your testing process like at *insert company name here*?” People want to know what your processes are at your company; either out of genuine curiosity, a search to find a fit for their skills, or to find issues in it that they think you could solve by changing “just one thing”. But what happens when the answer is “It depends”?

Many organizations in the software industry have fallen into a state where they have set processes that are used across the organization and teams. There’s a specific approach to be taken to development, to testing, to deployment and more. But most of the time there is one set process for each “step” in the process. The issue with this is that every team is not the same, so why are their processes all the same? 

In this article we’re going to explore what it can mean for teams to have individualized processes that are formed by the context of the work they are doing and of the team itself. What does it mean to have different processes? What can you gain (or lose) from this approach? How can you determine if they’re right for you? Where do you even start with attempting to move towards individual processes? And how do you set your organization up for success while moving away from a unified approach? These are all questions that we’ll be answering in the coming sections.

What exactly are individual team processes?

Individual team processes are processes that are specific to the context and the needs of a given team. Every team is unique; from the work that they are doing to the individuals who make that team up, there are contexts and skills that vary from any other team you have within an organization. Due to this, having one set of processes that every team needs to follow can be detrimental. 

A clear example of this is a UI-focused team vs a backend-specific team. Those two teams have different requirements and different expected outcomes, so if they were to follow identical processes, there would likely be overhead that isn’t necessary or gaps being missed. The UI design team processes may have a step for designer review of new UI components, but that would just constantly get skipped by a backend team. Meanwhile, the backend team may have requirements on security testing for different types of attacks that would never apply to the UI team. By letting them define the processes which make sense for themselves, they can ensure they aren’t wasting time and they can focus on identifying their own gaps and improving their processes for their context. 

It’s also important for these processes to have the ability to evolve over time. As priorities within a project change or the members who make up a team change, their processes may need to shift as well. By allowing teams the autonomy to control their processes,it enables them to review them regularly and make the necessary changes to ensure there are no gaps or tedious overhead slowing the team down. This ensures that the efficiency they have curated remains over time.

One thing that is important to note about individual team processes though is that they should never be completely unique. There will always be overlap between teams in certain areas. For example, every team likely has it in their development process that their code is reviewed by another team member. This is very likely an organizational requirement in most companies. So this is going to appear in every team’s process, which doesn’t mean that teams don’t have individual processes anymore; it just means that there are still some common aspects which are better for organizational alignment. It’s the addition and removal of non-required pieces to suit the context of the team that make it an individualized process. 

What are the risks with this approach?

Although there are other risks to working with individual team processes, the biggest one is a lack of organizational alignment. For example, if you have teams who are so focused on having their own process and being completely unique that they try out a “new” test framework, but don’t share that information, you could have another team doing the same thing and doubling the effort it takes and sharing none of the lessons learned, challenges, tips and tricks, etc, to getting that framework up and running. It’s important to make sure teams understand that they have the ability to choose the processes that work best for them, but that they don’t have to be brand new processes. Learning from other teams and being able to leverage their insights and bringing on processes that have been tried and proven helps everyone, and can still fit the context of your team just as well as others, so without that alignment and sharing individual processes it easily becomes more detrimental than beneficial. We’ll explore ways to reduce this risk more in a later section as well. 

Some of the other risks that are always worth considering are a potential lack of transparency into the processes, confusion on teams as you shift processes, increased ramp up time for inter-team moves, and difficulty in tracking audit requirements. Some of these risks are especially prevalent in companies with strict contractual obligations. For things like missing audit requirements, you can alway ensure those are present in all processes, similarly to how I mentioned requiring code reviews above. Most of the other risks also align back to the lack of alignment, and by ensuring that there is a good foundation for sharing information and discussion amongst teams, you can address those risks as well. Although they add to the work required to make individual processes work, it can still be done if that’s what the team is committed to.

What are the benefits of individual team processes?

The benefits that teams can see from introducing these context specific processes range from things like increased efficiency, which benefits the organization and customers, to an added sense of ownership for the individual contributors on a team, which benefits employee satisfaction and growth. 

By letting teams have additional ownership and a say in the processes that make up their day-to-day, we usually see an improvement in the quality of the features being produced, increases in their efficiency, increased satisfaction with less frustration from processes which don’t align to their needs, new innovative approaches being taken in terms of tooling and frameworks since they can explore more easily within those processes and added flexibility to adjust to changes. This list is also not exhaustive. These are the common benefits that I’ve seen on almost every team that I’ve worked on with this approach, but some teams see their own benefits like increased communication within the team, better alignment on goals etc. 

I think for me the biggest benefit that I see on teams, personally, is the reduction in friction around testing and quality conversations. When the requirements for testing and quality fit the context of the work the team is doing, then they are much more open to those processes. They can understand the why behind the approaches we take and it helps things to move much more smoothly. I’ve seen a very positive shift in the attitudes of the entire team to the testing processes when they are able to define the ones that make sense and work for them. 

How would I know if individual team processes are right for my team?

Determining if individual processes are the right choice or the right fit for your team is a crucial step. No matter how interesting they may sound or how excited you may be to implement them, it is important to consider the current context of the organization and teams within it before you attempt moving to individual team processes. So, I’m actually going to start with some of the indicators of a potentially bad fit. 

Some of the biggest indicators I have seen for individual team processes not working well in an organization are: having strict contractual obligations, having strict waterfall processes, having a very tightly coupled architecture, and already having issues with inter-team communication. The reason that these are the biggest red flags usually for teams is that when you have stricter processes and requirements, it can be easy for things to get missed as teams move to their own context-specific processes. Especially when there are already issues with communication within an organization, teams may not be aware of why certain aspects of processes need to stay in every team and they could remove them which can cause large scale consequences. 

An example of this would be a company working with medical data files, based on government regulations. Very strict processes need to be followed for privacy concerns. Organizations with a tightly coupled architecture can also experience issues when teams are not in alignment on required processes or coverage, which again is made worse when there is a lack of communication. In order for teams with this setup to thrive with individual team processes, there needs to be a very healthy level of communication between all teams. 

But, now that I’ve talked about situations where individual processes may not be the best fit, how can you tell when they will be? The best indicators that individual processes are a great fit are: having autonomous and high functioning teams, having or moving towards a decoupled architecture, having teams who are frustrated by an inability to try new processes or by overhead, and having some teams who are already starting to do this. 

I’m going to start by digging into that last point. In so many cases, teams are already doing this in some way. If there is an organization-wide process where certain aspects don’t apply to that team, they may already be telling new employees to just skip over that section. Or you hear them talking frequently about things that don’t apply to them. This means that the team is already moving toward defining their own processes, but without the ability to make it common practice. They’re already doing what they need to in order to identify overhead or gaps in the existing process and make the necessary changes to better suit their needs. This shows strongly how well they could benefit from having individual processes. 

Going toward individual team processes

If you’ve been convinced to give individual team processes a try, I strongly suggest slowly working towards them. Trying to rush towards instantly letting every team define their own processes can cause some of the risks discussed before to present more readily. By slowly moving towards this approach, you can identify issues and address them as you work towards that goal. 

The first step is to define the current process. By making sure that everything is well-defined, the current approach sets teams up to identify any gaps in those processes that they have or need to add in additional processes to fit their needs. Once the organization-wide process is defined, teams should review it and add to that strategy any extra steps needed to fill those identified gaps. Once that is completed teams should share those additions with other teams to see if they would benefit any other teams. 

Once teams are comfortable with the organizational approach with their specializations, they can start to work on removing pieces. They can do this by reviewing the current team process again, but this time looking for any steps which do not meet the needs or the context of the team and removing them from the process. Once teams have identified these steps, they should share these changes with other teams to get feedback to ensure that these steps are not required by some contractual obligation that the team wasn’t aware of. At this point, teams have an individual team process which fits their context! 

The last step for teams though is to start to review these processes on a regular basis. By reviewing them for both gaps and overhead regularly, the processes can continue to evolve as the team does. As requirements and the team members change reviews, ensure that everything is still aligned to the context. As always, if changes are being made in the process, those updates should then be shared outside of the team.

At that point, teams will be working with individualized team processes. From that point they should monitor for benefits that they are seeing from this approach and make sure that they are checking in with all teams regularly to ensure this approach is working and that all teams are still in alignment. 

How can we set ourselves up for success?

Since we know that a lack of alignment and cohesion are the biggest risks to maintaining healthy individual processes, how can we tackle the risk early and set ourselves up for success? I generally break it down into three suggested approaches: documentation, shadowing and communities of practice. 

Having up-to-date and comprehensible documentation of team processes is very important. Documentation not only allows other teams to learn about your processes, but it allows your team to verify that you are all on the same page about the processes you have defined. It’s important for the team to revisit this documentation on a regular basis to keep it up-to-date and accurate, to share updates when you make changes to your processes, and to ensure that it is in a publicly accessible spot for alignment amongst other teams.

Shadowing is a great way for other teams to get a more personal look into your processes and to understand whether or not they would be a good fit on their team. By having two individuals pair up and shadow one another as they work through the development and testing processes, you gain better insight into how those processes look in action and this can help to address any gaps that may exist in the documentation that should be recorded. 

The last piece is to have communities of practice. These are usually an open forum where individuals are able to discuss topics around a given initiative. I like to break communities of practice down into role-specific communities. So there may be a community of practice for testing and quality, for example where teams can come to share ideas and information about those topics. These become an ideal location for teams to discuss their processes (development processes in a development community of practice, testing processes in a quality community of practice, etc.). They establish a safe space to discuss wins, challenges, tips, etc., and allow other teams to see if new processes being pioneered on other teams could work for their team’s context as well! 

Although you could go with just one or two of these approaches, I have found that they are best used all together. They allow individuals to learn in the environment that suits them best. For example, some people learn best through reading, some through one-on-one conversation, and some enjoy a larger group setting for discussing these topics. By combining all three you are best set up for success! 

So what does it all mean?

At the end of the day, there are many benefits to having teams working with processes that are defined by the context of their work and their team. But, like many things in life and the workplace, they also take work. 

By allowing teams to create and establish practices that fit their context, you enable an increase in team autonomy, efficiency, and the quality of the work being produced. It allows for the processes and practices used on a team to grow as the team does, and enables teams to experiment and share more with other teams in the organization. Teams will also see a decrease in frustrating overhead or trying to adhere to requirements that just don’t make sense for what they do in their day-to-day. By putting in the work and allowing teams to take more control of their approaches, the teams, the organization and our customers benefit.