Agile Scrum vs. Waterfall
Agile scrum environments often enable business representatives to work closely with small teams, including scrum masters, developers, designers, and quality assurance assistants. When agile principles are followed, when there is transparency and when teams are enthusiastic about the process, the increase in quality communication is very beneficial.
Having had the pleasure of working in such an environment offered a front row seat to the benefits of agile. One concept promoted in agile is to have dynamic teams develop around projects as needs arise. This allows periodic team changes which helps avoid falling into a monotonous rut. It can also encourage knowledge transfer and sharing of skills. Dynamic team creation also helps members to see what practices make some teams more productive and what can hinder production.
One observation: in some cases, team members can lose enthusiasm, for example if team members have a sense of being micromanaged, or overloaded with work. If some team members feel their job is in jeopardy, especially if they are co-located, the transparency needed for agile to work can break down. Much of this depends upon the skill of scrum masters and product owners, who may be perceived as the unofficial leaders of the team. The term “unofficial” is used because, with agile, the concept of a “leader” is not emphasized. “Stakeholder” is the preferred term. All who have an interest in the project are stakeholders. This supports the “scrum” team spirit.
With the waterfall method, there usually is no attempt at disguising who the leaders are, but good leaders know they must foster team spirit. If a scrum master or product owner is determined to play the role of dictator, or a leader who does not foster team spirit, putting an agile scrum label on the workflow won’t make a difference.
Check out this video for a discussion on Agile vs Waterfall.