|Some developers look for an optimized solution at the start rather than actually starting to write the code.
||The top priority is to make the software work (per the acceptance criteria) by the end of the Scrum cycle.
If a team member has completed his/her user story task, then the next priority is to complete the remaining user stories. Help the team if they are lagging behind.
Optimization-related tasks can be reported or worked on (if all the user stories are completed based on the acceptance criteria).
|There is nothing wrong with this approach, but Scrum emphasizes timeboxing (all the tasks should be done within the stipulated time; they cannot be worked on indefinitely).
Complete the software first, present it to the product owner, and then discuss any points thereafter.
|Some developers do not ask questions or ask for help if they are stuck. They spend considerable time on a problem, then raise the flag.
||The onus of completing the user story/task is on the team.
Team members should first try their level best, and if they hit the wall, they should instantly communicate this to the person who can help them out.
Open communication is most important. Be transparent in answering the following questions so that the team member has the necessary information, and you can help accordingly:
- How much time was spent on this problem?
- What are the possible concerns?
- What approach was tried and why?
- What worked?
- What did not work?
The focus is to develop a self- managing team eventually (i.e., working closely and self-organizing) by building team harmony and improving team spirit. Open communication is the most essential step toward this.
So the mantra is: Do not be reluctant to ask for help from any team member. Be transparent by answering questions in case of noncompletion of tasks.
Moreover, if any team member is not cooperating or sharing information, report it to the team lead, ScrumMaster, or both, with priority. Be confident enough to speak up about the true situations that are affecting project goals.
|Sometimes developers say:
"My code is 90 percent done."
"It is almost done; I'm just doing some final touches."
"It is just about to complete."
"It is almost done and will be completed by today/ tomorrow/ evening."
|Beware of the 90-90 rule:
"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time."
-- Tom Cargill, Bell Labs
|Remember: A user story or task is not complete unless it satisfies the acceptance criteria and the product owner gives the go-ahead.
|Sometimes the developer says:
"The particular technology or product is new, so let me take some time, and then I will start working or implementing."
|The developer need not be an expert. Scrum focuses on learning while doing. So be open, adaptable, and quick to learn new things.
Learn the things that are relevant to the task or user story. Do not try to spend too much time on learning things that are irrelevant to the task or user story.
At the same time, do your best to understand the task or user story. Later you can and should try to explore, when the product context becomes clearer.
The focus should be on execution.
|Remember: The team is always there to help, and this is what Scrum focuses on.
Don't worry about what you don't know; team members will regularly provide the necessary training and knowledge transfer. That is what team spirit is all about.
|Some developers say:
"Scrum does not focus on documentation, so why should we do documentation at all?"
|Follow a simple rule for documentation:
Perform documentation when and where it helps to improve team performance or when lack of documentation becomes a bottleneck or hindrance to team performance.
|Scrum does not focus on exhaustive documentation, and it does not recommend that developers leave all their work and start documenting. However, it does recommend developing continuous documentation in small areas, whenever it's required to help the team.
Generally, use the "topic-based authoring" approach for technical documentation.
The request for documentation may be in the form of a product or technical knowledge document, code flow, code comments, the setup of the development environment document, etc.
|Team members sometimes might feel bad or offended under the following situations:
Other situations or conditions might exist that could make some team members uncomfortable.
- When asked to give their status in daily stand-ups
- When asked to delay a certain task
- When questioned in retrospectives about the failure of a sprint's goals
|Ensure that no one ever says anything to make a team member feel bad or to blame him or her intentionally.
The focus should be on communicating within the team to motivate each other, find what the mistakes are (as a team), how you can help each other, correct each other, and more. All this in order to accomplish the goals as set by the product owner.
Open communication is good. Show respect for each other.
Advice: To create a more self-organized team, take small steps toward improvement rather than a big-bang approach. The latter will backfire.
A 2 percent improvement by each member on a team of five brings an overall improvement of 10 percent.
So the mantra is: Take small steps to make the team self-organized, but at the same time be goal oriented.
|Quality is QA's responsibility.
||The onus of quality lies with both the Scrum team (developers and QA) and the product owner.
QA should not lag behind developers in terms of knowledge or understanding of the user story or task. In fact, they should be at par or be ahead of them in terms of understanding what is expected user behavior.
At the same time, the product owner should be very clear about the user story.
Remember, a team the size of n has n brains. In fact, it can be demanding for the product owner if he or she is not clear on the requirements.
|Quality consists of the following:
To ensure quality, everybody is involved from the beginning.
- Built-in quality: Generally, quality should be upheld by all developers, product owner, and QA.
- Quality includes code review, test-driven development, clear and common understanding of acceptance criteria, unit testing, minimum code coverage before bringing the product to the QA team, CI, focus on test case automation, etc.
- Detection of defects: Generally done by QA (by exploratory testing or running a test suite).
- Fixing of defects: Generally done by developers.
|It's not necessary to send the ScrumMaster all technical emails (especially if the ScrumMaster is nontechnical), because this role has nothing to do with the technical issues.
||Although sending emails is an important way of communicating, we recommend that you include the ScrumMaster as the recipient, whether he or she is technical or nontechnical.
| The ScrumMaster looks for all forms of issues (impediments) arising due to ineffective communication, such as lack of understanding by developers, QA, or product owner, any delay in communication, lack of sharing knowledge, difference between written commitments and delivery, etc.
Therefore, if the team keeps the ScrumMaster out of the loop and any problems arise, the effects, such as product delivery or team morale, are certainly not desirable.