Local optimization doesn’t necessarily mean improvement

Delivering software is a pretty complex activity that requires interaction between people with different skill sets. One of the cornerstone of Agile Development is continuous improvement, and one of the tool often used to learn and improve is the retrospective.

In a context where the collaboration is not effective, people tend to look for local optimization instead of seeing the big picture, and you have things such the “QA retrospective” or the “Developer retrospective”.

In this scenario a “QA retrospective” (as the Dev’s one, or a BA’s one) is probably more harmful than anything else; the specific issues that will be identified won’t address the whole activity of delivering software but will only be focused on that specific step (“we need x to do y”).

But what is the impact of that step in the overall process ?

How that step fits into the chain of event that will take a business idea to be delivered as a software artifact (hopefully in a timely and quality fashion ) ?

Don’t get me wrong: it’s definitively through specific improvements that you improve your overall process but if don’t frame your changes in the big picture, it’s more likely that your changes will impact your process in the wrong direction and actually cause an additional waste.

Each attempt of optimization should therefore start from the clear analysis of what is wrong from a high level point of view and only then it’s time to shift our attention to the specific details of each step.