Communication

This page shows all challenges and their respective Best Practices related to communication, either between team members or stakeholders

Index Challenge Best Practice
(12) Poor knowledge management (e.g. leads to a lack of comprehension of the project or distractions) [15, p. 61, 19, p. 517, 4, p. 86, 20, p. 64, 21, p. 4] Establish knowledge transfer meetings [15, p. 61]
Create timeboxes within the week to share knowledge [15, p. 61]
Enhance already set goals with further details on knowledge transfer [22, p. 49]
(13) No or not enough transparent communication [12] Foster transparent communication though the creation of a “free-to-fail” atmosphere [12]
(14) Customers are not being involved enough [19, p. 517] Let stakeholders take part in some Scrum meetings [9, 10]
(15) Too much or partially unnecessary communication between team members [15, p. 11 | 54-55, 23, p. 97, 24, p. 313] Scrum Masters must moderate meetings [15, p. 11]
Scrum Masters should hold a pre Sprint Planning meeting with Product Owners [15, p. 55]
Do not sacrifice too many resources to the daily Scrum meeting [24, p. 313]
(16) A team member slowly withdraws him-/herself from the others and is difficult to reach [25, 22:33, 15, p. 59, 26, p. 195] Dismiss the team member as he/she is not a team player and the attitude is unlikely to be changeable [15, p. 60]
(17) The Scrum team's surrounding company needs to know an estimate of how much the product will cost in advance [6, p. 200] Use Planning Poker to estimate the requested figures together with the team [6, p. 200, 14, 9]
(18) Interruptions caused by stakeholders [6, p. 201, 15, p. 67, 16, p. 163 | 168, 2, pp. 2-3] Create a timebox for asking questions, ranging from a fixed hour per day to a few hours per week [6, p. 201]
Scrum Masters should prohibit interruptions to the team [6, p. 201, 7]
Flesh out a behavioural plan on how to react to interruptions by the interrupter [15, p. 68]
Reach out to other stakeholders [15, p. 68]
Confront the interrupting party [15, p. 68]
(19) Inadequate progress communication [6, p. 201] Use Information Radiators [6, p. 201]
Install a Burn-Down-Chart [14, 10] (e.g. on the wall) [16, p. 201]
Try to integrate progress visualisation into a project management tool the team uses [6, p. 201, 9]
Visualise the team's velocity [10]
(20) The customer does not provide enough feedback on intermediate results and solely shows interest for the finished product [6, p. 200, 27] Slowly familiarise the customer with Scrum. The customer will normally appreciate the incremental nature of Scrum [6, p. 200]
Implement a customer feedback loop of high frequency [14] especially at the beginning of a project [54, p. 84]
Get the customers’ feedback on your deliverables past every Sprint [14]
(21) Justified dissatisfaction on the customers side during review [15, p. 70] Embrace given feedback and utilise it to improve the next Sprint [15, p. 71]
Create action items from given feedback to use in the next Sprint [15, p. 71]
The Scrum Master may relay given feedback to the team in their next internal meeting [15, p. 71]
Implement a customer feedback loop of high frequency [14], especially at the beginning of a project [54, p. 84]
Get the customers’ feedback on your deliverables past every Sprint [14]
Work on the Product Backlog and product vision together with stakeholders in a special meeting [9, 10]
(22) Unjustified dissatisfaction on the customers side during review [15, p. 71] Accept given feedback and inform responsible employees to cope with the issue before the next review [15, p. 72]
If the issue comes up several times again, the Scrum Master and Product Owner may confront all stakeholders about the situation and its conceivable influences on the project [15, p. 72]
(23) The team has little knowledge as to what the product should look like [9] Work on the Product Backlog and product vision together with stakeholders in a special meeting [9]