Click here to Skip to main content
13,766,675 members
Click here to Skip to main content
Add your own
alternative version

Tagged as

(untagged)

Stats

6.3K views
1 bookmarked
Posted 12 Sep 2013
Licenced CPOL

Don't Agile Your Way Back To Waterfall

, 12 Sep 2013
Rate this:
Please Sign up or sign in to vote.
There are two potential pitfalls to avoid.
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-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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author


You may also be interested in...

Comments and Discussions

 
GeneralNice insights Pin
Grump2-Oct-13 7:45
memberGrump2-Oct-13 7:45 
SuggestionNeeds Much More Depth Pin
GrantAnderson16-Sep-13 12:10
memberGrantAnderson16-Sep-13 12:10 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web01-2016 | 2.8.181114.1 | Last Updated 12 Sep 2013
Article Copyright 2013 by Unknown Author
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid