Mysafety x Econsulate Day 3 Recording 2

Overview of Project Management and Collaboration

Introduction to the Session

• The session aims to align both teams on project management strategies, focusing on lessons learned from past projects.

• Emphasis is placed on collaboration between engineering leads and hands-on teams for effective project execution.

Current Workflow Overview

• A typical software project begins with requirement gathering, requiring significant client participation to understand expectations and acceptance criteria.

• Following requirements, SRS documentation is created, which requires client sign-off before moving forward with estimates.

Estimation and Planning

• After confirmation of requirements, a detailed estimate will be provided that includes timelines and costs based on the finalized requirements.

• Assessment of resource needs occurs next, determining the number of developers and QA resources required based on project urgency.

Kickoff Meeting and Design Phase

Kickoff Meeting Preparation

• A kickoff meeting is scheduled after finalizing requirements and estimates; key personnel from both teams will connect during this phase.

Design Considerations

• If UI/UX design is necessary, Figma designs or visual representations will be shared for client approval before development begins.

• The team is familiar with specific design guidelines but may benefit from additional guidance tailored to the client's needs.

Development Process Overview

Agile Development Methodology

• Development follows an agile methodology with two-week sprints; tasks are broken down into manageable segments for efficient progress tracking.

Sprint Breakdown

• Once estimates are provided, development work will be organized into sprints to facilitate structured delivery.

Sprint Planning and Development Process

Initiation Meeting and Task Discussion

• The development team will hold an initiation meeting to discuss the tasks for the current sprint, focusing on incremental delivery rather than waiting for all tasks to be completed before receiving feedback.

• Estimation of story levels is crucial; final estimations will be shared with the client to ensure alignment on expectations.

Sprint Structure and QA Process

• The typical workflow includes two-week sprints, allowing for a structured approach to development and testing.

• A QA cutoff occurs around Tuesday of the second week, giving QAs three days for testing before deployment to either a QA or staging environment based on client requirements.

Quality Assurance and Testing Framework

• Quality assurance involves executing test cases in the designated environment, accommodating both manual and automated testing as needed.

• The team has its own automation framework but primarily conducted unit testing in past projects; future collaboration may include more comprehensive QA practices.

Deployment Strategy and Support Agreements

• After fixing any bugs identified during QA, deployments can occur based on client preferences—whether sprint-wise or bi-monthly—with considerations for downtime during updates.

• Separate support service agreements are available for clients requiring long-term commitment for bug fixes, including dedicated teams for 24/7 support if necessary.

Expectations from Requirement Gathering

• Clear expectations are set regarding requirement gathering; Pontus serves as the main contact point for user stories and acceptance criteria creation.

• Involvement of senior business analysts is noted; however, expertise in specific domains like insurance may require input from Pontus's team to ensure accurate requirements are documented.

Finalizing Requirements Documentation

• Proper documentation of requirements is essential; discussions can lead to finalized documents that outline clear expectations between teams.

• If provided by Pontus, a document can serve as a guideline. Otherwise, collaborative efforts will create a sign-off document confirming finalized requirements.

Project Estimation and Requirements Structuring

Initial Project Phase and Challenges

• The project will proceed with an estimation phase, allowing Jasper to approve the financial aspects before commencement. Past issues arose from rushed development due to a set deadline, highlighting the need for clearer requirements.

• A structured approach to project initiation is preferred over fixed deadlines. This allows for better understanding of requirements, reducing delays caused by unclear expectations.

Requirement Clarity and Team Management

• Clear communication of requirements enables the engineering team to break down tasks effectively. Any blockers can be identified early based on specified needs.

• Access to necessary systems is crucial; without it, progress may stall. Identifying these access needs upfront helps manage expectations and responsibilities.

Flexibility in Development Process

• Establishing a clear structure before development begins aids in task breakdown and resource allocation. It’s essential for both parties to agree on requirements for smoother management.

• While flexibility is important during the project timeline, knowing potential challenges at the outset helps maintain focus on deliverables.

Ongoing Communication and Mapping Scenarios

• Continuous updates from stakeholders prior to project start are beneficial for planning. For instance, mapping changes during development could necessitate adjustments in coding efforts.

• Learning from past experiences where unexpected changes occurred can inform future projects, ensuring all elements are accounted for before starting development.

Expert Involvement in Requirement Gathering

• Having business experts involved from the beginning ensures that accurate requirements are gathered and approved efficiently, enhancing overall project quality.

• Experts should articulate their needs clearly while being held accountable for their specifications. This collaborative approach fosters better alignment between technical teams and business objectives.

Final Thoughts on Project Execution

• The goal is to establish a clear process where business experts define what they need while technical leads ensure feasibility within broader project goals.

Project Requirements and Development Process

Clarifying Requirements

• The team will validate questions through relevant experts to finalize requirements, ensuring clarity before moving tasks to JIRA.

• Emphasis on breaking down tasks to cater to all proposed requirements, highlighting the importance of documentation in the process.

