 |
| Henny Youngman can teach us scrum. |
The most fundamental activity in agile is inspection and adaptation to changing circumstances. A retrospective is a principal tool used by the agile team to respond to change. Over time, a team can get stale in using the revelations of the retrospective to improve. As I continue to talk about agile basics, I want to highlight an essential part of agile retrospectives; action items.
Legendary borsht belt comedian Henny Youngman would tell a joke about a man who goes to the doctor and tells them it hurts when they bend their arm a particular way. The doctor always replied, “Stop doing that.” Behind the simplicity of this joke is a bit of wisdom. We are often hurting ourselves. Many of the things breaking the team often originate from the individual members of the group. Patrick Lencioni called many of these injuries the five dysfunctions of a team: inattention to results, avoidance of accountability, lack of commitment, fear of conflict, and absence of trust. Many of the issues which come up during a retrospective have their origins in these dysfunctions.
Recognizing a problem is only half the battle. Improvement happens when recognition combines with sincere effort to fix the problem. A scrum master then steps in, holding the team and its members accountable for making the change.
The following is an example of a dialog between team members. The team is struggling with quality and defects rollover from sprint to sprint. The retrospective points out this problem, and the group agrees to get better at quality assurance. Someone points out a spelling error in form validation, and it lingers two hours.
Scrum Master: “Did anyone fix that spelling mistake? It is defect-123.”
Developer #1: “What spelling mistake?”
Scrum Master: (checking the Kanban board) “The one we found two hours ago. Who worked on that page?”
Developer #2: “I did last week.”
Scrum Master: “Cool, do me a favor and write a unit test and fix the spelling mistake.”
Developer #2: “Developer #1 has the branch checked out.”
Scrum Master: “Ok, Developer #1 gets to write the test and fix the code and do the commit.” (points to Developer #2). “You can pair with them until it is done and meets the standard of care.”
Developer #1: “Ok, give me about thirty minutes.”
Scrum Master: “Thanks, and let me know when you merge the code.”
When fixing a spelling mistake on a web page, whether JavaScript or text, should not take a developer much time. It will take longer to write a unit test and have someone review the changes. It is up to the team members to point out these quick fixes and hold each other accountable. On a more mature team, developer #1 and developer #2 would have taken care of the defect when first spotted. The difference between the two scenarios is a significant improvement in code quality and fewer defects rolling over from sprint to sprint.
Only through constant attention and friendly reminders to the team will they internalize the lessons from the retrospective. It is up to the scrum master to be that force of change. Action items are nothing more than commitments the team makes to change for the better. Instead of reducing bugs, the team should strive for better quality, eventually leading to fewer bugs. Unit tests will not reduce the number of defects in a system, but they will reduce and spot future flaws before they become embarrassing.
Henny Youngman was right. If the team thinks it is doing something wrong, stop doing it. Taking action on an item from the retrospective will improve the team and save time and energy.
Until next time.
No comments:
Post a Comment