Local optimization doesn’t necessarily mean improvement
Luca | February 14, 2009Delivering 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.
That does sound scary. I hope you are not
Jeff Santini | February 16, 2009That does sound scary. I hope you are not on a project where that is going on.
Jeff
People tend t forget that the important thing is the
Marco | February 16, 2009People tend t forget that the important thing is the amount of business value flowing
through your organization and often end up optimizing a part to the detriment of the system. Avoiding components over systemwide optimization is key to turning an organization’s business ideas into business value fast(er).
Can I agree and disagree with this? Well I
Lachlan | February 17, 2009Can I agree and disagree with this? Well I have, and now you can’t stop me.
I agree that local optimization is risky without a focus on the whole, but I have had successful and focused function (for want of a better word) retrospectives. Giving a functional group a chance to examine how they are working within specific constraints can result in helping to optimize the overall work of the team.
If (for example) it’s perceived that the testers spends a lot of time waiting for something to be delivered and then there is a game of defect tennis. It’s worthwhile having some time with the testers to 1 – gain their understanding in a safe environment (ie testers only), 2 – have them come up with a plan to resolve the issue in context of goal and practices of the project.
Hi Lachlan, I definitively see the value of a focused function
Luca | February 19, 2009Hi Lachlan,
I definitively see the value of a focused function retrospective in specific scenarios (and I agree with you that can be an extremely useful technique specially regarding the creation of a safe environment), but I still think it shouldn’t be a ritual but more an exceptional event.
In particular with teams where communication is not so strong that kind of approach will not help the people understand that collaboration is not just interaction but more working with a common intent in their mind.