Agile Teamwork is a secret that make common people achieve uncommon results. How ?

Hindsight refers to the lessons we learn from the life including from IT projects. It emerges from our reflectiveness to evaluate what we did in the project and what we could have done better. Hindsight protects us from repeating our mistakes. Foresight, in contrast, refers to the intelligence to understand which actions will lead to which consequences and thereby choosing our actions wisely.

In Agile transformation, the hindsight (waterfall mindset) interferes with the foresight when instead of learning from the past, many Project Managers and Developers start living in the past.

Suppose your Waterfall project bus drives through a pothole (customer dissatisfaction, too many bugs, delayed business value) and the whole IT team get severely jolted. If the whole team pauses and looks back to see where exactly the pothole was and how they missed spotting it, they can avoid it in future. Instead, team member finger points to the driver of the project ( the Project Manager) making him fully responsible for the outcome. And, Project Manager finds an excuse to mitigate such blame by convincing top management that it would not happen in future. And, the history keeps repeating, sometimes it is a pothole (poor risk management), sometimes it is low fuel (resource issue), sometimes it is faulty equipment (obsolete technology), and often combinations of all leading to the poor project outcome.

In the Agile methodologies, this mentality of "one man army" ends because now every member of the team has a role in keeping the bus moving and making the drive a pleasant journey, and the team keeps checking the oil levels, tire pressure, fuel gauge in the form of Agile metrics (also known as Information Radiators), keeps eye on the road and help avoid the potholes. The team becomes truly cross functional, the every team member not only knows how to read the oil levels but also, if the time comes can change tires. Such practices foster the climate of rapid feedback and continuous improvement. This also ends the talking point in the meeting like “All I can do is change tires, if you want to change oil contact another person".

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 

Try to recall your most recent Waterfall project that you have been part of. You would be able to point to at least one team member that you thought was very critical because s/he was the single point of failure. If s/he doesn’t deliver or delay the delivery, the whole project gets delayed!! If the team has the cross functional skillset, it certainly helps mitigate the risk of single point of failure.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 

Only thing managers have to get comfortable with is letting development teams self-organize around their work during each iteration—not just who does what, but how much the team is committed to delivering. Developers, Testers, and Operations Engineers must learn to work side by side throughout the project, sharing responsibility for quality, stability, and performance instead of just “throwing it over the wall” to the team downstream. And everyone must embrace the idea that shipping fewer, high-quality features are better than shipping a bunch of features that don't quite work right. 

The best architectures, requirements, and designs emerge from self-organizing teams. 

Coming together is a beginning. Keeping together is progress. Working together is success. - Henry Ford.