¤ Core arguments - Can have long, interdependent tasks in parallel. - Early integration build allow changes to be made earlier, working with designers ---- - An on-site customer is cheap in a large project :) Cost of failure in huge project if the delivered product was not what was expected - Abundant testing is helpful in large projects - Knowledge about problems and opportunities is easier to make explicit ¤ Good about Agile TDD - maintenence is easier - Refactoring Sustainable pace, much easier to see if progress is on track Gradual refinement of components, can start downstream work with pre-releases Handling changes is very important in long-running projects Continuous/Daily/Weekly/whatever builds is very useful Early testing, yay! Games On-site customer becomes cheap/automatic Easier for "scrum master" or "boss" to be aware of problems in the development and bring it up in a larger context ----------------------- ¤ How to implement Agile (relatively) Easy to apply agile within sub-units Sub-division of tasks - A team of agile teams choose from high-level stories and then agiles them - Could do a "kanban" of "scrum" teams -- Not necessarily estimation of high-level tasks, but keep focus on critical chain! Lack of documentation : Tests, frequent refactoring and good separation mitigate the need, BUT : of course you should document. Don't be stupid. Same room : Could be applied for the smaller groups : Can have a large collection of scrum boards - webcams, trainees Standup meeting : Could be applied for the smaller groups and high level groups of scrum representatives (master?) Transitioning to agile : Depends on how company is organized, can be easy on a team level. Ericsson is doing it! Communication and knowledge spreading : Good separation of functionality, continuous integration and acceptance testing Scaling, growing from a small agile company to a large agile company :