Why One Size Does Not Always Fit All

“So, what’s your testing process like at *insert company name here*?”. We’ve all been asked this question. It comes up all the time when you tell someone that you work in testing and who you work for. People want to know what your cookie cutter process is for testing 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”. What happens when the answer is “we don’t have one.”?

Teams and organizations are slowly moving away from the monolithic processes for their development teams and allowing teams to forge their own paths forward. By allowing the teams to set up processes and practices that make sense for the context of not only the project that they work on but also on the context of the experience of their individual team members. This individualized process approach has a lot of benefits for those teams as they get rid of the overhead that slowed them down in the old process as well as fill in some of the gaps that are unique to their team, but it can also cause a disjointed feel among organizations. So how can you get your organization to work effectively with individualized processes?

First of all, let's define what I mean by teams having an individualized process. I don't mean that teams are making up their own new methodologies to the degree of Kanban or Agile, I mean that they have individualized the ceremonies or processes that fall within those methodologies. For example, some teams have moved away from having testers, some have their developers perform the majority of the testing, some have retros bi-weekly while some only need them every month or two, some of the teams I've seen aren't working on automation at all and some have it as a requirement for code to even be merged. It's all about the context of the team and what works for them. Teams that are working on critical software and can't afford to have it go down in production have more rigorous procedures in place whereas teams who are working on a project before it's initial launch are a little bit more lax in the way that they approach their procedures. It's also important to note that individual processes don't need to remain static. They can be constantly evolving as the team does and that they may eventually adopt the same processes as another team either in part or in its entirety if they are working on similar projects or in similar spaces. Having individual processes shouldn't mean doing something completely unique every time, it just means picking what works for you and sharing the why's behind those processes for other teams to learn from and potentially adopt alongside you.

So, let's talk about individual process, whether or not they're a good fit for your company/team, and how to handles the challenges that can be faced when you're working on teams with individual processes! Or, if you're already on those types of teams we'll look at tips and tricks to help address some issues you may be facing.

Benefits & Risks to Individual Processes

Like every tool or process that you can bring into a team there's always going to be some level of risk or challenge that comes along with it. Using individualized processes on your teams is no different. It comes with lots of benefits but there is always a trade off to be made and effort that needs to go into it to maintain those benefits over time. Monolithic processes may seem tedious but they also allow for easy alignment across teams and across an organization which is usually especially appealing to the higher levels of an organization, so it's important to understand the whole situation when trying to sell your company on allowing for individual processes!

Let's start it off with the negatives, just to get them out of the way. There's risks and challenges to moving away from a cohesive structuring for your processes. In the same way that it can be a challenge to have some teams on Kanban and some on Agile but with the same release schedule it can be tough to organize and reconcile information across teams when they have their own procedures in place for the way they do things. Some of the most common risks are:

Lack of transparency into processes. With teams moving to a more flexible and iterative approach to their processes there can be a lack of transparency at many levels into what a team is doing.
Confusion with changing processes. It can be confusing even on the team to stay aligned on what the exact processes are especially as they evolve. This can be especially tough when moving through an iterative phase or for new team members without any process documentation
Increased ramp up time for inter-team moves. This is a large pain point in larger organizations where one of the benefits to having a single process is that it also allows for efficiency in inter team moves, allowing someone to move to a new team and easily be "ramped up" on what is going on; obviously this is more of a challenge if each team has their own process in place.
Difficulty tracking audit requirements. Another common issue for larger companies or companies in security industries is the potential lack of tracking for audit purposes. There may be contracts with explicit criteria set for data tracking etc. which needs to be taken into account and could be missed with individual processes.
Lack of cohesion among teams. The final and likely most common issue for companies is that there is a lack of alignment across the different teams in their organization. This can cause duplication of tasks being performed, inefficiency at higher levels and result in a disjointed feeling among the teams themselves and a lack of connection.

Although these are all potential risks to moving to individual team processes they are all manageable and can all be worked through as we will discuss later, but it's important to be aware of them nonetheless.

So we've gone over some of the issues that you may face with individual processes, but there are also so many benefits to moving away from monolithic processes. Some of the benefits your team could experience from moving to an individual processes are:

