Action Items Round Two

In my last post I discussed keeping your action items assignable and actionable. In the days since that post went out, I've seen a few more things to add to the subject of action items. We're agile, we're all about continuous improvement.

Action Items Are To Improve Team Workflow

Action items are things the team agrees to try in their next iteration to improve a process which is giving them trouble. In otherwords the team has identified a problem in how they're getting their work done and the action item they've decided on should help fix that problem. Some examples of action items I've seen on team boards in the past...

1. Add Work In Progress limits to our scrum board.
2. Make our Product Owner the single point of contact for our field engineers to limit the context switching of developers.
3. Add a large, red light outside our team area to let the rest of the office know that the team is in heads down "quiet time" and shan't be interrupted.
4. Try planning poker at our next planning meeting.

If the item would go straight to the value stream of your project, meaning it's something you are going to work on that will apply directly to your deliverable, then I usually don't classify it as an action item. Things that gostraight to your deliverable are typically specific features, setting up hardware, and technical spikes. (More on those in a sec.)

Not every retrospective will yield action items and that's OK. If you're doing short iterations and are humming right along, you may have a very short retrospective and be pretty happy with how everything went. There's nothing wrong with NOT having a problem on your team.

Technical Spikes

Spikes are meant to answer a question and should be time boxed. This stems from a couple things we as developers are very good at: Taking too long to come up with an answer and going off in the weeds, down a number of tangents and returning with what we think is the absolute perfect solution. Enter the technical spike. Limit our off in the weeds time, give us a definite end time, and force us to come up with A solution prior to coding it into the PERFECT solution.

Why don't I think spikes are action items? Because in the long run they should be answering a question about something that will likely go straight to the value stream of the project. Usually we're answering a question about some portion of code that's new to us, a framework we haven't used before, or something along those lines. These questions need to be answered for us to deliver our product, not necessarily to improve the team, its process and its flow. (Though not delivering our product will most decidedly have a negative impact on the team.)

An an example of what I mean, I have a spike assigned to me right now to look into a GUI testing framework for our project. This is clearly a question for us, and not something that I need to do to improve the next iteration and beyond. It's something that will provide direct value to our client.

So, let's say I finish my spike and settle on Selenium as our GUI testing framework of choice. After three or four iterations we see that our selenium tests are getting quite large and out of hand, at that point the team would probably identify an action item to clean those tests up. (And we would of course assign a steward to oversee that clean up.)

The Working Agreement

In my last post I got a very good comment from Fanlan:

At my company, we distinguish between tasks (Action items) and working agreements. "We will do a peer (code) review when we think we have finished a user story" is an example of a working agreement.

Many of the teams I've been on we haven't been too explicit with our working agreements, though I think that's a mistake on our part as I do like being more explicit about team workings. Leaving things open for interpretation rarely goes the way you wanted it interpreted, so I do like Fanlan's suggestion here.

In my example our team was going to try out code reviews and added them as an action item for the next iteration. In that context we don't know if code reviews will work for us or not, so we're going to run with incremental change and see how it goes. In another example we may want to add WIP limits to our team board, but after a couple of iterations they may not change our flow. If all goes well with our action items then I'd add the new practices explicitly to that working agreement for the team, but we should go through the "try before we buy" period before full adoption by the team.

Incremental change is a big deal in making your teams and your deliverables go better. Work at those retrospectives and their resulting action items, you'll see those improvements start to take hold.