Hydra for Managers - Hydra Connect workshop

The following areas were covered in the Hydra for Managers workshop at Hydra Connect, January 21st 2014

See also the presentation used in the workshop attached

How does Hydra fit your needs?  Why would you choose Hydra?

• Community
• Shared purpose
• Different problems/issues exist at different institutions: Hydra is a way of working together to address these
• Not just a quick fix, building flexible and sustainable technical solutions
• Share approaches, not just the solutions

How to find staff for a Hydra implementation (aside of hiring staff directly)?

• Job for hire
• Consultants / temp agencies
• Cross institution contracting for short periods
• Headhunters (expensive)
• Student internships

• Training can overcome resourcing concerns
  • Hydra documentation – ongoing development can also be training materials in their own right
  • Webcasts (e.g., Railscasts)
  • Ruby tutorials (e.g., Michael Hartl tutorial, Rails for Zombies, Code School)
  • Face-to-face benefit of Hydra Camps
  • Dive into Hydra tutorial – self-paced curriculum
  • Contribution of tutorials based on experience is welcome
  • Resources need collating
  • Gaps:
    • Scrum master training
    • Product management
    • Developer partnering within the community can be of help
    • Knowledge transfer (maybe informal, currently?)
    • Librarians learning to code
      • Metadata management can be a crossover area

How to progress further discussion?

• Engagement with head developers in Hydra to assess activity and fit
• Managers IRC?  There is need to enable people to ask questions.  Focused online meetings perhaps
• Big Hydra project plan would be helpful (to help build local business case)
• Working together to address issues that arise in coming new to the community
• Tackle common issues in migration from different systems
• Develop better ways to evaluate solution bundles for potential use

Key steps

• Focus on what you want to do
• Be guided by developers on how this can be done

Working with Hydra.  Development and Management roles/costs/issues

Three approaches:

• Self-directed – Rock’n’Roll, get involved in the community
• Small – Hull, WGBH – both used DCE, limited local development capacity
• Large – UVa (and Hydramata) – more structure, more collaborative, but also agile

Hydra environment:

• Pairing developers (experienced and new)
• Multi-institution projects can sit alongside each other within the community
• ‘Intentional, robustly messy’ – Tom
• Code sharing – gemification and open github sites.  Collaboration improves local QA
• Focus on maintaining as little code as possible locally, and use shared codebase
• Functional awareness – partner sharing, engagement, screencasts, ask via hydra-tech!  Use of the list is encouraged for questions

What do you need to get going with Hydra?

• Manager skills – precise skills depends on the nature of the project
• Established software engineering practices, and articulating why these are important
• Stamina!
• Relevant project management style (e.g., agile)
• Technical management
• Break project down into chunks
• Technical architecture skill, so as to control how this develops
• Community engagement

How is it working with Hydra?

• Hydra philosophy – informs the specific nature of working with Hydra
• Enabling rather than managing
• Working together as colleagues
• Involving everyone necessary in conversations

Hiring staff to work on Hydra

• Hiring – UVa focus on understanding the Hydra Way, not specific Ruby skills.  Don’t overly focus on the code language
• Emphasising the benefits of working for a library

Engagement

• Review webpage and wiki – there’s lots there
• Many hands make light work – all contributions welcome
• Add generic list for queries, focused on managers (hydra-users@googlegroups.com will be re-launched for this)
• Open to ideas for further engagement activities

Questions

• What helps to aid decision-making?
• How do we best communicate event information to those coming new to Hydra?

Requests

• Case studies of technical set-ups would be helpful (hardware, software, personnel, other resources) – information on how to start
• Guidance on how to enable organisational change to match technical change
• More on metadata standards being used
• Guidance on migration from other technologies would be helpful

Chris Awre/Karen Cariani

January 2014