Increased efficiency. With your own processes in place you're able to determine what is important and what gaps there are in your processes that you need to fill. It also reduces the overhead that can come with monolithic processes when parts of that process don't align with the work the team is doing.
Added sense of ownership for the team. When the team is responsible for the processes and the ceremonies of the team it can lead to an added sense of ownership as well as increased trust among team members. They feel more empowered which helps them ensure their processes are the best that they can be.
Increased flexibility. When the team is able to determine their own processes they are able to evolve those processes to fit the needs as they change. As the team and the product grow and evolve the processes can too, taking into account new team members skills, experiences, and suggestions alongside the new requirements of the team.
Greater ability and space to experiment. Teams usually feel more open to experimentation when the impact is confined to their team. They are willing to try out new tools or procedures and then use the results of the experiment to make a permanent change or to learn from the experience what doesn't work for the future.
Allows for context fit of the product and team members. Since every team is made up of individuals with their own experiences and skills, and every team is working on their own area of the product, it can be incredibly beneficial to allow for those different contexts to play a part in determining what the processes of the team should be.

Clearly there can be many benefits and risks to moving to individual team processes, and the lists above only capture some of the more common ones. There will be more depending on the context of your team and your industry, which will always play a part in determining what the best path forward is. That's why our next section will cover some of the indicators that will help you determine if individual processes are likely to be a good or a bad fit depending on your context.

Indicators of Fit

Based on the benefits outlined above you may be eager to get started with introducing individualized processes onto your teams, but there are some factors you'll need to consider. Based on the situation you may find that individual processes could hold you back more than they launch you forward.

Let's start off again with the negatives. What are some of the most common indicators of a potentially bad fit for teams having their own processes?

Strict contractual obligations. This is one of the biggest indicators of a bad fit. Teams or companies that are in the security, financial, or government spaces usually have some very tight contractual obligations to consider. Based on those obligations you likely have, or should have, tight processes in place to ensure those obligations are being met. Due to this, having teams changing processes on their own can be more dangerous, although there is always room to add processes that help, just be very wary of taking any out.
Strict waterfall processes. If your company is currently working on the waterfall model with little to no indication of changing that any time soon, individual processes will likely slow you down. Since there are preset expectations at a higher level for what is to be completed and when, changes to that structure are hard to get buy-in for and even harder to implement.
Tightly coupled architecture. If your company has a very tightly coupled architecture between components of the system and between teams in the development organization, having teams using different processes can be confusing. When you have a dependency on another team, you need to know what to expect from them and when. The same goes for any team dependent on you. Having individualized processes can still work in this environment if you have great communication skills, but it certainly adds to the challenge. Which brings us to the last point...
Poor communication amongst teams. If your teams are already struggling to communicate with one another and keep each other up to date, changing your processes is likely to add to this struggle. Although individual processes may be followed on teams there should be a good deal of overlap and if your teams can't communicate changes and why they're making them, other teams may fall behind and you may end up with silos or islands of processes all over the organization with little to no alignment.

Although the four points above are certainly some warning signs that individualized processes may not be the best approach for your organization, it doesn't mean they can't work. Similarly to the risks we mentioned above there is always a way to make it happen, it will just require extra work. It may also mean adjusting the rules for how individual processes work with your teams in order to ensure that they're adding to your efficiency and not taking away from it.

So now that we've gotten some of the indicators of a bad fit out of the way, what are some indicators that individualized processes would be a good fit for your organization?

Decoupled architecture. One of the best indicators of a good fit for individualized processes comes from having a decoupled architecture. If you're in a position where teams can work on separate pieces of the product without interfering heavily in others and without reliance on other teams then individual processes will likely work well! Your team can experiment and do their own thing without negatively impacting other teams.
Teams are frustrated by overhead or gaps in current processes. If your team is already complaining about overhead in the processes that don't fit their team, or they've started to identify gaps in the processes leading to reduced quality, you likely want to start looking into individualized processes.
Some teams are already doing this. This is the biggest indicator of all, some of your teams are already modifying processes ever so slightly to fit their context. Individualized processes do tend to start happening naturally as teams require specific processes (or lack thereof) to keep their quality high.

Although there are certainly many more indicators possible for when individual processes may be a good or a bad fit, these are a great jumping off point. Seeing where your organization fits can help you understand how much work would need to go into creating this culture in your organization. It could also help you make a game plan for understanding what needs to change in order to get your organization ready for this kind of shift.

Evolving to Individualized Processes

So now that you've decided you want to try moving to individualized processes, what do you need to do to get started? Sadly, it's not as easy as just coming into work one day and telling everyone "Ok! Teams can now use whatever processes they want, have fun!". That would cause complete chaos and would likely not go over so great with leadership either. Instead, using an iterative approach slowly over time to get your teams to individual processes is key.

