Some practices which harm the way we adapt to agile way of working or in a way sort of bad practices which are counter productive. They may very well push back the organizations which are still testing the waters of going agile.
End of the day integration:
Doing it one time a day is not continuous enough. Many a times the counter argument is that the build time is so much that it makes sense to do it only once but that defeats the whole purpose of CI which aims to provide a quick feedback on the status of code under development. With frequent check-ins, there will be frequent integration, frequent feedback and very less merge conflicts. The more the code lies on the developer’s box, the more adverse effect it can have.
Here is what Martin Fowler has to say
Many organizations do regular builds on a timed schedule, such as every night. This is not the same thing as a continuous build and isn't enough for continuous integration. The whole point of continuous integration is to find problems as soon as you can. Nightly builds mean that bugs lie undetected for a whole day before anyone discovers them. Once they are in the system that long, it takes a long time to find and remove them.Let us keep the refactoring tasks for later:
Quality of design and code is as important (if not more) as the implementation of the functionality. We all understand that sometime it is difficult to come with a business case for it and may get hard to justify the time and effort involved in the refactoring activity to the customer but it has to be done and sooner the better. More often then not refactoring can be done as part of the development and the effort should be estimated as part of the estimation of implementation of user story until and unless there is big architecture or design change involved (which then is considered as a separate task in itself and should be treated that way).
Unit testing the complex pieces is enough:
All the code should be unit tested as it is very subjective to decide how much unit testing is enough and which all pieces are too easy not to test. More the unit testing, more are the chances to catch an issue which might have quietly crept in as a side effect of making changes somewhere else or due to refactoring tasks.
Move the iteration untill all the user stories are done:
All the iterations should be time boxed as sustainable pace and rhythm keeps the team going. Moving over the iteration to complete a user story is bound to break it. It might seems to be ok to take care of an exceptional condition but then the number of exceptional conditions keeps on increasing the rhythm to develop and release breaks.
Here is an interesting quote
The iterations are time-boxed. This means that the length of the iteration does not change from iteration to iteration. And we do not extend any single iteration (or sprint) because "we're not quite done yet".Let us try to do as much as possible during the iteration:
Be pragmatic do what can be done and what provides the maximum customer business value. It is important to have something working at the end of each release, a working code rather then a lot of code which fails to work. Never do overtime as it kills the pace and so the team. Doing more will make the code coverage fall, will serve as an excuse to skip stand-ups and the rest a crappy and fragile code.
Comment the test as it is breaking the build and we will come to it later:
There is no better time then now to fix the test case. Test cases fail for a reason, identify and fix it rather then deferring it for some other time.
Retrospectives are not adding much value, will save time if we skip it:
They give us a chance to inspect, learn and adapt. They do not add value as nothing happens after that, nothing happens to the ideas and suggestions which come as a result of it.
Allan Kelly reasons:
The most common reason given for not doing a retrospective is lack of time. True, we are all busy people, but if we really value retrospectives the way we say we do, surely can we make time? Finding the time is really a question of prioritization, deciding that the retrospective is more important than other things.We are doing continuous integration so we are already agile:
Agile is something which you either do or you do not. There is no partial way of doing it and doing it partially will not take us anywhere. Agile is more about doing development in iterations, working code, customer feedback, adapting to changes rather then picking and choosing few practices and calling yourself agile.
Most of the user stories are high priority:
Very important to make sure we have the requirements prioritized and what we do as part of iterations are the ones at the top of that list. If we have too many high priority items then different team will go about it in different ways, some will pick the easy ones to demonstrate how high their velocity is and some will pick the tough ones to technically feel great about themselves.