Scaling a Drupal team for an enterprise project: Keeping agility; Finding and keeping superstars; Building team cohesion; Selling Drupal to nervous clients.
Case study:
Active communiy 100000 users migrate 65000 content items from multiple sites in 9 months.
Internal team of 100 people? [Wow, that seems a lot on content alone. What was functional spec like?]
Team - get senior people - hire superstars [?]
Have to spend a LOT of time on recruitment
Build the team; empower them to deliver themselves; clear management structure (who to talk to). But in the end got very flat. SMT > representatives > everyone else
External supplier help - time difference was good; communication lines needed to be well kept; Skype to India. Get quality correct from the start.
Selling Drupal to stakeholders - budgets being blown before anything comes on board; compare OS side by side with Commercially available off-the-shelf (COTS): Stability and features
Agile v Waterfall; Waterfall wrapper roung Agile project [we tried this with mixed results: tensions; redundancy of processes]
But use what works: e.g. 10-day sprints - started to evolve into Kanban (driven by team members themselves); cross-functional scrum teams.
Backlog with components e.g. search; Increments within components; Prioritized: No point in over-engineering before time
Formal signoff from stakeholders, that client SMT product owners could embed in teams and had the responsibility to say yes or no without referring back.
Standards, Testing: automation and manual, Accessibility, Release management, Code submission, Config management - Puppet
Open-plan office [can it be stressful?] Seat teams together? Worked and didn't work.
Communications: Daily standups, Informal and formal. Struggled with meetings - tried to make short, open, honest and frequent, and "just enough"
Match IT toolkit to role: Make support as easy as possible; Convince IT team to give you control.
