3/25/2019
SubTeams and members

• Batch: Sharif, Robert, Dennis, Kweku
• Trainers: JD, Jake, Brandon, Ron, Jon
• PTO: Evan, Patrick, Nate, Oscar
• Testing: Ian, Dan, Rafael, Serjey

Sprint 2 consisted heavily of code leading up to the code freeze. Interaction between teams and team members increased as PTO was being fully implemented, external trainers were being added and batch team were completing timeline fixes and moving logic to server side. The batch team, PTO team, and trainer teams merged members with some PTO team members going over to the testing team. During this sprint, code coverage was increased to 100%. Daily stand ups each morning depicted issues with logic and moving information across to server side logic. Our major issues consisted of learning how events worked, how information is sent from component to controller to apex and back. During the merge, team leads worked together to oversee requirements that spanned over multiple subgroups and attempted to ensure that work was being delegated properly to keep people who working on prior tasks still working under those merged tasks. ex: PTO on timeline, timeline members from Batch team and PTO team working together. In this sprint, external trainers were also implemented into the system. All code and admin changes to orgs were retrieved using SFDX and then pushed to subteam branches and sent to testing in 4 testing pulls and 2 pulls to production.

• Resource allocation: As requirements were hashed out, we shuffled teams around to account for needed tasks.
• Subgroup inter-communication: When the merged happened, groups were able to collaborate better with each other.

• Interaction and clear direction: Able to figure out better what requirements were and how to go about doing them.
• Subgroup inter-communication: Conjoined groups were able to talk and plan out requirements with each other.

• Communication: Increased communication among groups
• Work ethic: Members were willing to meet up after work and talk past hours to fix and update requirements

• Work ethic: More work was done this sprint than last sprint.
• Resource management: Team switch went well with being able to gather information between teams.

• Resource management: Bringing together the teams went really well.
• Time management: Were able to keep up with tasks.

• Resource management: Dividing up the work allowed us to get a lot done.
• Contribution: During this sprint, everybody was able to contribute to requirements.

• Clarity/Goal Orientation: The batch team had a goal and clear path ahead. Was able to implement the goals of calling from the database once, and moving logic from the client side to server side.
• Inter-communication: Communication and working together went well within the batch team.

• Communication: Lots of communication between the teams and the group during daily stand ups. Having a larger 15 minute stand up allowed us to hear more about/from each requirement
• Work Ethic: During this sprint, members had good increased work ethic.

• Resource Management: Splitting up the Batch team allowed batch team members to focus on specific sub tasks.
• Collaboration: Team members did good with figuring out Git branches and getting git collaboration figured out.

• Collaboration: Team members came together over the past weekend to finish the project.
• Team Coordination: Merge helped teams coordinate requirements

• Leadership: Team Leads did good with coming together and delegating tasks.
• Collaboration: Co-workers did good with merging.

• Communication: Best aspect of communication was changing daily stand ups from subgroups to daily stand ups as a larger merged group.
• Work Ethic: Members made themselves available to help others.

• Testing: 100% Code Coverage
• Resource Management: Resources were allocated well.

• Involvement: Got to interact with code more and felt influenced more to work.

• Resource Management: Teams were able to handle the merge fairly well and stay on task.

• Code Clarity: High chart was able to be cleared up.

• Code Clarity: Fixed main issues with the high chart.

• Story Points: Create User Story Points to gauge how difficult a task would be.
• Communication: More Inner Communication.

• Group Sizing: Limit the size of the group to smaller groups.

• Inter-communication: Relay team lead information to other members.

• Requirement Allocation: Spread out our work.
• Communication/Delegation: Lack of communication on a personal level and delegation of work.

• Comprehension: Understanding the tasks at hand better.

• Requirement Allocation: Divide the work based on people’s strengths.
• Foresight/Hindsight: Planning for issues. Looking through code/project as a whole.

• Time/Task Management: Implement requirements that were not started yet.
• Database efficiency: Re-adjust logic to call from the database once.

• Requirement Allocation: Delegate tasks based on people’s skills.

• Synchronization: Could still use more communication to get more members on the same page. ex: Like when trying to transfer client-side to server-side, communication of requirements and processes weren't effectively shared.

• Delegation: Team leads to delegate more and members to complete tasks.
• Time Management: There was a lot of lead focused work near the end, Despite this coding though the time crunch went well.

• Delegation: Delegate work better so team members are given tasks equally.

• Delegation: More delegation. Most work fell on team leads.
• Daily Stand Ups: Have stand ups like were reporting to someone.
• Isolated Working: Don’t work in isolation. Didn’t see other people’s work enough.

• Task Management: Control Planning, like having a more granular Gantt/Task assignment.

• Planning: When merging teams have a little more of a plan so things transition smoother.

• Version Control: Had issues pulling files from git that deleted some files of mine.

• Communication: Team shuffling caused a lot of miscommunications on tasks.

• Communication: Team merging caused a noticeable decrease in communication.

• Team Boundaries: Felt like he took overstepped too much into Batch Team, would take a step back and rely more on chain of command with Batch Team Sub-team Lead.

• Team Structure: Laying out groups differently. There was a bit too much overlap for the initial four sub-teams.

• Research: Dedicate to research lightning components.

• Communication: Talk more with the team and spread work across sprints evenly

• Strengths/Weaknesses: Finding out where people’s strengths were.

• Effective Use of Git: Approach Git differently. Learn more about gitignore.
• Code Review: Look at old code in more detail before getting into coding requirements.

• Less focus on Version Control/Using Deployment Tools: Prioritize on the requirements instead of vscode and github.
• Goal Oriented Focus: When the trainer and batch team merged, a lot of the original progress and goals the batch team had been focusing on, were forgotten about when the teams merged.
• Equal Distribution of Work: Some team members overtook the work, planning, and logic of some requirements and delegation was not given to other members causing an unequal distribution of work. There were enough people to implement new requirements, however the distribution of workload remained with a few members while other members did not get delegated new requirements.
• Communication: Lack of communication among members after the merge. This caused less productivity on implementation of requirements and some requirements to go unfinished.
• More focus on requirements: Requirements like calling from the database once and having the target capacity filtering were unfinished. Less focus should have been placed on performance, big-o-notation, and rewriting logic, and instead more focus should have been placed on fulfilling requirements.

• Communication: Communicate more with Team.
• Code Review: Learn the meaning of the existing code.

• Task Delegation/Collaboration: Split up the Tasks better and we could’ve collaborated sooner.

• Task Delegation: Spread out the work so it's not a lot on the leads.
• Learn proper git usage: Teach Git sooner.

• Team Structure Management: Should’ve sent over Testing Members sooner.

• Learn proper git usage: Set time aside to learn Git.
• Lean scratch orgs: Try to use Scratch Org instead of Playground.

• Outside requirements affecting productivity: Reschedule Panels/Interviews
• Team structure management: Less members in the Testing Team initially and then more members to be added after, rather than the other way around.

• Pre-planning: Plan out who needed to do what before merging teams

• Learn proper git usage: Learn more about git before trying to use it

• Pre-planning: Plan tasks for people to do after merging teams

• Learn proper git usage: Figure out git before trying to handle projects