SitGuide Analysis Paralysis
The short duration of w3Develops Cohorts requires that teams strike a delicate balance between performing quality work, learning new things, and completing the project. This is made even more import by the fact that team members typically have responsibilities outside of their Cohort project such as family obligations, jobs, and school which can create more stress. The objective of the Cohort is to learn and not increase stress.
The first step to take in preventing any form of "analysis paralysis" is to determine the team's learning expectations and availability. It is critical to make sure that everyone is realistic in their level of commitment and availability. Working less than what you have committed to is disrespectful to your teammates and can hinder the team's progress and morale. As a rule-of-thumb (ROT) team members can typically devote 4-10 hours a week towards the project depending on individual situations.
The second step is to evaluate everyone's current technical abilities and determine at least one primary technical learning goal for each teammate. Pick something that is 25% outside of the team's comfort zone / skillset. Any further and you will likely be overwhelmed, while any less and you are limiting your rate of learning.
It's always a good idea to ensure that at least one team member is familiar, even at a cursory level, with each component of the technical stack you've chosen for your project. Cohorts go by faster than you think and you need to focus on learning through building rather than getting caught in research rabbit-holes.
What follows are various situations that can impair your teams ability to complete their project, which in turn can also increase stress on the team. As a PM it's your job to recognize the warning signs for each of this and to take the necessary steps to correct them or to mitigate their impact.
Some teams have a tendency to over commit to the amount of new technology they choose to include in their app. This includes frontend libraries and frameworks, CSS libraries, database management systems, object relational mappers, and a whole myriad of development and runtime technologies.
- Danger: Technologies in the project stack which no one on the team has any experience using.
- Warning: User story uncompleted for more than 1 sprint
- Danger: User story uncompleted for more than 2 sprints
- There is an adage stating "You can't manage what you don't measure". Defining the technology baseline for your team will help you to recognize with the teams capabilities are being strained.
- Ensure that at least one member of the team is acquainted with each component of the stack and than individual team members don't exceed their capability (the 25% rule) to absorb new technology
- Measuring the rate of story completion for each sprint and projecting the impact on project completion.
- Tracking user stories that are unresolved across multiple sprints. The root cause of team members who are unable to complete their stories across more than two sprints could be, but isn't limited to, too much new technology.
- At some point you may need to step in and request in more strenuous terms that more "tried and true" technologies be used. It should be stressed to the team that the stories that include new technologies may always be re-attempted once the app is working and as time permits.
- Reach out to other W3Developers in Discord when you need help.
One of the great traits of w3Develops teams is they are driven to stretching their capabilities to learn new technologies and to deliver quality applications. These are admirable attributes, but it's important that teams not sacrifice completing a project at the expense of striving for perfection.
- Warning: User story uncompleted for more than 1 sprint
- Danger: User story uncompleted for more than 2 sprints
- Make sure that user stories are granular and are achievable within 1-to-2 sprints. The majority of your stories should be able to be completed in a single sprint with only a minority that span sprints. Remember that stories build on one another across sprints. Features don't have to be perfect in one sprint.
- Measuring the rate of story completion for each sprint and projecting the impact of delays on project completion.
- Tracking user stories that are unresolved across multiple sprints and reviewing progress with the team in your Standup Meetings. Team members with over due tasks should volunteer to discuss their status and if they need help. If they don't it's your responsibility as the PM to bring this up and to ask others on the team to help resolve the blocking issue.
This case is similar to "Too Much New" except it describes the situation where a teams progress is held back due to switching technologies in the application stack. Essentially chasing new technologies at the expense of getting anything done. Although there may be good reasons for a mid-stream change to the application stack, given the short duration of w3Develops Cohorts changing components should be seriously questioned once development is underway.
- Warning: Team members unable to agree on which components will make up the apps technical stack.
- Warning: No clear agreement or decision on the technical stack
- Danger: Composition of the technical stack not 100% defined in Sprint 2.
- Danger: Changes proposed to one or more parts of the technical stack after Sprint 3.
- As part of both Sprints 1 & 2 educate your team on the importance of defining how the team will operate during the Cohort and the implications of changing parts of the stack after development begins.
- If a change to the stack is proposed after Sprint 2 - Design work with the team to ensure that there is sufficient justification for the change and the impact it has on completing the project on time is fully understood.
- Changes proposed after Sprint 5 should be challenged since this is the midway point in the Cohorts development cycle.