Integration and Access Levels

• Discussion on the need for application access levels, suggesting that faster integration can be achieved by collaborating with the application team.

• Concerns raised about numerous questions during handover meetings; mapping should ideally occur before development begins.

Timeline and Resource Management

• An estimated two-week integration period is discussed, with a suggestion that refining requirements could take up to three months.

• Team members express confidence in working with Azure DevOps, noting expertise within the team and new recruits specializing in this area.

Team Synchronization and Project Structure

• New employees are syncing with past staff to understand safety domains better, preparing for future projects effectively.

• Acknowledgment of complex vendor relationships affecting project timelines; access levels are crucial for progress.

Internal Coordination and Planning

• Proposal for creating an internal forum called "preview assembly" to ensure synchronization among teams and stakeholders.

• Importance of knowledge transfer (KT) from experienced members is highlighted as essential for managing future projects effectively.

Managing Dependencies and Program-Level Planning

• Discussion on understanding critical components necessary for defining project timelines amidst multiple vendors involved in integrations.

• Need for program-level planning emphasized; coordination between teams is vital to ensure timely completion of dependent components.

Weekly Meetings and Product Planning

• Weekly meetings suggested as a strategy for ongoing communication; leads must participate in program-level planning discussions.

• Importance of pre-development product planning sessions noted, allowing resource persons to clarify upcoming project goals.

Brainstorming and Planning for Development

Importance of Pre-Planning

• Emphasizes the need to define use cases and acceptance criteria before the development sprint begins, ensuring clarity for the development team.

• Suggests a two-week planning cycle to identify potential blockers early, allowing for adjustments in feature prioritization.

• Highlights that proactive capacity planning can enhance project health by avoiding last-minute rushes as deadlines approach.

Sprint Planning and Client Involvement

• Discusses conducting proper sprint planning meetings with reviews to assess progress and completion of tasks.

• Proposes client demos during review sessions to provide feedback on developments, facilitating timely go-ahead decisions for production readiness.

Enhancing Communication and Documentation

• Encourages open communication regarding suggestions from clients to improve project progression and ensure alignment with expectations.

• Mentions the availability of specific templates for requirements documentation while remaining flexible to adapt based on client needs.

Requirement Finalization Process

• Stresses the importance of creating descriptive requirement documents to minimize last-minute questions and revisions, aiming for a single finalized document.

• Advocates finalizing user stories directly from client input to avoid gaps between development output and actual requirements.

Task Management in Azure DevOps

• Queries about how task updates will be managed in Azure DevOps, discussing options for clients either providing stories or having them uploaded by the team.

Project Management and User Story Breakdown

Confirming User Story Structure

• The discussion begins with a confirmation on how user stories will be organized, specifically whether they will be placed in the backlog and broken down into smaller components.

• It is clarified that the major story will be identified first, followed by breaking it down into sub-stories and tasks as needed.

Epic Creation and Documentation

• There is an emphasis on creating an epic after full documentation of the application, which serves as a tracking mechanism for development progress.

• The team acknowledges that breaking down features is essential, especially when dealing with large features stored in the backlog.

User Stories Management

• A consensus is reached that user stories should be documented clearly to facilitate their breakdown into actionable tasks for developers.

• The importance of linking requirements to user stories within the epic documentation is highlighted to ensure clarity in task assignments.

Sprint Planning Considerations

• Discussion shifts to sprint planning, where default estimations and story points are used to prioritize which stories will be selected for upcoming sprints.

• Prioritization of requirements is crucial; items need to be defined ahead of time for effective sprint planning.

Backlog Management and Critical Path Identification

• The team agrees on brainstorming sessions before sprint planning to assess feasibility based on available resources and effort required.

• There’s recognition that some projects may require midway demos or critical path identification, emphasizing the need for prioritizing certain features early in development cycles.

Project Development and Requirements Clarity

Importance of Clear Requirements

• Emphasizes the necessity for clear requirements at the start of development to avoid confusion later in the project.

• Highlights that developers should analyze requirement documents thoroughly and identify any gaps early on, leading to a list of questions for clarification.

Questioning Process

• Discusses how unnecessary questions can arise when team members are unfamiliar with new requirements; it's crucial to filter these out based on relevance.

• Once clarity is achieved, teams will proceed with estimations and project timelines, ensuring all parties are aligned before moving forward.

Expectations from QA

• QA expectations include understanding output files generated during development without needing deep technical knowledge; clarity on approval processes is essential.

• The discussion includes planning for production deployment, emphasizing the importance of UAT certification before final deployment.

Testing and Certification Process

• Describes the testing environment where final specifications will be tested before business involvement; this ensures that all expected features have been built correctly.

• Clarifies that testing must be completed prior to signing off for production deployment, maintaining a structured approach throughout the process.

Maintenance and Monitoring Responsibilities

• Discusses defining environments for maintenance and monitoring; flexibility is key while establishing standards.

