1. AGILE ELIMINATES PLANNING

The successful implementation of the agile methodology, like the Waterfall development approach, is dependent on supporting business processes, including planning and budgeting. One difference between agile planning and Waterfall planning is the time at which planning occurs. In that agile employs iterative processes, its planning process is incremental as well. In contrast, the Waterfall model requires that planning take place during the project’s initial phase. In turn, the scope of planning that occurs for an agile project at one point in time differs from that using a Waterfall model, as does the number of planning cycles.

2. AGILE ESCHEWS ALL DOCUMENTATION.

To set a project’s direction, a software development team relies on documentation that specifies how a system should work. Such documents align the objectives of developers, IT architects, end users and other business stakeholders. Consequently, agile project documentation, not unlike traditional project documentation, serves as a basis for team member collaboration, as well as a reflection of that collaboration. The timing of the production of agile project documentation, however, varies from that of Waterfall documentation: the former likely consists of a number of documents that are produced throughout the project’s life cycle; the latter consists of a single, all-inclusive document created at the beginning of the project.

3. AGILE APPLIES TO SMALL, POINT SOLUTION PROJECTS ONLY.

The agile team model can be effective for small, point solution projects and large, complex systems alike. In particular, the creation of multiple small, cross-functional groups can be of particular benefit during the development of multidimensional systems requiring the support of multiple cross-functional groups. For instance, the development of large, comprehensive systems can benefit from the division and allocation of convoluted or multifarious requirements to multiple teams. In this case, organizing individual teams by software function or IT architecture component focuses team member effort and limits redundant efforts.

4. AGILE STAKEHOLDERS AND DEVELOPERS ARE CO-LOCATED.

Although agile projects are dependent on the participation individuals of varied and different expertise throughout the software development process, it’s not necessary to co-locate team members. Instead, a team can rely on telecommunications systems for formal and informal communication, regardless of team member location. What’s more, visual aids that support communication and collaboration take a variety of forms, such as screen-sharing tools that allow one colleague to view the computer screen of another.

5. WITH AGILE, A PRODUCT REMAINS UNDEFINED THROUGHOUT THE DEVELOPMENT PROCESS.

The Waterfall model allows an end product’s requirements specifications to be fully defined before coding begins. But design, business process, stakeholder needs or data requirements may remain unknown until a later date and they might change. In these circumstances, the Waterfall model may be less desirable than the agile methodology due to cost and timing concerns. Agile product planning, like the Waterfall model planning, occurs during the early development stages. A major difference being the plan details emerge as agile development proceeds and each system iteration is built and refined.

6. AGILE DEVELOPMENT PROCESSES ARE AD HOC: UNSTRUCTURED AND UNDISCIPLINED.

A mature agile framework invokes an ordered and repeatable approach to software development. In fact, a software development cycle guided by the Waterfall model is less coordinated and process-oriented than that directed by the agile methodology. Using user story prioritization to govern project scope, defined roles and events to guide project management, and periodic stakeholder reviews, agile processes are more disciplined than are those guided by other software development models or methodologies.

7. AGILE IS SYNONYMOUS WITH SCRUM.

Scrum is a framework deployed in complex agile projects in part due to its ability to accommodate last-minute changes. But in fact, multiple agile approaches exist in addition to Scrum: lean programming, extreme programming and other hybrid approaches. For instance, a developer may simply revise existing processes by incorporating particular agile principles, such as the incremental development and delivery of software, to expand stakeholder collaboration.

8. AGILE DEVELOPMENT PROCESSES ARE NONCOMPLIANT WITH FEDERAL DEVELOPMENT REQUIREMENTS.

Some federal SOPs related to acquisitions, enterprise architecture, and security certification and accreditation might be problematic if contracting with agile developers. Even so, regulations don’t specifically preclude agile development. For instance, a primary issue might originate with the agile development process itself…namely, the spontaneous changes for which agile is noted run may counter to agency requirements in regards to traditional contract bids and change orders, delays and budget overruns.

9. AGILE NEGATES THE MAJORITY OF SOFTWARE DEVELOPMENT DIFFICULTIES.

Agile has its relative advantages: stakeholder involvement and alignment, fast delivery of production versions, early-on identification of project risks, and so on. Agile development, however, is not appropriate for any and all projects. For instance, agile is best for project work that can be divided into small increments, each of which can be completed in a matter of weeks. Also, an organization’s culture and practical project methods must support an incremental delivery approach. What’s more, some initiatives are better suited to agile than others, For instance, agile is a good option for analytics and mobile projects, but less so for ERP and large system modernization endeavors.

Agile development is an approach relied on by many companies representing a variety of industries due in part to the speed, customer focus and flexibility it engenders in the software development process. As a consequence, agile contributes to increased customer satisfaction. But some companies base their adoption of agile development on long-held misconceptions and, therefore fail to reap the rewards of the methodology. Hopefully, these comments counter some of these misconceptions and, in so doing, help companies get agile right.