Making Changes For Your Software Team

In a previous article, I discussed a software manager’s role in finding useful practices that may be missing from the team’s engineering workflow, using acceptance criteria as an example. Now I’ll address adding this missing practice to the process and testing it, to form a repeatable cycle of improvement.

Making the Change

You’ve identified a process change, and now it’s time to put it into action. But it’s not as simple as requiring engineers to start behaving differently. If you don’t get buy-in on the idea first, you risk requiring them to do something that doesn’t make sense to them, resulting in mistrust of the process and a feeling that they don’t have the support of the organization to do good work.

Instead, take the time to explain to engineers and product owners that they have a new tool that benefits them both; after all, both of them want the features to get implemented quickly and correctly without resorting to endless rounds of revisions.

Even with buy-in, your process may be set up in a way that incentivizes rushing through the early steps of defining the feature, meaning that they’ll feel pressured to skip the new step.

Here’s where management has the opportunity to prepare the environment by designating a time and place for the collaboration around acceptance criteria to occur. Depending on your process, this may involve adding a new column to a scrum board, specifying a new outcome for an existing feature review meeting, or any number of other things depending on your organization’s unique characteristics.

Test Your Assumptions

No matter how complex it is to add a step to your organization’s development process, the manager’s next steps are the same. Observe what happens after making the change, and verify both that the team chooses to use the new technique, and that it actually improves results.

Easier said than done, right? However, with the correct approach, these objectives are within the reach of any organization. For example, measurement can be very expensive, and it’s important not to go overboard, especially to the point of measuring in ways that could be used as a performance evaluation for individuals. Remember that the goal is to empower your knowledge workers to solve the problem the best way they can, so what you’re really evaluating is your own hypothesis that you’re giving them a better tool to get the job done.

Once you’ve seen the results, if you’re happy with them, you can stop there, or better yet, form a new hypothesis. Or you might need to make changes and test again. This feedback loop is a big part of the job of an effective software manager, and it will put you ahead of the vast majority of other organizations following the same general methodology as you. Because each new element you add to your process is not there simply to fit the methodology; it’s there because it adds demonstrated value to your unique situation, and helps to bring out the best in your team.