Symptom: The same improvements keep appearing from retrospective to retrospective with no visible sign of progress and the are team losing interest.
Probable Cause: No closure of improvements identified in retrospectives.
Suggested Resolution: Try to derive an action plan and follow up on improvements. It sounds simple, but you really need to go that extra mile to close the improvements and achieve some real progress for the team so that they do not reappear at the next retro.
Also try to toggle between a generic retro looking at general improvements and specific retros looking at specific areas for improvements that you can resolve before the next retrospective.
In addition, try to also do a retrospective on the retrospective at the end to determine if your current retrospective format could also be improved.
The retrospectives are a real learning forum for the team to take stock of what they are doing and how they are doing it. But progress needs to be made for the team to feel that there is real value in these.
For more agile coaching options, check out agile coaching
Saturday, October 31, 2009
Friday, October 30, 2009
#7 Daily Standups Taking Too Long
Symptom: Daily standups are consistently taking longer than 15 minutes with lots of discussion and some team members feeling that their time is being wasted.
Probable Cause: One cause can be the team are not aware of the aim of the meeting or the time taken, and look to resolve problems in the standup rather than just provide an update of their progress and raise awareness of impediments.
Suggested Resolution: To remind everyone of the time available for the standup, try putting a kitchen timer or something similar in plain view so that everyone can see it. The team should be able to make a decision on the use of the 15 minute limit once they can see the timer ticking down.
In addition, it may be good to remind everyone that they should only be talking about their progress in the last 24, what they are doing in the next 24 and what impediments they have during the standup. However, also give people the option to have a resolution discussion after the standup if needed. This clear distinction between a standup and a resolution discussion will signal to other team members who do not need to attend the resolution discussions, that it is ok for them to leave and so use everyone's time appropriately.
What you are looking for here is a short snappy daily standup that is of high value to everyone with the option for some team members to stay on and discuss issues or resolutions etc. after the standup.
For more agile coaching options, check out agile coaching
Probable Cause: One cause can be the team are not aware of the aim of the meeting or the time taken, and look to resolve problems in the standup rather than just provide an update of their progress and raise awareness of impediments.
Suggested Resolution: To remind everyone of the time available for the standup, try putting a kitchen timer or something similar in plain view so that everyone can see it. The team should be able to make a decision on the use of the 15 minute limit once they can see the timer ticking down.
In addition, it may be good to remind everyone that they should only be talking about their progress in the last 24, what they are doing in the next 24 and what impediments they have during the standup. However, also give people the option to have a resolution discussion after the standup if needed. This clear distinction between a standup and a resolution discussion will signal to other team members who do not need to attend the resolution discussions, that it is ok for them to leave and so use everyone's time appropriately.
What you are looking for here is a short snappy daily standup that is of high value to everyone with the option for some team members to stay on and discuss issues or resolutions etc. after the standup.
For more agile coaching options, check out agile coaching
Thursday, October 29, 2009
#6 Stories Not Being Completed Within A Sprint
Symptom: Some stories on the sprint backlog take a long time and do not get completed within a sprint.
Probable Cause: The granularity of a story or the detail level of the objective to be achieved could be too high.
Suggested Resolution: It takes a while for many teams to really tune in to what is the right level of granularity for a story and discover how to break stories into smaller ones. Try to set yourself a story point limit for a sprint, i.e. if a story is estimated at 13 story points for example and 8 story points is your limit, then look to break it down into smaller minimum marketable features or deliverables.
Sometimes for new areas of little knowledge it is a good idea to break a story into an investigation story to get more information, which will help with estimating, and an implementation story to do the work. Both of which may not necessarily be in the same sprint.
What you are really looking for is a story that can be achieved within the sprint, and it is good practice to keep this in mind when estimating stories and looking for when to break them down.
For more agile coaching options, check out agile coaching
Probable Cause: The granularity of a story or the detail level of the objective to be achieved could be too high.
Suggested Resolution: It takes a while for many teams to really tune in to what is the right level of granularity for a story and discover how to break stories into smaller ones. Try to set yourself a story point limit for a sprint, i.e. if a story is estimated at 13 story points for example and 8 story points is your limit, then look to break it down into smaller minimum marketable features or deliverables.
Sometimes for new areas of little knowledge it is a good idea to break a story into an investigation story to get more information, which will help with estimating, and an implementation story to do the work. Both of which may not necessarily be in the same sprint.
What you are really looking for is a story that can be achieved within the sprint, and it is good practice to keep this in mind when estimating stories and looking for when to break them down.
For more agile coaching options, check out agile coaching
Wednesday, October 28, 2009
#5 Yoyo Velocity
Symptom: Experiencing a yoyo velocity where on one sprint the team are achieving a high velocity followed by sprint with low velocity followed by a high velocity sprint etc. etc.
Probable Cause: One root cause can be not resizing stories that are part done from a previous sprint and carrying on with the story in the following sprint.
Suggested Resolution: Try to re-estimate the story size of part done stories according to how much effort is required to complete them during the planning for the next sprint. This will reflect the true velocity of the team during a sprint, rather than earning some additional story points from the previous sprint and throwing out the velocity measure.
Ideally you should be getting to a good granular level of user story that can be completed in a sprint and avoid this scenario all together, but that is another post ;o)
For more agile coaching options, check out agile coaching
Probable Cause: One root cause can be not resizing stories that are part done from a previous sprint and carrying on with the story in the following sprint.
Suggested Resolution: Try to re-estimate the story size of part done stories according to how much effort is required to complete them during the planning for the next sprint. This will reflect the true velocity of the team during a sprint, rather than earning some additional story points from the previous sprint and throwing out the velocity measure.
Ideally you should be getting to a good granular level of user story that can be completed in a sprint and avoid this scenario all together, but that is another post ;o)
For more agile coaching options, check out agile coaching
Tuesday, October 27, 2009
#4 Team Not Sticking To The Plan
Symptom: The team are doing other things rather than what was agreed at the start of the iteration or sprint
Probable Cause: One root cause for this can be not referencing the iteration plan or scrum backlog during the daily standups, which can impact a team's ability to stay on track and keep to the team commitment for the iteration.
Suggested Resolution: Try to make the iteration or sprint backlog present when doing daily standups. This improved visibility can be a reference point for the team and provides a context when they are talking about what they have done, what they are doing next and what impediments they are experiencing.
If you use a notice board or white board to hold the iteration or sprint backlog, try to have the daily standups around the board and then it can be updated as people are providing their updates.
When using an electronic board such as a spreadsheet or a web application for example, it can be very easy to close it down after an update, which means that any visibility is lost. Try to find a way to keep the visibility either by printing it out after every daily standup or keeping a dedicated pc with a large screen just to display the iteration or sprint backlog on a permanent basis.
The key point here is improving the visibility of how you are tracking against what you said you were going to do at the start of the iteration.
For more agile coaching options, check out agile coaching
Probable Cause: One root cause for this can be not referencing the iteration plan or scrum backlog during the daily standups, which can impact a team's ability to stay on track and keep to the team commitment for the iteration.
Suggested Resolution: Try to make the iteration or sprint backlog present when doing daily standups. This improved visibility can be a reference point for the team and provides a context when they are talking about what they have done, what they are doing next and what impediments they are experiencing.
If you use a notice board or white board to hold the iteration or sprint backlog, try to have the daily standups around the board and then it can be updated as people are providing their updates.
When using an electronic board such as a spreadsheet or a web application for example, it can be very easy to close it down after an update, which means that any visibility is lost. Try to find a way to keep the visibility either by printing it out after every daily standup or keeping a dedicated pc with a large screen just to display the iteration or sprint backlog on a permanent basis.
The key point here is improving the visibility of how you are tracking against what you said you were going to do at the start of the iteration.
For more agile coaching options, check out agile coaching
Monday, October 26, 2009
#3 Working Hard But Not Finishing Within The Iteration
Symptom: Everyone on the team is working hard but at the end of iteration there are only a few stories completed.
Probable Cause: The team may be splitting up the work according to their respective skill set and working on their own personal backlogs of stories rather than as a team on single user stories.
Suggested Resolution: Try to work as a cross functional team on the highest priority stories and do what needs to be done to complete them. This may mean that a team member may have to do work outside of their primary skill set, but as an agile team member, their prime objective should be to complete stories rather than starting other user stories. Working as a group this way to tackle the top stories can reduce the tension of working on something new when compared to working on your own, and also helps to build the team social bonds.
For more agile coaching options, check out agile coaching
Probable Cause: The team may be splitting up the work according to their respective skill set and working on their own personal backlogs of stories rather than as a team on single user stories.
Suggested Resolution: Try to work as a cross functional team on the highest priority stories and do what needs to be done to complete them. This may mean that a team member may have to do work outside of their primary skill set, but as an agile team member, their prime objective should be to complete stories rather than starting other user stories. Working as a group this way to tackle the top stories can reduce the tension of working on something new when compared to working on your own, and also helps to build the team social bonds.
For more agile coaching options, check out agile coaching
Sunday, October 25, 2009
#2 Running Out Of Time For Testing In An Iteration
Symptom: Testing is the last thing in an iteration which usually results in running out of time to perform adequate testing.
Probable Cause: The team is still in a silo approach, where all dev is done at the sprint and then left up to testing at the end of the sprint. Can also be attributable to coarse grained user stories that require a lot of dev work followed by a lot of test work to complete them resulting in a rush at the end of the sprint.
Suggested Resolution: Try to derive finer grained user stories or finer grained tasks that require less dev and less test effort that can be done rapidly. A little work and often will help to provide everyone in the team with something to do rather than some team members waiting on others to finish their piece, as with large work packages. If everyone in the team is fully utilized during the iteration, then there should be a constant stream of completed items and the "test rush" at the end of the sprint is distributed throughout the sprint.
For more agile coaching options, check out agile coaching
Probable Cause: The team is still in a silo approach, where all dev is done at the sprint and then left up to testing at the end of the sprint. Can also be attributable to coarse grained user stories that require a lot of dev work followed by a lot of test work to complete them resulting in a rush at the end of the sprint.
Suggested Resolution: Try to derive finer grained user stories or finer grained tasks that require less dev and less test effort that can be done rapidly. A little work and often will help to provide everyone in the team with something to do rather than some team members waiting on others to finish their piece, as with large work packages. If everyone in the team is fully utilized during the iteration, then there should be a constant stream of completed items and the "test rush" at the end of the sprint is distributed throughout the sprint.
For more agile coaching options, check out agile coaching
Saturday, October 24, 2009
#1 Testing User Stories Appearing on the Backlog
Symptom: Testing user stories appearing on the backlog with a number of bug fix tasks attached.
Probable Cause: Amassing technical debt due to not sticking to the "done criteria" of user stories and not completing all testing for each story within the iteration.
Suggested Resolution: Try to get all of the testing done for each user story before classifying the user story as being done. Paying off the technical debt in smaller increments in this way and improving the discipline to stick to the done criteria will help to reduce the impact of technical debt.
For more agile coaching options, check out agile coaching
Probable Cause: Amassing technical debt due to not sticking to the "done criteria" of user stories and not completing all testing for each story within the iteration.
Suggested Resolution: Try to get all of the testing done for each user story before classifying the user story as being done. Paying off the technical debt in smaller increments in this way and improving the discipline to stick to the done criteria will help to reduce the impact of technical debt.
For more agile coaching options, check out agile coaching
Subscribe to:
Posts (Atom)
