Efforts on Hydramata have been refocused toward the Hydra Works community effort. These pages are kept for reference but will no longer be updated.
Roles for the Hydramata project
Required: each sponsoring partner must define, at a minimum, these roles:
Project Director (1 per partner)
Product Owner (1 per partner)
Team members: developers, UI/UX specialists, QA specialists, tech leads, QA leads, Subject Matter Experts (SMEs), system administrators. (number variable per partner, but each partner must contribute some team members)
The partners must also identify one person who will serve as the Scrum Master to the project.
What is the responsibility for each role?
Project director (campus director). Each institution must identify a single person who is responsible for helping to develop the high level vision for Hydramata. The Director is responsible for communicating with senior stakeholders at their institution, for the commitment of resources, and for helping to guide the overall process. This individual should expect to contribute 5-10% of their time to the project. The Project Director (PD) should be present for demos and sprint planning sessions, but are not required to participate in daily standups. PDs work with Product Owners to contribute input on the timing of releases and ordering of features. While the (PDs) do have overall authority on the project, on a sprint-by-sprint basis they are not directly guiding the work of the team, and are not adjusting priorities in sprints. PDs meet by phone biweekly.
Lead Project Director: one member of the Project Director group will be appointed lead; this appointment is expected to rotate. The Lead PD responds to requests for feedback from the Lead Product Owner, conducts regular PD meetings and coordinates communications from the PD group as a whole.
Product Owner (campus product owner). The Product Owner (PO) must understand the high level vision and translate these needs, in conjunction with the other campus POs, into a detailed product vision. The PO's will connect with local stakeholders such as users and SMEs to gather user stories grounded in real work practice. Based on this stakeholder feedback the PO's may work with the PD's to refine the product vision. The PO then writes and selects the stories that drive development and coordinates the work and input of SMEs. They maintain a Backlog of stories for future sprints. The PO determines the priority for work. Only the PO pulls stories or bugs into the current sprint (and in the case of Hydramata, only the Lead Product Owner does this). This individual should have some experience with software development projects and should expect to contribute at least 25-40% of their time to the project. The POs should attend daily standups as much as possible (Lead PO is required to attend), sprint planning (and pre-planning) sessions, and participate in demos and retrospectives.
Lead Product Owner: one member of the Product Owner group who is primarily responsible for making sure stories are written and ready for work, and for responding quickly to any questions from the team members. The Lead PO must be available to answer questions from the team within minutes or hours. The Lead Product Owner is responsible for seeking feedback as needed from the Lead Project Director, and solicits input from the Team, and the Tech Lead in particular, as needed in the development of stories. The Lead PO is required to participate in daily standups; the Lead PO should have a backup designated. It is expected that the Lead PO will devote at least 50% of his/her time to the project.
Team members all partners are requested to also identify individuals to fill these roles. Team members demonstrate their work at the end of each sprint, participate in the sprint retrospective, and plan the next sprint with the Lead Product Owner. Team members 'task out' the stories the PO has selected (more detail in Sprint process). Team members are not assigned work, they are expected to break down stories into specific tasks, and then to 'pull' the tasks that they will work on. At each morning standup session, each active team member is responsible for providing three basic pieces of information: 1) what I worked on yesterday, 2) what will I be working on today, and 3) what is blocking me from proceeding with this work (technical problems, dependencies on other tasks, conflicts with time commitment, etc.). All team members are responsible for making sure their technical environments, including tools used to demonstrate work, are functioning properly and are tested prior to standups and demos. Specific types of team members include:
Tech Lead. The Tech Lead is an advanced team member. The Tech Lead pulls tasks and contributes to the work of the sprint. This person is responsible for understanding the technologies deployed and providing technical guidance to the team and PO. This role will work in close coordination with the PO to produce requirements and may be involved in writing finer level user stories. The Tech Lead should be available to the rest of the team to help answer technical questions and remove road blocks, and should be available to respond within minutes or hours. When requested by the Lead PO, the Tech Lead may produce planning documents or participate in planning conversations, capturing the overall technical vision in keeping with these planning conversations, and tracking contributions coming in to make sure short term goals are met while aligning to the long term roadmap and vision for the system. Helps the team take the stories written by Product Owner and decompose them into tasks to drive work.
UI/UX specialist. This person is responsible for developing wireframes and other design specifications to facilitate development. This role may be filled by more than one individual at a given campus, in which case that campus should identify one UI/UX specialist as their campus lead. As possible, the UI/UX specialist will observe actual use and provide to PO's based on user experience.
Developers. Developers write code. specific expertise and time commitment will be variable but no less than 30% time is desirable for any individual assigned to the project. Developers are likely to be assigned to project in chunks of two weeks corresponding to sprints, with a minimum of 2 sprints of advance notice.
Quality Assurance (QA) specialists; validation of the work of a sprint would be the responsibility of a QA but may be balanced across institutions.
QA Lead. The QA Lead is an advanced team member. They will create and implement testing plans to validate the behavior and functionality defined by stories within each sprint. He/she will work with the PO(s) and developer(s) for each story to capture the acceptance criteria. The QA Lead will then automate testing of acceptance criteria as much as possible to make testing efficient and repeatable. As necessary he/she will direct others to help create automate tests or perform manual testing. He/she will also automate tracking changes of dependent components into the continuous integration process to ensure overall quality and stability of tools. All of the work of the QA Lead must be expressed in tasks attached to stories in the sprint.
Subject Matter Experts (SMEs) - possess expertise in some specific area (metadata, repository service/support, content/data models, policy, etc.), time commitment variable, likely to be told by the Product Owners when to engage and to come and go from the project.
System Administrators - deployment strategies, test and production infrastructure will be needed at participating institutions to brand, configure and test the use of the Hydramata within the local institution and to support QA activities.
Lead project roles
Beginning in November, 2013, the participating partner institutions, through their campus directors, will define a process for selecting a Lead Project Director, Lead Product Owner and overall project Tech Lead. These positions may rotate over time, and the campus directors will also outline a process for assessing the effectiveness of the individuals in these roles.
Lead Project Director (described above): Rick Johnson; Claire Stewart backup (as of March 2014)
Lead Product Owner (described above): Julie Rudder; Linda Newman backup (as of March 2014)
Tech Lead (described above): Jeremy Friesen (as of March 2014)
QA Lead (described above): Chris DeLuca (as of March 2014)
Scrum Master: The Scrum Master makes sure the project participants are following the rules of scrum, is responsible for running daily standups and the sprint demos, retrospectives, and sprint planning sessions. Makes sure active team members report out about what they are working on on a daily basis and identify anything blocking their work. Scrum Master is responsible for clearing blockers, which will likely involve coordinating with a number of stakeholders. In particular, the Tech Lead must work closely with the Scrum Master to identify and remove and technical roadblocks to the completion of current sprint stories, including helping team members with individual tasks and stories. The Scrum Master organizes the end of sprint demo, asking Team members to identify who will demonstrate what story, and being available to help them test their screen sharing prior to the start of demo so that time isn't wasted. In a traditional scrum process, during standups the team members go in random order for their daily report. Based on experience so far with Hydramata, it seems to work better if the Scrum Master assists by asking for reports by currently open story.
Onboarding for new participants
The Project Director or the Product Owner for each campus is responsible for making sure new project participants are alerted about the onboarding process, and letting the Lead PO and Scurm Master are alerted so that onboarding meetings can be scheduled. As new team members are added, depending on their specific role (metadata SME, developer, etc.) they must schedule time to talk with these participants (can be combined into a single meeting depending on individual preferences):
Lead Product Owner. The Lead PO will give the new participant an overview of the process and the product that is being built. Will explain what stories are and what work is complete, what's underway, and what lies ahead.
Scrum Master. The Scrum Master will review the rules of scrum and make sure the new participant understands the process, the roles and responsibilities within the project, how work is described and broken down, and the rhythms of daily and weekly work.
Tech Lead for Developers. The Tech Lead will talk with new Developers to the project and provide an overview of the code as needed, helping them to gain access to code and systems as needed.