In my experience, it's usually a three step process, though it depends what state your organization is currently in. The typical states and evolution look like this:

Let's start by defining those four states.

Standardized Process:

One single, standard, process that all teams within an organization follow
Changes to this process are immediately required to be followed on all teams

Standardized Process with Specializations:

One single, standard, process that all teams within an organization follow
Additional processes may be added on by individual teams and any additions should be shared with the organization to determine if they should impact all teams or not
Processes cannot be removed by individual teams, only at the organizational level

Static Individual Processes:

Each team has established processes based on the context of the project they are working on
Changes are done infrequently but are shared amongst other teams when they are made, focusing on why the change is being made
Should still be overlap amongst teams on similar processes (i.e. Code reviews)

Dynamic Individual Processes:

Each team has well documented processes based on the context of their project and team
Processes are evaluated and iterated on frequently to maintain or improve efficiency
Changes are shared amongst teams when they are made, focusing on why the change is being made
Should still be overlap amongst teams on similar processes (i.e. Code reviews)

So now that we have an idea of what the four states we're discussing are, how do we go about moving through the evolution of these states? Well first, figure out where your team is at! Look at the processes currently in place in your organization. You may think that you're in the Standardized Process state but once you start to ask other teams they may have already been adding things on their own, actually putting you closer to Standardized Process with Specializations! It's important to start by understanding where teams within your organization are at and getting everyone to a level playing field. Once you know where you're at, here are some guides for moving between the states.

Standardized Process -> Standardized Process with Specializations

Define your existing process. Have the standardized process well documented and understood by all teams.
Review this process for any overhead. As an organization, or with representatives from all of the teams, review the current process and determine if there are any unnecessary steps being taken. Determine why these processes existed and whether or not you can safely remove them from the standard process.
Review the process on each team. Ensure that each team is aware of the standard process and they understand it.
Identify gaps in the process. After you've reviewed the process within your team, see if there are any gaps that this process doesn't fill. Are they extra pieces that you need to add in to ensure quality in your project?
Document your specializations. As a team, ensure you have documented your process. Reference the standard process which is being followed and highlight what additional processes you follow and why.
Share your specializations. Once you have determined what gaps the process has for your team, share what you're doing to mitigate those gaps. Other teams may also need to mitigate the same issues.

Standardized Process with Specializations -> Static Individual Processes

Review your standard process and specializations. Before taking the next step it's important to once again ensure everyone is on the same page about the current approach. Each team should review their processes and the organization should review the standard process and the specializations teams have made.
Identify gaps and overhead in the process. As a team, look at the current process (standard + specializations) and identify unnecessary steps being taken, why they might exist and determine if they can be safely removed. Next, identify any gaps that are not being covered by the current process and identify and implement ways to fill these gaps.
Document your new process. As a team, ensure you have documented your process. Call out what your process is, why each piece is done, and document what was removed (and why). This will create a historical record for the team and help new members get up to speed on what the team is doing and why it's being done the way it is.
Share your process. Once you have your newly defined process, share it with your organization. Ideally this should be a publicly accessible document within the organization and discussing what changes were made and why can help other teams improve their own processes.

Static Individual Processes -> Dynamic Individual Processes

Review your process on a regular cadence. Part of having dynamic processes is reviewing them regularly to ensure they are still working effectively for the team. Shifts in the project, team members, etc can lead to necessary changes in your processes. As you review the processes focus on identifying any overhead or gaps that exist in the current process
Experiment with new processes. As your team and your project evolves, try new processes or approaches and document your results. See if a new way of doing things, or a new tool adds efficiency to your team. Document not only what you did but why, and why or why not your team decided to keep doing it long term.
Share your updates and your experimentation results. As your processes evolve, share those changes with the wider organization. Sharing your experimentation results is also helpful because even though something didn't work for you, it may still work for another team. Sharing the why helps to streamline this process for other teams to determine if they should try that new process or not too.
Encourage questions, comments etc. about your updates. By allowing others to ask questions or comment on changes your team is making you create an environment where everyone is able to learn from one another. Someone may have additional information that can help your team and vice versa which can prevent you from wasting time and increase your efficiency even faster.

