When we reward people for becoming increasingly specialized, when we reward projects only for delivering on time and budget, then we make it difficult to impossible to implement some of the core Agile practices (co-location, dedication, responding to change, focus on business value). Introducing good software engineering practices to support Agile development, such as modular development, architectural practices, coding and programming standards, and Continuous Integration, can also be surprisingly difficult to implement because of specialization, a desire to not lay off people, confusion about how to promote and reward people, and even problems with accounting.
Different companies will have different answers as to how far they want to go along the Agile adoption curve. At the same time, we have to recognize that most major corporations will continue to do some work using Waterfall, and so the changes we suggest to support Agile cannot break Waterfall. What are some of the challenges of making the changes to better support Agile? If your company does A, and decides to change to B to better support Agile, what are some ideas for how you get from A to B and what are the potential impacts on the organization? Also, can you stop part way to B and still get benefit, or do you really have to go all the way.
This presentation will equip you with the knowledge you need to talk with your managers about whether to adopt Agile practices and how far you want to go in your Agile adoption.
