Text of Large drupal site builds a workshop for sxsw interactive - march 17, 2015
1. Large Drupal Site Builds SXSW Interactive, 2015
2. Who the Heck are We? Rob Ristroph Technical Architect at Acquia, a digital experience company based in Boston, MA and with remote team members worldwide. Based in Austin, TX! ATX Hacker Space Member Drupal/Open Source contributor
3. Who the Heck are We? Jenn Sramek Sr. Engagement Manager at Acquia, based in the San Francisco Bay Area Manage large-scale Drupal projects for organizations and companies that are often new to Drupal Formerly Dir. of Operations at CivicActions Board President for the Haight Ashbury Food Program
4. Who the Heck are We? Alex Urevick- Ackelsberg Co-Founder/CEO of Zivtech Extensive large Drupal project experience Wears many hats Nick Lewis Site Architect at Zivtech Extensive Drupal site architecture experience Sock Puppet Master
5. Who the Heck are You? Drupal experience? Large-scale web? Open Source? Have an active/current large-scale project? Planning one? Waterfall/Agile? Local/from other states/countries? Anything else interesting?
6. Logistics Connectivity Power/Wireless Biology Restrooms Food/Drink Overall Schedule 9:30 am - 1:30 pm Shared Notes and Resources https://pad.lullabot. com/p/Large_Drupal_Sites_Workshop_SXSW_2015
7. Topic Overview Project Management - whats different about big projects ? Technical: Development workflow Custom APIs and the ecosystem of API consumers Scaling and performance at the enterprise level - configuring cache, finding bottlenecks Large-scale data migration Monitoring Social: Open Source and corporate culture Training Larger development team dynamics - culture of quality Multiple teams and vendors Tell us what to focus on
8. Defining Large Projects SXSW Interactive, 2015
9. What is Large? Customer has a lot of money ? Site has a lot of traffic or data ? Project build runs for a long time ? Whatever is pushing past your comfort / experience zone in some way.
10. What is Large More than one website Platform and distribution builds Another team uses your platform or distribution Multiple stakeholders Company vs. Divisions or Franchisees Technical vs. Marketing departments APIs and System interactions mail delivery SSO authentication, including roles and other metadata Web metrics Workflows, editorial processes Significant migration of data
11. What is Large Content Staging Workflow on steroids / between servers Inflexible legal requirements Solutions Content staging server and clone Site Preview System (SPS) Deploy suite of modules Challenging, Interesting and Fun Inter-disciplinary development Complex feature development Cutting-edge interaction design
12. What is Large The most common single feature of a large project is the interaction with more team members and more stakeholders.
13. Working with Large Teams Working with large teams is the most likely source of project failure... If you are new to big projects, interacting with and managing big teams is probably the most unfamiliar area and the greatest area of risk Even large organizations can fail at large project implementation repeatedly All the same technical issues that show up in large projects can show up in smaller projects, but it is harder to maintain clarity, quality code, expectations, and scope when dealing with large teams
14. Working with Large Teams You start with a client / customer Add a design / strategy vendor Add another developer team on the customer side Add other outside developer team(s), with sub-contractor relationship Add multiple other vendors, with no sub-contractor relationships Separate projects with out-of-sync timelines All still working on the same project with ultimately the same goal for success...
15. Working with Large Teams Timeline differences Scope differences or gaps Resource gaps Process differences Deliverables differences or gaps that may be significant Coordinating vacations/time off Internal team mentorship, developer ladders, or other process for fully on-boarding new team members (including client)
16. Working with Large Teams Multiple parties make DevOps essential Practices that just provide efficiency at the scale of one team become absolutely necessary: Pull request workflows Peer code review Standardized development environments Automated testing Tech demo ?
17. Working with Large Teams The most rewarding parts of big projects Personal growth and learning Exposure to other teams is like having several jobs without switching bosses Part of a larger community
18. Getting Large Projects Pick the projects, dont let them pick you Initiate contact with particular clients and projects that interest you Talk with your whole team when going after something large Long term projects should be something people find fulfilling Winning by the lowest bid is a red flag Spend much more time vetting/ do formal Discovery Be picky; build padding into quotes
19. Picking a Vendor Is the vendor interested enough to be committed to a long project ? Unrealistically low bids are a red flag Budget for discovery, and pay for it If the vendor has not done projects of your size before: Allocate more to planning Smallest MVP possible A partnered bid may mitigate some risk If you fall behind, cut scope instead of adding resources
20. Overall Process and Project Management SXSW Interactive, 2015
21. Project (Program) Management Overall... The basics become essential JIRA or another tool Discipline in using that tool Communications and Report Generation is key, and may involve X-facing veation Reporting is part of the effort of a Project or Program Manager More project managers on different teams, coordination Often multiple JIRA instances and trackers in play On big projects, project managers can really shine and make an obvious difference, and technical people who hate it are more likely to be able to avoid it (not necessarily a good idea ?)
22. Discovery for Large Scale Drupal Curiosity is a Skill...
23. Discovery for Large Scale Drupal Discovery is really a very long list of questions to answer before you start development: - Create shared understanding of the work to be done and its priority, and start technical requirements docs - Align everyone on the process that will be used for development, quality assurance, signoff/acceptance - Surface any risks or potential issues that will require mitigation planning - Document any schedule or resource considerations - Right-size the effort of development
24. Discovery for Large Scale Drupal Technical Requirements: - Content types and fields - User roles/permissions - Content and site management workflows - Integrated service requirements (CDN, analytics, single-sign-on, Translation Management Services, payment processing, feeds,) - Migration details (size and complexity of database, content type/field mapping, consistency of data) Non-Technical Requirements: - Resources including third-parties, dev team(s), schedules, dependencies, internal technical resources, training needs - Internal timelines and schedule constraints (vacations, major internal events, conferences, product releases) - Security/Governance workflow and approval process (incl. clearance for those with data access and secure systems for data transmission and storage) - Access to associated systems and tools
25. Planning for Large Scale Drupal - Timeline - Dependencies - Risks and Mitigation Planning - Resources (considering attrition of internal and external teams) - Technical/Architectural planning (including POCs/rapid prototypes) - Code management - Security management - Plan for addressing technical debt - Governance (assignment and acceptance) - Maintenance plan, development cycles, post-launch - Pre-launch/Post-launch planning
26. Planning for Large Scale Drupal Involves LOTS of technical-specific planning (by the architect). A site architect may do as much technical planning as the PM does project planning (code management, maintenance, release planning, etc). Documenting risks protects everyone, and the project Interim maintenance and remediation Documentation needs may differ for large projects
27. Now that all the pieces are in place... Waterfall? OR Agile?
28. Working with the MVP
29. Tools for Large Scale Development SXSW Interactive, 2015
30. Tools for Large Scale Development Plan for tools to scale - know what happens to them when the project is over Ticketing system Document repository Code Management tools UX/Design Management tools Communications Channel(s) Training tools
31. Tools for Large Scale Development JIRA/Rally/others - plan for tools at scale and know what happens to them when the project is over. Code management tools - Github, BitBucket (more integrated with JIRA for one PR per JIRA ticket) Process more than product Onboarding dev documentation. UX/Design management tools - differ by firm, many use BaseCamp Living document for coding/best practices/standard practices
32. Development Managing multi-team interactions Deployment tools and procedures will take up a lot of time Delays between code and UAT Deployment and DevOps can have huge (%30 ?) impacts on efficiency Re-work is the biggest cost
34. Iterative Development Developers cannot JUST develop, have to document how they developed. There is a much larger team depending on clarity. Can effect technology choices Iterative can differ at the enterprise level There can be more than one effective Agile team Include maintenance rou