Agile for Optimization…or Maybe Not?

by | Dec 20, 2017

There is noth­ing quite so use­less as doing with great effi­cien­cy some­thing that should not be done at all.

Peter Druck­er

Over the last 10 years, I’ve worked in sev­er­al orga­ni­za­tions, and for sev­er­al clients, who have evolved from a “wild west” style of test­ing. These orga­ni­za­tions real­ized there was a great need for process in order to orga­nize and pro­vide qual­i­ty con­trol for test­ing pro­grams. Invari­ably, the first process that was cre­at­ed was over­ly com­plex and cum­ber­some. This result­ed in every­one hat­ing the whole idea of ‘process for the sake of process’. Many then pushed for an “agile” process for their pro­grams and are hap­py with the results that allow them to move faster than they did with their pri­or 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 pro­grams often fall into the trap of “doing test­ing” with great efficiency…but lim­it­ed suc­cess. These pro­grams often test things that should not be test­ed at all because their focus is on vol­ume 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 cre­ative in the most effi­cient man­ner, they fail to take a step back and ask “why?” and “so what?” and “should we?”

I’m by no means say­ing 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 pro­grams, we must take care to ensure that we are not jeop­ar­diz­ing the focus of the pro­gram on what’s impor­tant and impact­ful for the sake of what’s effi­cient and “doable”.

Recent­ly, I’ve been involved in sev­er­al agile opti­miza­tion meet­ings where a new test or change is request­ed, and the only dis­cus­sion is about the capa­bil­i­ty of the team to cre­ate the test, or make the change, and the impact on the deliv­ery time­line. Not one per­son 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-dri­ven deci­sion­ing and pri­or­i­ti­za­tion as well as agile, flex­i­ble devel­op­ment? I believe it requires a sep­a­ra­tion of the agile process from ideation and pri­or­i­ti­za­tion. It requires change con­trol gov­er­nance using evi­dence to sup­port any change requests and to ensure they are aligned with pre­vi­ous test plans or pri­or­i­ties.

So wait – we fix process with process? Iron­i­cal­ly – yes. Process is not the ugly word so many of us think it is. Process done right makes our jobs eas­i­er and helps our pro­grams be more impact­ful. Process done wrong – well – then we’re back to Peter Drucker’s use­less effi­cien­cy. Or worse – TPS reports!

If you need help improv­ing your opti­miza­tion gov­er­nance or process, reach out – we’re hap­py to help!