The less governance you have over software QA, the more intense it gets with your Leadership team, the clients, and the PMO. Angry emails get sent, side-bar triage meetings become more prevalent, and eventually, the entire team starts to loathe those Monday morning dept sync calls.
We all know that you cannot “unring the bell” when something goes horribly wrong during implementation or, worse yet, something comes up in production. We do have some tips to offer to increase the level of communication and lessen the opportunity for the Grim Reaper to invite himself to your boss’s next staff call. Better yet, let’s transform that Monday meeting back into a positive progress report by working together! In the meantime, here are some ideas to get you started.
Start with your meeting schedule
Monday morning meetings often end up being reactionary and defensive because, after a weekend of implementation mayhem, the standard canned answer on Monday morning is, “yeah, it hit the fan, and we are presently working on a resolution.” If you think it sounds suspiciously like an uncensored recording you hear when you call the help desk, you are correct!
No more manic Mondays
If a resolution didn’t materialize over the weekend production release, give them Monday to regroup, analyze, and exchange ideas before reporting their status. Allow individual team huddles to define problems and come up with ideas and resolutions. Giving back Monday doesn’t lessen the brevity of a problem, but it gives them a chance to present answers instead of documenting all of the questions.
Status starts on Tuesday
With a full day to triage and regroup on Monday, the Tuesday status takes on a whole new vibe for the team. Instead of a day of questions, it becomes a meeting of answers and an exchange of ideas. The status meetings between the project manager and Leadership becomes one of progress and forward movement more often than one of “The team is working on it – I’ll let you know as soon as we have our next steps.” Imagine the change in mood when reporting solutions over problems!
Documentation is a learned skill
I worked on a project team that had several consultants from different resources, rural and overseas. They had the brilliant foresight to bring in a trainer to teach the entire team quality documentation skills. Now, maybe it was because this was an IT firm with a help desk of over 600 people, and this training resource was in their pocket, but the results I observed from that training was the need for less follow-up by the project manager chasing down answers because they were all there for him already. The notes were clear enough that anyone on the team could easily understand them. This practice reduced inquiry chatter and increased productivity across the board.
Here are some of the essential documentation lessons that the trainer presented to the project team:
1. Document everything
The cadence communicated to the team is, “if you didn’t write it down, it never happened.” There are no obvious next steps when it comes to documenting your actions, especially with incident and defect tickets. The message is to assume nothing and leave no question when recording what was done, what remains to be done, and what resources are needed to get it done.
2. Consider your audience
Who will be reading your notes? When writing, do so using language and terminology everyone can understand? This detail reduces the number of interruptions and clarifying questions, especially with incident tickets, where the helpdesk, customer service, and management will be reading your details.
3. Use a template when you can
The trainer introduced some customized templates to the team to use for the most common types of notes, prompting them to remember the most critical details. Another template I liked was with status updates by the team leads. They had a very simple layout with stoplight color-coding (red, yellow, green). Each Friday, they used the template to report what tasks completed that week and what was upcoming for the next week.
If they ever had a status of red or yellow, they were encouraged to seek out resolutions and present those in addition to their normal status. That way, they can identify what assistance they need ahead of the meeting and instead of merely reporting the news. If you opt to make these statuses available for the team and Leadership to review on a dashboard, each party has the self-serve ability to see and act. It might even eliminate a regular meeting off of the calendar. The project manager then has the time to spend Monday lining up resolutions for the Tuesday team meeting.
Embrace proactive practices
Ultimately, the best solution is that of prevention. That’s the entire point of testing software before implementing it.
Automation testing and a functioning CICD (continuous integration continuous deployment) process is the first line of defense, because it stops defect leaks from bottlenecking resources and it shrinks the size of releases which in turn reduces the risk associated to that release, giving the team a chance to make corrections, and more importantly, prevents them from repeating the error in other functions or environments.
The next proactive action is the selection of your testing team. If you’ve been involved in IT implementations once or a dozen times, you know that not all testing teams are not created equal. Skill and experience translate directly into their ability to ensure your products and code are defect-free and as designed.
Have trust in the team
You’ve provided the essential tools and processes needed to make everyone on your team work better and more efficiently. ..But if you’re struggling with code quality and want a second opinion,
Lighthouse Technologies can assist you in many ways. From automation testing to the best and brightest testers in the industry as an outsourced solution.
Contact us today and let’s have a conversation about the issues you’re seeing and going through. We’re always just a phone call or email away.
Text content
After spending over 20 years managing, developing, and deploying complex software/hardware systems for both commercial and Department of Defense (DoD) applications, Jeff founded Lighthouse in 2000 with the aim of establishing a company whose customer service was only eclipsed by the quality of its work. Armed with an encyclopedic knowledge of motivational leadership tactics and a wealth of expertise in software quality assurance (QA) processes and technical leadership, he’s both a hands-on company leader and the primary architect of Lighthouse’s celebrated workplace culture.
