Software in the large

Here are my initial notes on the Jutta Eckstein presentation on scaling agile development across large teams. Cleanup may follow :)

Scrum of Scrums
Crystal

Iteration Duration: larger the team, shorter the development cycle
per week, count on a half day of retrospective (two week cycle = 1 full day retrospective)

Expectation: plan/develop/deliver.
Difficult - activity-oriented planning or component-oriented planning?
Therefore: Result-oriented planning. Focus on the features! Comes back to the Agile Manifesto: Our highest priority is to satisfy the customer.

Plan for accomplishing a valuable feature: integration, test, documentation.
A feature is a brief statement of functionality, from the user's perspective
How does one deal with architecture issues?
A feature produces a measurable result.

Iterations are steered by features, but defined by tasks

Tracking tools: PPTS, TRAC
Someone also mentions they use Sharepoint
Or just three checkboxes: working on it, untested, done done
Tools support communication, not replace it

Release Planning

Iteration review (Demo)
Present software, recognize & extract best practices, learn from failure

Measurement: Acceptance tests, planned functionality, is the product owner satisfied?

Retrospective after every iteration. Likely problem that people try to make large-scale changes

- Cross-functional or feature teams
- A large project might have tech teams; the customer of a tech team is a feature team

An ideal team is self-organized; this ensures whole features and good knowledge sharing. Managers must provide environment allowing teams to gel. This is like my ACG posts from a few months ago.

Trust

Agile development is a trouble detector. Bad news is also good news. Integration of departments (Projects are customers) Close customer relationship ensures rapid feedback.

Discussion of implementing practices a few at a time. Ping-pong implementation!

Synchronization: Face-to-face is preferred. Sync across subteams daily (Scrum of scrums). If your team is self-organizing how does that work?

Communication via wiki

Just one "Chief architect" - pulls the strings, makes technical decisions, "guiding light". Relationship of chief architect and customer?

Starting: take baby steps. Start small. Use skilled people. Develop a few features and make sure to do iteration retrospectives. Grow slowly.

Don't finalize architecture before growing team; use retrospectives. Domain teams must formulate new requirements. (But you might have to finalize to eliminate fear...or at least say it's finalized!).

Avoid hot technology. A large project has enough problems on its own without trying to train developers on something new at the same time.

Refactoring: technical excellence is doubly important. If a developer sees a needed refactoring on another team, they have to point it out to them.

Large projects may have exponentially greater test time. 10% of dev effort for integration/build. (If something is difficult, do it over and over until it's not difficult any more.)
Q: Special iterations for integration? A: no
Nor a special integration team; rather people from each team who specialize in integrating

Reviews:
Special review team. People should jump around between teams, and be on a team strictly for the purpose of reviewing the code. Everyone should do this.

Knowledge transfer (via Daily Scrum and pair programming). Scrum master ensures the process; product owner ensures business value).

Q: Agility in a distributed environment. A: