¤ 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
: