The Myth of Agile

[article]
Member Submitted
  • project is not a brand new one rather an enhancement or a maintenance of an existing system. What if there are not enough knowledgeable members left over, or not enough up-to-date documentation.
  • You may want to consider the practice, in which high-level concepts and requirements are kept in documents while low-level details are explained in source code comments. This way, the documents won’t get out of date quickly, and developers don’t have to go to multiple places to keep things up to date.
  • Consider Agile, if you can break a project into many easy-to-manage intermediate deliverables to take advantages of the benefits Agile offers such as iterative fine tuning, earlier usage of implemented functions (maximizing ROI). Still, I feel it will be more effective if certain best practices are followed to provide necessary check and balance, and further to avoid the traps mentioned above. If a project is too complex, you may want to consider something like waterfall model for a complete project plan before breaking it down to iterations. Without a "whole" picture, the likelihood of re-architect your software at the iteration level is high. It, of course, is highly undesirable.
  • You may want to consider tools, which provide the flexibility for you to customize a process to best fit your situation and enforce your best practices. Productivity enhancement tools are also important, because small time saving become big one due to the repetitive and iterative nature of Agile.
  • It will pay off if you mandate certain critical modules are reviewed. Not only more heads are better than one, but also more people are knowledgeable of critical pieces. It, too, is true that developers will do a better and more complete job, because they know others are looking over their shoulders.

In summary, there are no hard and fast rules but the best process for a project. What process to use depends on many factors such as the nature of the project (complexity, management’s and end users' expectations, etc.), the construct of the team (skill sets, communication means, commitment, etc.). As mentioned in the beginning, the intention of this article is to stir up more discussions, and, hopefully, via your participation we can all benefit from each other’s knowledge and experience.

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09