I’m an absolute fanatic about delivering products via an Agile Process. That wasn’t always the case. I wasn’t a believer earlier but I’m now. We primarily follow Scrum in our organization and can totally vouch for the value it provides. It not only provides astounding ROI but also allows to succeed or fail faster. It specifically works great for product companies building beta or version 1.0 of their product. It allows everyone to be nimble and be focused on constantly improving the product based on user feedback.
I could go on highlighting the benefits of it but we have found certain myths/misunderstanding regarding following the process. Here are the top few that we have seen recurring-
1. Retrospectives are the panacea for fixing the problems.
Well, it’s only partly true. Prognosis of issues or talking about them candidly wouldn’t solve them. The team has to be diligent to iron out all the issues collaboratively. It needs relentless focus and drive to mitigate the risks or clear out the impediments once they have been brought to the forefront. Sometimes inadvertently the team ends up making similar mistakes. The most common problems that I hear in the retrospectives are about – not enough discussion regarding User Stories, not estimating the work properly, not writing enough test cases, not enough time to do code reviews or refactoring. And, then only to fall in the same trap again.
2. 100% Code Coverage predicts bug free software.
Mostly true. At the same time, we have seen that some issues creep in because of environment configuration, external dependencies, browser issues and integration with other components. Having good unit test cases does solve most of the heartaches and gives you the confidence to re-factor but the product still needs to be functionally tested to make sure it solves the user problem.
3. It increases productivity i.e. It takes less time to build software.
Not true rather it takes more time to build software the agile way. It is a process that recommends building products in Sprints thus the team releases individual features faster. The product takes somewhat longer as one has to bake in unit testing, code reviews, pair programming, having the right build process in it. Please don’t misconstrue this as I wouldn’t develop any other way but doing all of this takes time. In the end, one does get a mature product but at the cost of incremental time.
4. Unproductive teams do stand ups for more than 15-20 minutes.
Not true. At all. I’m not saying that one should have hours of meeting but there are times when one needs to explain the context of their impediment. Does going over the time limit to explain the context and get help a big deal? It isn’t. I would rather that the the entire scrum team(BTW, we only work in small teams. We end up having small scrum teams if the size of the team grows) knows the context of the given problem so that they can help.
