Sprint2_TeamLead_2 - revaturelabs/assignforce-force GitHub Wiki

The purpose of this Wiki page is to help any future team leads in learning from any mistakes made by past Team Leads and from the past successes that they encountered.

AssignForce Iteration 2
Successes

• We chose to divvy up teams based on preference and chose team leads based on the top 5 voted for overall Team Lead. This worked out fairly well for us in having strong leaders with team members who backed them.

• We performed daily stand-up everyday and held one another accountable for what they had accomplished.

• We had set high goals for our test coverage to bring all tests above 75% code coverage as opposed to 75% overall. This worked out in us being able to test all of the best practices related to testing.

• We reallocated resources as we saw fit. When teams started to run out of requirements part way through the project, we shuffled them around in being able to reduce our backlog quicker.

• I had performed daily stand-ups with our trainer. This helped us with being able to clarify questions we had as well as getting some advice on how to tackle some of the problems we had come across.

Failures

• We had spent a ton of time on SFDX during the first week of the project. We were the first team to use SFDX as a batch for the project and had not had that much experience with it up to that point. This hiccup started to really cut into our time and made it so we had to rush to get the project done.

• We had ran into an issue of time management among some team members on certain teams that had to sorted early on. Some of our batch mates weren’t being mindful of how little time you actually have in getting the project done.

• We had completely rearranged the teams due to a bottleneck that we had faced half through the project. The problem being, we had some batch members that were lost or sometimes not having things to do while others were steady working.

Lessons Learned

• Spend time hitting SFDX hard the first day to ensure everyone’s connected to scratch org’s, afterward have those connected getting into the code and get the others up to speed.

• Make sure that the sub team leads, as well as yourself are staying on top of the other team members in ensuring that they are working diligently throughout the project. Don’t necessarily babysit them unless it’s the only way to ensure that they are working.

• Have a solid plan for those you’re gonna have moved around if/ or when a bottleneck happens so others don’t get lost by the wayside. One thing they can do while you finalize a plan for them is to work on documentation or code review with whoever might be developing certain aspects of the project.