• Outlines responsibilities regarding system monitoring, indicating that 80% falls under the technical team's purview while also addressing alert management processes.

Technical Team Operations

• Explains how alerts are managed by developers who identify issues within modules and redirect them accordingly for resolution.

• Mentions collaboration between teams when fixing problems, ensuring efficient communication about module-specific issues.

Knowledge Transfer Challenges

• Raises concerns about internal knowledge transfer as roles change within teams; emphasizes gradual handover due to complexity in understanding MySafety domain intricacies.

• Suggestion made regarding recruiting or reallocating personnel to ensure continuity in expertise as transitions occur.

Knowledge Transfer and Transition Planning

Deep Dive into System Understanding

• The team plans to conduct a deep dive into specific components, aiming to clarify their understanding before moving forward. This will involve documentation and follow-up questions with Robert for further insights.

Handover Process and Team Readiness

• Robert will provide knowledge transfer (KT) sessions on the next system processes, ensuring that the team is well-prepared to take over responsibilities after his departure. Early initiation of this process is emphasized as crucial for success.

Identifying Gaps in Knowledge

• A work description may be created to identify areas needing strengthening or where gaps exist in current knowledge. This proactive approach aims to leverage Robert's expertise while he is still available.

Access Levels and Team Collaboration

• There are concerns about access levels post-handover; it’s essential that the team has shared access similar to what Robert currently possesses, preventing any single point of failure if he becomes unavailable. Collaboration among team members is highlighted as vital for continuity.

Documentation and Knowledge Sharing

• Emphasis on thorough documentation during the transition period is critical, along with early questioning to ensure clarity on processes and systems being handed over by Robert. The timeline for this transition should ideally span four to six months for effective knowledge transfer.

Understanding Roles and Responsibilities in Application Engineering

Identifying Key Personnel

• The discussion emphasizes the importance of knowing the specific application engineers involved, their roles, and responsibilities to establish clear contact points for various applications.

• It is suggested that a concise overview of each engineer's key areas of expertise would be beneficial, akin to identifying doctors in a medical context.

Collaboration and Communication

• There is a need for structured updates on team responsibilities, ensuring business experts are notified about changes relevant to their areas.

• The conversation highlights the significance of having dedicated system owners who can provide requirements and oversee project developments effectively.

Workshop Dynamics

• Workshops with partners often delve into technical discussions regarding APIs and capabilities; bringing knowledgeable resources is crucial for depth in these sessions.

• A suggestion is made to have specialized personnel available during workshops to ensure clarity on primary topics as transitions occur within teams.

Knowledge Transfer Strategies

• The idea of shadowing plans is introduced as a method to prepare multiple team members rather than relying solely on one expert, enhancing overall knowledge retention.

• Emphasis is placed on understanding potential impacts when adding new features or modifications, highlighting the necessity for comprehensive technical knowledge during meetings.

Documentation and Requirement Gathering

• The group discusses documenting processes clearly when upgrading systems or developing new features, ensuring all requirements are well understood before implementation.

• An expectation is set for initial meetings where questions should be prepared in advance; this allows for efficient discussions and clarifications by subsequent meetings.

Project Development and Expectations Discussion

Overview of Project Requirements

• The team aims to create an epic that aligns with business expectations, ensuring clarity on requirements and possibilities for the project.

• Emphasis on maintaining updated documentation is crucial; all members should adhere to the latest versions of guidelines to set clear expectations.

Technical Details and Development Process

• A request for detailed technical insights into development progress, including configurations and summaries of what has been accomplished.

• Developers are expected to provide comments upon closing tickets, detailing the development process and testing outcomes related to each ticket.

Future Planning and Team Collaboration

• Upcoming sessions will focus on sharing learnings from previous discussions, highlighting any outstanding points that need addressing in future meetings.

• The team is encouraged to share insights about potential projects in the near future, particularly those planned for the next quarters.

Market Launch Strategies

• Discussions around launching new markets involve replicating existing systems for new partners while preparing teams for upcoming projects.

• Teams should conduct research and prepare sandboxes for relevant platforms ahead of time to ensure readiness when projects commence.

Roadmap and Integration Challenges

• Current focus includes automating processes while integrating various components; there’s a need for ongoing learning as new challenges arise.

• The conversation highlights concerns regarding project timelines, especially with Hamilton's seamless project completion being a priority.

Discussion on Development Plans and Data Integration

Initiating the Second Phase of Development

• The discussion emphasizes the importance of starting the second phase of the development plan as previously discussed, ensuring clarity on expectations from both sides.

• There is a focus on delivering results promptly once the development plan is established, highlighting efficiency in project management.

• The conversation shifts to data requirements, indicating that going live with minimal bookkeeping is feasible if data integration aligns with financial dimensions.

Challenges in Data Dimensions

• Acknowledgment of challenges where each dimension must be interconnected, suggesting complexity in managing multiple data aspects.

• The mention of "volume and manual" indicates a reliance on manual processes for handling certain dimensions, pointing to potential inefficiencies.