Agile for Optimization…or Maybe Not?

by | Dec 20, 2017

There is nothing quite so useless as doing with great effi­ciency some­thing that should not be done at all.

Peter Drucker

Over the last 10 years, I’ve worked in several orga­ni­za­tions, and for several clients, who have evolved from a “wild west” style of testing. These orga­ni­za­tions real­ized there was a great need for process in order to orga­nize and provide quality control for testing programs. Invari­ably, the first process that was created was overly complex and cumber­some. This resulted in every­one 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?

Maybe.

Maybe not.

In my expe­ri­ence, agile opti­miza­tion 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 through­put instead of action­able insights.

Why? Because in the rush to be flex­i­ble and push tests and change requests through dev, design, and creative in the most effi­cient 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 devel­op­ment. Rather, when we apply oper­a­tional agile method­olo­gies to our opti­miza­tion programs, we must take care to ensure that we are not jeop­ar­diz­ing the focus of the program on what’s impor­tant and impact­ful for the sake of what’s effi­cient and “doable”.

Recently, I’ve been involved in several agile opti­miza­tion meet­ings where a new test or change is requested, and the only discus­sion is about the capa­bil­ity of the team to create the test, or make the change, and the impact on the deliv­ery time­line. 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 – strate­gic, data-driven deci­sion­ing and prior­i­ti­za­tion as well as agile, flex­i­ble devel­op­ment? I believe it requires a sepa­ra­tion of the agile process from ideation and prior­i­ti­za­tion. It requires change control gover­nance using evidence to support any change requests and to ensure they are aligned with previ­ous test plans or prior­i­ties.

So wait – we fix process with process? Iron­i­cally – 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 impact­ful. Process done wrong – well – then we’re back to Peter Drucker’s useless effi­ciency. Or worse – TPS reports!

If you need help improv­ing your opti­miza­tion gover­nance or process, reach out – we’re happy to help!