Don't Agile Your Way Back to Waterfall
Lack of Team Member Buy-in
Most companies run into this situation when introducing Agile or new team members. Individuals tend to attack the process of Scrum, Kanban, or any other framework because they are frustrated. It's common to hear phrases such as, "It's not applicable to our project," "This gets in the way of doing our jobs," "We cannot move faster than we are already going," and "That might work at other companies, but not ours." It's imperative to have management buy-in and proper representatives in these retrospective meetings who continue to champion the Agile concepts. Encouraging constructive feedback is an essential part of Agile, but it's important to make course corrections that are in line with it's core principles and how a company chooses to implement them. Throwing out Agile processes because "we don't like them" or "we don't understand them" is not acceptable.
Process for the Sake of Process
Giving teams the ability to review their own process is a powerful tool. It gives them the ability to analyze where they are, identify what they can do better, and recommend areas for improvement. This can lead to teams with attributes such as lean, efficient, fast, reactive, and reliable. Although this is an amazing tool, it should be managed and contained. Without proper guidance, teams may have a tendency to fall back on old Waterfall habits. There is a natural impulse in most developers to fix a problem by creating additional process. This can be a positive step forward, but too much process can start to put teams back into a Waterfall model. When deadlines are missed, the feedback loop is extended, or opportunity and innovation are stifled, there might be too much process in place. Carve out a recurring opportunity to revisit existing processes, procedures, ceremonies, and expectations. Identify areas that might be inhibiting growth and provide a venue to rehash their purpose within the larger picture. This will help maintain a positive Agile mindset.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)