For the past decade, Agile has been a buzz word that has passed by every business and developer in the software industry. It offered many solutions to practical issues created by the Waterfall model, which originated in the manufacturing world where it is better suited. Agile's iterative approach naturally encourages adaptive planning, faster delivery, and more flexibility. This reduces the feedback loop from concept initiation to customer interaction. This along with other retrospective techniques allow teams to be "responsive to change." Scrum, which is an Agile framework, has a continuous review process that provides an opportunity for the team to reflect at the end of every sprint. During this retrospective discussion individuals examine the good, the bad, and/or the ugly that encompassed the sprint. This is where the power of Agile can accidentally lead to its own demise. There are two potential pitfalls to avoid.
Lack of Team Member Buy-InMost 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 ProcessGiving 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.
CodeProject