Archive for November, 2010
After a few years of experience working with agile, I have come to the conclusion that many of its principles are just buzz talking targeted to management and that they don’t help in the development of the application.
What follows is a list of the most common myths I have seen around agile. Please, feel free to add a HA! After you mentally read each of their titles.
1.- Stories are better if you follow such and such conventions to create them.
Have you ever had a fight over the best convention to use to name a story? Or have you ever expend hours trying to split your backlog into stories that fit such and such criteria? Or maybe spend weeks deciding the best application to store them?
There is a funny fact about stories, when there is a communication issue in the team, stories are usually blamed: They are not clear enough, the acceptance criteria wasn’t good enough, the color of the cards was wrong…
Stories are great placeholders for discussions between development, management, QA and the customer. That’s all they are. All you need to do is make sure that everybody involved understands them and keeps an open discussion.
The ones to blame when communication doesn’t work is the team, and the solution is usually not improving the stories, but improving the communication.
2.- Planning, with agile is fun and accurate.
Fact: Planning in software development is not accurate. You can use days, hours, points, play poker or blackjak, is not going to work, and if it works is usually by coincidence. So, should we stop planning? … mmm… I don’t think managers would be very happy about that.
Definitely planning adds value, it tells you about the scope of the task: is it hours/days/weeks? And it helps to determine the percentage of completion of functionality of the application. It is also useful to set expectations for management.
Agile actually does a good job setting the right expectations. With agile the customer should legitimately expect to receive the best solution as possible for a given date, but agile is not going to tell you when you are going to be finished, still is probably going to be more accurate than waterfall.
3.- Daily stand-up, the communication panacea.
Stand-ups don’t substitute communication in the team, but some agile teams tend to think so, the “let’s raise it in the tomorrow’s stand-up” approach, doesn’t work.
Stand-ups are ok, they provide an overview for the previous and the current day, but that’s all they are. Communication is very important in software development and it can’t be limited to a 10 minutes discussion in the morning.
4.- Agile the process that fits everything.
Agile is not the silver bullet. That’s probably one of the most repeated sentences in agile environments; still, I have seen the very same people that say so behave like if it was.
Applying agile principles to everything is not only wrong, but lends to dogmatic ridiculous situations, like never documenting the code, never creating documentation or never creating even a light design upfront.
Software development is a complex matter that requires different approaches depending the circumstances, sometimes a waterfall approach is better suit than an agile approach or vice versa, and most of the times what is going to be better suit is going to be a mixed approach.
5.- Retrospectives, they fix everything.
Not only is a bad practice to wait for the retrospective to raise an issue, is childish to expect them to be fixed just because they get raised, issues raised in retrospectives are usually serious impediments, and management tend to leave them for after, which usually means never.
Over the years I have come to the conclusion that removing impediments or improving the process are usually up to individuals. “Hero developers” make most of the big differences made in software development.
These hero developers are the ones that usually get fed up of not having SCM or not having an automated test suite… And they decide to champion an action and fix things on their own terms.
6- Unit tests is all you need.
There is a tendency in agile to believe that unit tests is all you need. But the problem is that the major issues are always in the integration points and E2E aspects of the application, and that’s something that your unit test are never going to highlight. Unit tests are still very important, they have a lot of value for refactoring and to help you design your code, but keep in mind that you are still going to require integration, end to end, adhoc and other types of testing to guarantee the quality of your product.
Another stupid affirmation is the ones that refer to an specific necessary quantity of code coverage in the project. This type of metrics are useless and usually come from people that has never coded for real. Your unit tests must cover parts of your application that contains your business logics, not getters, setters, integration points etc.
7.- Agile is a process fitted for junior programmers.
Short answer: No, agile is not a process suited for junior programmers. Agile switches the main responsibilities of the development from a few to everyone in the team.
Everyone is responsible for maintaining the quality of the application, and when you asked someone without experience for this kind of responsibility you are calling for troubles.