Agile for Optimization…or Maybe Not?
There is nothing quite so useless as doing with great efficiency something that should not be done at all.Peter Drucker
Over the last 10 years, I’ve worked in several organizations, and for several clients, who have evolved from a “wild west” style of testing. These organizations realized there was a great need for process in order to organize and provide quality control for testing programs. Invariably, the first process that was created was overly complex and cumbersome. This resulted in everyone hating the whole idea of ‘process for the sake of process’. Many then pushed for an “agile” process for their programs and are happy with the results that allow them to move faster than they did with their prior process, though still not as fast as they did with no process.
Best of both worlds – right?
In my experience, agile optimization programs often fall into the trap of “doing testing” with great efficiency…but limited success. These programs often test things that should not be tested at all because their focus is on volume and throughput instead of actionable insights.
Why? Because in the rush to be flexible and push tests and change requests through dev, design, and creative in the most efficient manner, they fail to take a step back and ask “why?” and “so what?” and “should we?”
I’m by no means saying that agile is bad or that we shouldn’t have agile development. Rather, when we apply operational agile methodologies to our optimization programs, we must take care to ensure that we are not jeopardizing the focus of the program on what’s important and impactful for the sake of what’s efficient and “doable”.
Recently, I’ve been involved in several agile optimization meetings where a new test or change is requested, and the only discussion is about the capability of the team to create the test, or make the change, and the impact on the delivery timeline. Not one person has stopped to ask, “why?” Why do we need this change? Why should we run this test?
So how do you get the best of both worlds – strategic, data-driven decisioning and prioritization as well as agile, flexible development? I believe it requires a separation of the agile process from ideation and prioritization. It requires change control governance using evidence to support any change requests and to ensure they are aligned with previous test plans or priorities.
So wait – we fix process with process? Ironically – yes. Process is not the ugly word so many of us think it is. Process done right makes our jobs easier and helps our programs be more impactful. Process done wrong – well – then we’re back to Peter Drucker’s useless efficiency. Or worse – TPS reports!
If you need help improving your optimization governance or process, reach out – we’re happy to help!