Action items make the retrospective real.

The most fundamental activities in agile are inspection and adaptation to changing circumstances.  A retrospective is a principal tool the agile team uses 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 usually 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 during a retrospective have their origins in these dysfunctions.  

Recognizing a problem is only half the battle. Improvement happens when recognition is combined with a sincere effort to fix it. 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 defect rollover from sprint to sprint. The retrospective points out this problem, and the group agrees to improve quality assurance. Someone points out a spelling error in form validation, which lingers for 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.” 

Fixing a spelling mistake on a web page, whether JavaScript or text, should not take a developer much time.  Writing a unit test and having someone review the changes will take longer.  It is up to the team members to point out these quick fixes and hold each other accountable.  On a more mature team, developers #1 and #2 would have taken care of the defect when first spotted.  The difference between the two scenarios is significantly improved 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 the team's commitments 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.