Get certified - Transform your world of work today

Close

Scrum Team Traps

Situations to avoid in Scrum

27 July 2015

Amit Agarwal
Accretive Health Solutions


The Scrum cycle can be affected in many ways, as described in the following examples:
  • Software is complete, but it is not working per the acceptance criteria by the end of the Scrum cycle.
  • Software is not completed per the acceptance criteria by the end of the Scrum cycle; therefore, the user story is moved forward to the next iteration or sprint.
  • Last-minute, undue pressure is placed on team members to finish the stories, and sometimes QA members might be pressured by either time or the team to pass the user story.
  • Without really understanding the true scenario, the team lead or another developer wonders why a developer is taking a long time to complete a certain task.
  • Work-arounds in the code or bugs that were swept under the carpet can surface later.
Due to differences in expectations, team members accustomed to working under a traditional project management method fail to understand the true spirit of Agile and, as a result, fail to fulfill expectations. There can be quite a number of reasons behind the failures, however:
  • Individual team member styles and attitude
  • "Student syndrome," which leaves a lot of work until the last minute
  • Ineffective communication or a lack of communication
  • Lack of a common understanding among the team members
  • Emphasis on delivery over quality
  • Lack of learning new things
  • Separate sets of assumptions for each member of the team
These reasons are also known as traps. They are relevant to those who have worked in a traditional style of software development and might be accustomed to working in their preferred style or within their comfort zone. But as far as Scrum (or Agile) goes, they are traps, and if they go unnoticed or unresolved, they can affect the Scrum cycle, team morale and productivity, and product owner expectations.

Wherever the ScrumMaster observes these behavioral patterns within the team, he or she should coach the members appropriately.
 
Possible traps Recommended action Additional remarks
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:
  • 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
Other situations or conditions might exist that could make some team members uncomfortable.
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:
  • 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.
To ensure quality, everybody is involved from the beginning.
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.

The ScrumMaster can experience any of these scenarios. The best approach for tackling them is to coach the team.

Happy Scrum!
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3.8 (5 ratings)

Comments

Durgesh Kumar Mishra, CSP,CSM, 7/28/2015 6:14:05 AM
Nice one Amit !!

Keep it up. I loved the very last line of your article.

"Home » Community » Member Articles » 2015 » July » Scrum Team Traps
Scrum Team Traps
Situations to avoid in Scrum

27 July 2015


Amit Agarwal
Accretive Health Solutions



The Scrum cycle can be affected in many ways, as described in the following examples:
Software is complete, but it is not working per the acceptance criteria by the end of the Scrum cycle.
Software is not completed per the acceptance criteria by the end of the Scrum cycle; therefore, the user story is moved forward to the next iteration or sprint.
Last-minute, undue pressure is placed on team members to finish the stories, and sometimes QA members might be pressured by either time or the team to pass the user story.
Without really understanding the true scenario, the team lead or another developer wonders why a developer is taking a long time to complete a certain task.
Work-arounds in the code or bugs that were swept under the carpet can surface later.
Due to differences in expectations, team members accustomed to working under a traditional project management method fail to understand the true spirit of Agile and, as a result, fail to fulfill expectations. There can be quite a number of reasons behind the failures, however:
Individual team member styles and attitude
"Student syndrome," which leaves a lot of work until the last minute
Ineffective communication or a lack of communication
Lack of a common understanding among the team members
Emphasis on delivery over quality
Lack of learning new things
Separate sets of assumptions for each member of the team
These reasons are also known as traps. They are relevant to those who have worked in a traditional style of software development and might be accustomed to working in their preferred style or within their comfort zone. But as far as Scrum (or Agile) goes, they are traps, and if they go unnoticed or unresolved, they can affect the Scrum cycle, team morale and productivity, and product owner expectations.

Wherever the ScrumMaster observes these behavioral patterns within the team, he or she should coach the members appropriately.

Possible traps Recommended action Additional remarks
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:
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
Other situations or conditions might exist that could make some team members uncomfortable. 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:
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.
To ensure quality, everybody is involved from the beginning.
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.

"The ScrumMaster can experience any of these scenarios. The best approach for tackling them is to coach the team."
Ankur Nag, CSP,CSM, 7/29/2015 10:33:29 AM
Nice Article !! Scenarios and solutions are quite practical

The only things is we should avoid using the word "Developer" instead use Team.
Robert Day, CSM, 8/3/2015 8:28:07 AM
Depending on the client and application under development, documentation may be a requirement, possibly part of a legal compliance programme (especially for medical or similar applications). So if documentation is going to be required, it should be a part of the Sprint backlog and your team will have to include people who are skilled at creating and providing documentation.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe