Here are my initial notes on the Jutta Eckstein presentation on scaling agile development across large teams. Cleanup may follow :)
Scrum of Scrums
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)
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
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.
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
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: