Pitfalls in Agile Software Development

We all know that Agile software development is a surefire way to produce results oriented, client satisfying, and measurable software development. While there are tons of white papers, blogs and project success stories to justify this methodology, there is comparatively less material dedicated towards the pitfalls in Agile Software development.

This post is a quick recap of some of the most common risks / pit-falls associated with this methodology and is primarily oriented towards Project Managers who would do well to note and research more into these risks as they make their foray into the realm of Agile Development.

• Agile is not best  suited when… the system being developed is a mission critical application where there is no room for an iterative approach to development or where all the specs are clear upfront and the deadline and scope are not flexible.
• Agile is not best  suited when… only a few people on the team truly understand the Agile methodology; it’s important that all members of the team understand how the framework works. You cannot advance the project very successfully by the “it’s my way or the highway” approach.
• Agile is not best  suited when… your teams are geographically separated and communication is minimal.
• Agile is not best  suited when… business and IT have never had a record / history of working together throughout the software development life cycle
• Agile is not best  suited when… business team members are too title oriented, inflexible to adopt a new role, or unwilling to spend time with the development teams and be available on call to resolve issues or clarify scenarios.
• Agile is not best  suited when… teams are not capable of being self organizing, or lack the ability to self-manage deliverables and timelines.
• Agile is not best  suited when… an organization recognizes its lack of experience in Agile methodology but refuses to bring in coaches and mentors who have strong experience in implementing using Agile.
• Agile is not best  suited when… when employees are not used to being very communicative.
• Agile is not best  suited when… the business is not ready to be flexible in differentiating between critical functionality versus non-critical functionality and thereby adopting a non-compromising attitude towards functional requirements.
• Agile is not best  suited when… core requirements are not understood well thereby leading to the inability to produce a stable core architecture where only feature level requirements are expected to morph.
• Agile is not best  suited when… teams are ready to begin work on small pieces of functionality without a full understanding of how it fits into the bigger picture.
• Agile is not best  suited when… unknown technical challenges usually in the form of attempting something that has never been proven to work before is part of the core functionality.
• Agile is not best  suited when… an organization’s culture thrives more in order than in chaos
• Agile is not best  suited when… when teams are very large
• Agile is not best  suited when… impact of defects on functionality is very great

The above are just a general rule of thumb and could be debated. But then for the Project manager who lacks the time to research the pitfalls of Agile development, the checklist above would serve as a quick and handy guide.

As a practicing project manager, I have delivered quite a few mid and large sized projects using the Agile framework while breaking a few of the above thumb rules. But since I was forewarned due to my knowledge of the above, you can say I was also forearmed. Ultimately, understanding the framework and planning for contingencies is still key – but then that is part of Project Management.