Although I've broken this evolution down into three "simple" steps above, it's not necessarily a quick process. Some teams will still need months, or even years, to work through these different states. The key is to keep lines of communication open amongst the teams to ensure they feel empowered to share wins and losses they experience throughout the phases. It's also perfectly okay if your team wants to stop anywhere along the path. Some of the stricter industries that we mentioned above in indicators of best fit are likely safest to stay at Standardized Process with Specializations for example and that's perfectly ok! Figuring out what works best for your teams and organization while evolving and growing is the key.

Maintaining Cohesion Among Teams

As you may have picked up from the risks section and the indicators of potentially bad fit, maintaining cohesion among your teams while having individualized processes is one of the hardest parts of the process. This doesn't just apply to having individual processes, maintaining cohesion among teams is vital for all aspects of a healthy organization, but it certainly applies here too. So we're going to chat about three key things that organizations and teams can do to ensure that they are maintaining that cohesion even if they have their own processes.

Documentation

As simple as it may sound, having good documentation is one of the best ways to increase or maintain cohesion among different development teams. Having somewhere to go to learn more about another team's work, approaches, processes etc. means that we can stay up to date with one another without lengthy meetings. We're able to check in on specifics that we want to stay up to date on without too much overhead of going over all those extras we don't necessarily need.

One key to good documentation is to make sure your own team is using it. Using documentation as the source of truth for your own team and baking in processes to review the documentation you have is key to making sure that everything stays up to date. If your team is able to use your documentation then other teams can as well.

The last thing that needs to happen in order to ensure that your documentation can help maintain cohesion... make sure it's publicly available! Publicly available within your organization that is. Although some teams may instinctively want to keep their documentation and information close to home, having publicly available documentation is key to fostering a culture of continual growth and safety. By sharing our information with one another we invite the opportunity to learn from one another and grow each team as a result.

Communities of Practice

For those unfamiliar with the term, Communities of Practice are an open forum for sharing ideas within an organization. They typically revolve around particular roles in the company (take quality/testing as an example) and are a way for individuals in those roles on various teams to get together to share knowledge, solve problems and assist one another. It is important to note that although they may revolve around a role, such as testing, they should not be limited to this role. Others should also be welcome to join to benefit from the knowledge of that group. Having developers in testing communities of practice can lead to new ideas and vice versa. Having communities of practice where individuals or teams can share with one another can foster additional growth within an organization and lead to better cohesion amongst your teams.

One of the key aspects to having healthy and productive Communities of Practice is to ensure they are a safe space for all attendees. They should be spaces where people feel empowered to discuss not only wins within their team but also losses and struggles. By sharing both sides we're able to assist one another and grow as a community as we learn together through those experiences. Fostering psychological safety within these groups is just as important as having it on individual teams.

By having Communities of Practice within your organization you open a doorway for teams to share their processes. This enables teams to have a space to float their ideas, get feedback, and lean on the expertise of other colleagues. It's also a great space for teams to learn about other processes that they may want to adopt on their team and gives them some subject matter experts to lean on as they implement those processes themselves.

Shadowing

The last practice that I've seen to be very beneficial in maintaining cohesion among teams is the practice of shadowing. This allows different team members to not only listen to the experiences of others within the organization but presents them the opportunity to work directly with other individuals or teams to learn from them.

In terms of individualized processes, having the opportunity to not only hear about other processes teams have in place but to sit with that team and see them in action is highly beneficial. This can lessen the learning curve to implementing those processes on their own teams and can be a more conducive environment to ask questions and gain expertise in a practice more quickly.

Allowing for shadowing is also a step towards inclusivity in your cohesion amongst teams. This allows for individuals who prefer a more hands on approach to also gain experience and confidence in using a process before they put it into practice.

With these three practices in place teams will be able to maintain cohesion and work together, even while working with processes that fit their individual needs. However, this list is not exhaustive by any stretch. These are just my three favourite and most effective techniques. If there are others that work well for your organization I would absolutely love to hear about them in the comments!

Bringing it all together..

With all of that being said, individualized processes can reduce overhead, fill in gaps and increase the efficiency of teams; but they require work!

I've outlined many aspects of individualized processes in this post from the benefits and risks, factors to indicate fit and some approaches to implementing them effectively on your teams. But it's important to remember that what works for one team may not work for another. Take everything I have said as a guideline and as a resource for determining if shifting towards individual processes is the right call for your team. Experiment with it, see what works and see what doesn't. As I call out in this post a few times, learning from one another's experiences is the key, so please share yours with me so that we can all improve together.

Search This Blog

Things Testing Taught Me