Ten Agile Pitfalls

Agile is not just a methodology, but a set of principles, and a philosophy.

The business purposes of taking Agile methodology is to adapt to change, improve customer satisfaction, and enforce communication. Agile is basically dialogue applied to application development - an iterative process of "thinking together." However, if the people involved have limited skills for thinking together, then agile won't work well at all, as an emergent methodology, Agile causes certain confusions or even failures, what are the potential Agile pitfalls? 

1. An Agile methodology is not a good fit for the organizational culture, criticality of the project, or the team personalities. For example, in a very rigid top-down organization, Agile is going to really struggle.  Functional Matrix and Agile don't go together, it introduces more unnecessary politics. 

2. The team isn't really using an Agile methodology, they just say they are. To be effective, an Agile approach requires the use of strong software engineering practices, it does require discipline and a collaborative leader to focus on the team and ensure they are following best practices and approaches. You need to be able to tell the difference between "Cowboy Coding" and using a real Agile methodology.  

3. The team isn't using an Agile tool to manage their work and project; or worse they are trying to cram an Agile project into a Tool that was never designed to manage an Agile project.
       
4. Looking at Agile as a singular project methodology and being concerned about the variations in a solution that can occur. Methodologies, architectures, languages etc. are only tools to help get the job done, not an end in themselves 

5. The team isn't integrated. Agile is all about the team working together as one. If it is only the software developers who are working in an Agile fashion, but everyone else: Business Analyst, QA, etc. aren't working with the team and are operating in more of a push throw over the wall methodology; then you probably won't have much success. It is critical to have all key roles integrated within the team and working as one. 
   

6. The Business Customer simply isn't involved or doesn't care to be involved. For Agile projects, it is important to have the primary SMEs and Business Customers involved in the project. Poor requirements gathering have more to do with the "business" than IT - which is only true until IT experiences the consequences of the failure. 

7. The Team wants to operate in an Agile (Pull process), but Management has not adapted and is still thinking in a Push model: trying to push more work onto the team as quickly as possible - without taking into consideration the Team's capacity and what they can accomplish within a given Iteration or Sprint. 

8. Agile is used as an excuse by some for not executing engineering & management discipline that has been long and hard won. If you really execute Agile well, then it has more effective control, communication, metrics than waterfall. 

9. Simply doing the mechanics of Scrum, XP, DSDM, etc. doesn't make a project 'Agile'. What makes a project 'Agile' is adherence to Agile values and principles. From a governance perspective, typically you would align a team to support one or more business units or applications, and you fund the team for a given capacity - measured in software points 

10. The fundamental problem of managing vendors and requirements. The whole point of agile development (and really, all of the iterative, rapid prototyping development frameworks) is to focus on many iterations of task-level work, operating in parallel across the whole of the product, making extensive use of feedback to rapidly bring working software (as opposed to non-working models) to completion.Architectural design, structure and integration are crucial in long-term project success. 

Posted in: Agile,Lessons from Failures,Project Management