Spring is coming

The past nearly three months have flown by since the new year and Spring is now nearly upon us. In that time I have held many meetings with those interested to share things such as accelerating defect triage to daily, automation frameworks and scalability, leveraging Docker to make automation scalable and more stable, how to improve team communication, and the last presentation was on how developers can contribute to quality. The attendance at each of these meetings is highly variable and is somewhat disappointing. I do however know that people are watching the recordings. In one instance the meeting recording was locked with a password and a few reached out to ask for the password:) Maybe that was just a test?

During this time I have developed a Continuous Testing program that helps to spread testing throughout the lifecycle and it also shares the responsibility for testing from the testers to the whole team. Making sure that the right people are in meetings and discussions about team scope is one of the most important things to drive teams to change. The more that everyone on the team talks, the less lines of code that are written based on unvalidated assumptions from the requirements and the more tests that are executed whether scripted (unit, integration or functional) or exploratory.

Also I have run through some ROI calculations, why would anyone want to change what they are currently doing if we are doing "well enough" now? Well the answer is simple there is a return on investments being made in changing processes, training people and removing organizational impediments. For instance the reduction of time for a hardening sprint can translate into hundreds of thousands of dollars of savings, not that the money is not spent, but it can be redeployed to build features, rather than test and harden the previously completed sprints.

Again as testing slips out of sprints in a multiple sprint release cycle it is easy to let testing "slip right" out of the sprint, but the correct mechanism to improve quality and reduce waste in product development is to "shift left". Shifting left is when each phase of the product development cycle includes testing, from the requirements to the support of the application in production, tests should be executed throughout, whether table top requirements refinement exercises with the 3 amigos (product, dev, test representatives) or unit tests, or integration tests, or functional automation, or even exploratory testing. All of these things add value by reducing rework later.

This is where I was heading in my strategy and when I attended the two day TISQA conference locally in Chapel Hill, NC at the end of February I was excited to be right on par with some of the industries best thought leaders. I returned from the conference and reviewed my nearly complete "Get to Great Quality" presentation that I was building as the explanation of my testing strategy for product development and I made only a handful of minor updates! My strategy was spot on with what multiple companies had already done and were sharing so that others could get to the level that they were already at.

I would meet with executives the following week after the conference, a meeting that was on the calendar for over a month and had already been moved once. I was as ready as ever and had so many facts and industry comparisons and also peer review from some of my most trusted leads from my business unit. Unfortunately the one thing that I had failed to work on was my delivery and also my negotiation skills. While my presentation on the future strategy went well and I maintained the attention of those in attendance I was left without the result that I wanted, investment in quality.

A week later I was able to catch up with the executive that wasn't able to attend the rescheduled date and the feedback was basically that my delivery needs some improvement, "blunt axe" was the exact takeaway. I wasn't upset with anyone, but myself. I know that talking with the executives is not my forte and mostly because I don't have the opportunity to do it from where I sit in my business unit. The opportunity to lead the Quality Center of Excellence opened up the executives to me as they were the ones requesting the program, but I still need to polish my negotiating skills and also my ability to answer the age old question "what is in it for them". That last piece I learned just this past week at a SIM-RTP dinner event. Also that being concise and to the point, "less is more", is very important.

Looking back I have some work to do myself, pare it down, make it clear and concise, and tell the audience what is in it for them. Also coming ready to negotiate and get parts of the whole concept green lighted as opposed to everything staying stuck on the stop line. It will take some time but I will get the right message to the right people and others from throughout the organization will support the strategy and start to implement it because it is the right thing to do to move their business unit and ultimately the enterprise forward. Until then it is back to developing bi-weekly meeting content to continue training the testers in how to approach challenges differently, stand out and start influencing behaviors in their teams that lead them forward faster and with higher customer satisfaction.