Many organizations face the challenge of Agile adoption, particularly if they are trying to replace a familiar traditional methodology completely. To ease the adjustment, managers may consider adopting Agile principles that can integrate seamlessly with existing methodologies.
The Waterfall model of software development and other non-Agile methodologies work very well since they force the creation of some or all of requirements, functional specification, technical specification and technical architecture documents before a line of code is written. However, they do not work well because quite often you wait for many weeks or months before a software delivery is made and find out too late from the end users that you have been off-course all along. The Agile methodology closes this communication gap earlier on.
Agile developers do a release and a demo the end user can play around with and provide feedback on course corrections that need to be made early on in the development cycle. You don’t need to wait weeks and months to find out that the software developed was off-course. The end user gets to use the software earlier on and provides feedback on whether you are on the right track or not.
Communication between the end user and the development team is the biggest problem in software development efforts. If you fix communication problems early on, the development effort goes that much more smoothly. One of the main principles behind Agile is the elimination of waste behind any process. Waste can come in many forms – unnecessary and wasted human effort, wasted time in terms of delays and rework of completed software code.
You can incorporate these underlying principles behind Agile methodologies into other methodologies in the following ways:
- Eliminate all unnecessary and superficial documentation: The functional specification, technical specification and technical architecture documents should all be optional and to be used selectively on a case by case basis. If it is a short duration project, all these documents may be overkill. Each of these documents should be considered for their utility, combined into one or eliminated completely before we start coding anything.
- Create quick and dirty documents to clarify design early: Once we are past the specification stage, for every project, the development team creates a high level design document, even it is just a couple of pages. This will just feature mockups of user interface designs. The reason is for end users to get a preview of the user interface early. The development team gets a chance to ask questions and clarify things before proceeding to coding.
- Increase periodic builds and releases for communication and increasing code quality: Rather than wait for months between releases, make a project plan that breaks up the time available for development and testing into weekly, 10-day or at a maximum, every-two-week build-release cycle. On this date, without fail, there is a release. The reason for this is to instill a build and release discipline. Every build will be tested formally, locally and only then released. This also ensures that software is tested many more times than in a purely Waterfall model and increases the quality of the software indirectly.
- Use an online, automated issue/defect tracking system to communicate better and faster: Communication speed is one of the biggest benefits of Agile methodologies. Problems, issues and defects get identified earlier, communicated and addressed. An automated, online issue/defect tracking system that is integrated well with email can go a long way in realizing the same benefit when incorporated with other methodologies.
- Turn project status meetings into semi-stand-up meetings: Agile stand-up meetings help in identifying problems and obstacles early in a development cycle, addressing them and getting them out of the way. Development teams may even do daily Agile stand-up meetings. When using other methodologies, daily stand-ups aren’t necessary, but increasing the periodicity of project status meetings from say, monthly or quarterly, to say, every one or two weeks, achieves the same goals.
- Measure project velocity by keeping track of completed features by release: When Agile projects managers measure project velocity by keeping track of stories completed by build and release, they have a sense of how fast the development effort is going. Teams that use other methodologies may also need to come up with a sense of how many of the features they are completing with each release. Increasing release frequency helps these teams keep track of the project velocity at a finer level than before.
Agile methodologies help bridge communication gaps, identify difficult technology and user interface issues early. They also eliminate a lot of waste in needless documentation, unnecessary and wasted design and coding efforts. Frequent releases and project management meetings make sure that course corrections are identified early, and made. By identifying what works with Agile methodologies and why, the same can be incorporated in a gradual way when using other methodologies.