Skip to content

Four Tips for Keeping Your Product Development Teams in Sync

Apr 12, 2018

Interdepartmental relations are often one of the first virtues to suffer as a software company scales, which in turn affects the overall quality of the product. Clear and consistent communication and collaboration are crucial to maintaining a viable product--especially across the departments responsible for product development. Each department from Support to Development plays a critical role in the overall health of the product, so while it is important that each team functions individually, it is equally important that technical teams work as a cohesive unit.

A unified front is easy enough to achieve with a team of 20 employees where the developer working on a fix is a desk or cubicle away from the support analyst who reported it, but what happens when your company adds 20, 50, 75 employees, moves into larger, more segregated offices, and company culture naturally evolves from a democracy to a republic?

Let’s look to the following scenario to see what happens when Product Development departments don’t work together.

A user reports issue X to your Support team, which replicates it and logs it in your company’s issue tracking system. Development sees issue X and tentatively targets the fix to the next maintenance build. Support, seeing this, updates the user accordingly. Development later begins work on the issue and finds that the fix is too complex to fit into the next maintenance build but doesn’t reach out to the analyst with the new timeline. The release date initially promised rolls around, and the user reaches out to Support for an update on the fix for issue X. Support then goes to Development to get this information and finds the issue has been pushed to a different release. The fix will now not be available for an additional couple of weeks, and the user, tired of waiting, posts a negative review of his experience, which deters a prospect from purchasing the product.

Of course everyone works hard to avoid situations like these, but unfortunately, information will inevitably slip through the cracks from time to time, and as a company grows, so do the number of cracks. For the purposes of scaling gracefully and sealing up the cracks, try implementing the following strategies so that teams stay tightly integrated and communication--as well as your users--don’t suffer in the process.

Invite Support to Sprint Planning

While departments will (and should) always have some degree of autonomy, the sad story of issue X can be avoided by implementing a company culture of transparency in which individual departments invite external departments into their processes.

In the case of issue X, if the analyst who logged the behavior had been a part of the conversation in which the issue was assessed and removed from the initial targeted build, the domino effect would never have started.The analyst could have learned on the spot that the issue was too complex to rush into the next release and could have managed the user’s expectations better so that the wait time did not come as a surprise.

At Exago, any Support analysts who have recently logged new issues attend the next Sprint Planning session and go over each of their submitted issues with QA and Development to assess the priority and severity of the reported behavior and determine what targeting information to deliver to the client.

Some pointers for implementing this strategy:

  • Have an open invitation for analysts at attend sprint or scrum planning sessions and notify them of any scheduling changes.
  • Have a means of tracking newly logged issues, grouped by week.
  • Use your issue logs in Sprint planning sessions for more efficient coverage of relevant issues.
  • Designate a point person to moderate and track the discussion.
  • Have each employee write down his or her deliverables from the meeting.
  • Make sure Dev, QA, and Support are on the same page with regard to the status and priority of each issue by the end of the meeting so that they may deliver the most accurate info to the client.

Meet your Newest Members of QA: Your Support Team!

Another way to break down walls between departments is to initiate project sharing by recruiting helping hands internally when one department is feeling particularly strapped.

The members of your Support team are the power users of your company’s product--who better to assist QA and put new features through their paces before major releases?

With Support acting as a branch of QA, there are more hands and eyes on the product during the testing stages, which helps alleviate the pressure and time requirements from QA and developers when ramping up for major releases. It also presents opportunities for Support analysts to bring their front-end product knowledge into the testing process. Since Support works more closely with clients than anyone in the company, they can offer user perspectives on enhancements and issues, which helps QA explore different areas of the application. You may be thinking, Okay, but what does Support get out of this besides a larger workload? When they get access to new features before they are available to the public, Support analysts are better prepared to answer the inevitable questions that pour in, which cuts down on their time spent on tickets in the long run.

To put this into practice:

  • Give Support due notice before adding to their workload so they can plan accordingly and give testing their full attention.
  • Have QA write checklists for analysts to create a mix of targeted, prescribed, and general “free-for-all” testing .
  • Inspire enthusiasm for the project by turning QA into a contest. Award prizes to those who find the highest number of unique issues. (We tend to get very competitive and hyped about our “Testathons” at Exago.)

Put Developers on Support Calls

While Software and QA Engineer aren’t traditionally heavy client-facing or customer-service roles, occasional developer presence on client calls benefits everyone involved; developers hear frustrations and feedback on design choices and issues directly from the people struggling with them, developers expand their knowledge of client use cases, Support analysts learn developer troubleshooting techniques, and developers help deliver quicker solutions to clients in cases where there are more complex, technical puzzles to solve.

At Exago, developers and QA engineers will regularly join analysts on support calls with clients. To keep this process organized and distribute labor equally, we have implemented Headshot, a visual logging system that tracks the number of support calls developers take.

Taking a call can mean simply observing and being on hand in case technical backup is needed, or it can mean taking a more active role in the conversation. Currently, developers have a quota of two calls per month, regardless of the nature of the call. The system is a two-way street--support analysts can reach out to developers to schedule a call, or developers can notify the support team of their availability and ask about any upcoming calls they can join.

To initiate this system:

  • Have a tracking system to log the number of calls per developer.
  • Distribute calls equally amongst developers so that no single developer gets bogged down in client cases.
  • Establish bi-directional communication between Support and Development for easy coordination.
  • Have Support analysts brief developers on each case before the call.

Professional Development and Group Learning Sessions

Professional development is always mutually beneficial for employees and companies--employees learn and improve their skills, which then benefits the company they work for directly. Professional development done through the form of group learning sessions can also help unify your team. Like with Support’s QA efforts, you can utilize the resources you already have and let employees teach skills and concepts to their colleagues.

For example, if new features are being added to the product, have the developer building the feature demo it for both QA and Support. This gets all three product development departments in one room, learning about the features, asking questions, proposing ideas, generally getting on the same page about what this feature is and what it is supposed to do.

At Exago we have Scott School--named after our VP of Business Development and Technology, Scott Epter, who has a penchant for launching into lectures when enthused about a topic that comes up in conversation. We formalized the concept and opened the floor to anyone who has a teachable skill or knowledge that she wants to share with the rest of the company. All are welcome to attend these presentations and they are a great way of getting people from all of the different tech teams together in one room.

To start this program:

  • Create a recurring tentative meeting time once a month (or however often works best for your team) on every employee’s calendar.
  • Don’t make the meetings mandatory--not every topic will be relevant for every employee.
  • Invite employees with special skills to create short presentations and share their knowledge with the rest of the team.
  • Create a casual, academic space where employees are comfortable teaching and asking questions of one another.
  • If employees are giving presentations within their own departments, open up the presentation to employees in other departments who could benefit from the knowledge or are simply curious about what other teams are working on.

While some of these may be more your company’s speed than others, we invite you to try any of these techniques to streamline communication between the front and back ends, create a more unified team, and avoid retroactive team building efforts so you can focus on growth.

Schedule a Demo

Leave a Comment