Most Agile Scrum projects start of well with a high velocity, highly motivated team and fast paced deliverables. But then down the line it all seems to recede. However, here the problem is not with the team, culture or morale. They would presumably be in the right place since the whole purpose was being met well initially. Here, the problem is more to do with managing a software project/ product that is getting bigger and more complex to handle over a period of time. The result or outcome is poor quality, which in turns starts affecting the productivity.So, what does one do in such a case? Again, one needs to get deeper into software engineering and look at that from an altogether fundamental approach. One needs to look fundamentally into two factors, i.e., into productivity and quality. One approach is to look into one of the Engineering practices such as ‘Test Driven Development approach’ and apply a two thronged approach into solving this problem. Here are 6 quick steps in Test Driven Development approach that will give quick and reliable results to help continue your Agile Scrum practice in a fast and productive way:
1) Reduce Test Size and Failures and increase speed: As mentioned above, quality is the root cause of Agile Scrum not being affective at later sprints. Ironically, it is one of the most important expectations of going Agile apart from fast paced deliveries and incrementally developed potentially shippable product. So, ensure that the Test Suite size and methods are smaller and more manageable. Ensure that the test suites run quickly. Ensure that there is minimal breakage while running the test suites in the production environment. All this should be taken very seriously.
2) Minimize the Methods and Class size: Ensure that the code has smaller functions, methods and classes. If the class size exceeds certain threshold, ensure that it is further spilt. This is to ensure that the code is easily managed and consequently the unit test cases are equally efficient and productive.
3) Run Static Code Analysis: to help find and reduce programming flaws and weaknesses. This can also find and measure the amount of duplicate code.
4) Ensure Continuous code integration: Ensure you have a server that creates build every time a developer changes and checks in some code. Run all the tests on that build and address any failures immediately. Having said that, ensure that good builds are built daily: Reduce build failures. Measure the number of failures in a month and reduce the occurrence of build failures.
5) Measure “definition of done” by running story tests in the integrated system or the potentially shippable product at the end of every sprint: Ensure that stories are not marked as done until their corresponding story tests are passing.
6) Practice Pair Programming: Believe me, this really helps. Development Teams that pair produce better codes. They make fewer mistakes. This is because they communicate with each other about designs and implementations. They continuously learn from each other.