Winging It

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.

Action Items: The Results of the Retrospective

One of the principles of agile is incremental change. Looking inward on what your team is doing that could be better is one way to get that incremental change, and team retrospectives are a great way to do that looking inward. If you're not familiar with team retrospectives, essentially they're a fairly informal gathering where teams bring up issues and kudos over recent work and decide on a few things that they want to improve. The things they decide to improve are usually called Action Items.

Having been on a few agile teams and taken place in many a retrospective there are a couple of things that come to mind in regards to action items.

Make Your Action Items Actionable

Ok, that sounds a little on the obvious side, and it can be. But it's a very real problem with many action items.

A team gathers and they find an issue with their code. For example our team is working on a large, old code base. There are many pieces of it that are just scary to change. So the team brings this up at the retrospective. Many people have issues on the board such as, "code is scary to change." Or something like "our code is difficult to work with." And since it's a dev team somebody has probably taken a little initiative and just put, "Code SUCKS!" up on the board. After some discussion the team has decided on an action item of: Improve the Code.

The whole team is there, managers, product owners, QA folks, everybody, and they settle on "Improve the Code" with some gusto. This is an item we KNOW we need to do and the whole team is behind it. If we're going to succeed, we need to IMPROVE THE CODE!

But our (somewhat) hypothetical team has missed the important part of this action item: HOW do we improve the code? Just saying "improve the code" is the dev team equivalent of saying, "Well, duh." We're always striving to improve the code, but what's that first step? Make sure your action items are indeed items and not overall team goals.

Drag the discussion a bit further. Start asking questions when you settle on a broad action item such as this. If you start digging, you'll arrive at that first step to your bigger goal. For example, our team notices that they have a small seam in their code where they could get their data layer wrapped in an adapter and add some more testability to both sides of that data layer. Now they have an actionable action item: Wrap Data Layer in an Adapter.

Make Your Action Items Assignable

The next retrospective comes around, and we working hard at getting actionable action items. After some discussion, we realize that we could use a quick code review before we move our features to "development complete." Performing a code review is pretty actionable, and everybody on the team can participate. Our team is happy with this action item and they decide to tackle it the next iteration. They've also decided to assign it to "Everybody."

So they just assigned it to nobody.

It's human nature, if everybody is assigned to a team task to complete of their own free will, nobody will take care of it. Code reviews will likely not happen, and we'll arrive at the next retrospective with everybody looking at each other thinking, "I thought somebody else would take the lead on that."

Even if your action item probably does need to be done by everybody on the team, as would be the case with our code review example here, assign it to one person to oversee that it actually happens in the iteration. Make that person a steward of the action item. This person likely needs to do nothing more than bring up at the first stand up to remember our code reviews, then later volunteer to do the first one and the ball will be rolling. Additionally, at the next retrospective the team has a person that is accountable to report back on the results of that action item from the previous iteration.

Retrospectives are great tools, possibly the greatest tool for incremental change. Keep an eye on those action items and keep them actionable and assignable.

pik, IronRuby, MRI, and a .Net Project

On a recent ASP.Net MVC project I was leveraging IronRuby and Cucumber to get some BDD specs in place to drive development. Though this post isn't about the benefits of BDD, it was very easy to get the specs worked out with my Product Owner, and the demos went really quickly. For the most part, I was using IronRuby to run functional tests at the controller level.

Then we decided to add on some GUI tests. With Ruby and Cucumber already in place, we decided to give watir a try. Except once we went on to using watir, IronRuby was no longer needed to test the website. We could instead use MRI 1.9.2 as our interpreter and get a little more speed out of our watir tests, and leverage the latest version Cucumber.

Since we're doing our development in Windows we don't have the luxury of RVM, but pik is a great solution to switching Ruby interpreters on Windows. During development, a few pik switch statements keeps all our cucumber tests in sync with either our IronRuby testing or our watir testing. However, if we wanted to run them all at once I had to write a little batch file to handle it. (I'm a dev, I'm lazy, I just want to type one line in the command prompt and have it all kick off...)

After knocking the rust off my batch file fu, here is the contents of that batch file...

@echo off
@call pik sw 100
@call rake
@call pik sw 192
@call rake watir

Here's what's happening in our little five line helper file. First line just doesn't echo your commands back out to the command prompt. After that we call pik sw 100, which is pik switch to IronRuby 1.0.0. Then our default rake task is called, which builds the project, runs the unit test suite (in nUnit in this case), then run the IronRuby cucumber tests. pik sw 192 is switching to Ruby 1.9.2, then calling rake watir just runs our watir tests against the already built website. Pretty straightforward.

Now that was only for our dev machines in order to do one line build test, test, test during development. Our CI server was much easier to configure.

We were using TeamCity as our CI environment when we added watir to the mix, but the batch file wasn't needed as TC allows for different build tasks to use rake and specify which interpreter to use. So it was as easy as add an IronRuby build task call the default rake task, then create another rake build task and call the watir task in the rake file. We have since switched from TeamCity to Jenkins, but the set up with a build task per interpreter is identical.

(Don't have pik installed and you're a Windows using, Ruby loving programmer? Ben Hall's post on getting pik installed and running is the best reference I've found.)

Upcoming Speaking Events

Trying to slow down the speaking and associated travel schedule this year, but not giving up on it entirely. So, here's what I've got coming around the corner...

Stir Trek

On May 6th, Stir Trek happens again. This has quickly grown into one of the region's more popular conferences, and it's only a one day thing. I'll be presenting "Executable Requirements: Testing in the Language of the Business" in the Testing Track there this year. There's something cool about seeing your slides on a movie screen. There's also something daunting about following Jim Weirich on the schedule...

Columbus Ruby Brigade

On May 16th I'll be presenting at the Columbus Ruby Brigade. It's not directly a Ruby topic, but the good folks at CRB have been kind enough to give me an hour to present "The What's, Why's, and How's of Kanban." So, it's not specifically for the Rubyists, but Kanban is good for everybody! If you're thinking, "Really? The Kanban talk AGAIN??" Yes, again, because I need the practice for...

Agile Dev Practices

June 9th I have the honor to be on stage at Agile Dev Practices West, again presenting "The What's, Why's, and How's of Kanban." Yes, more of Tim yammering on and on (and on and on) about Kanban and how it will cure all that ails you, but this time I get to do that yammering in Vegas! I am really looking forward to this conference and the crowd that will be different from the normal developer type crowd at most of the conferences I attend.

LSSC Video of My Kanban Experience Report

Back in April I was selected to give a Kanban experience report at Lean Software Systems Consortium in Atlanta, and as luck would have it InfoQ had set up a camera in the room I was presenting in. Yesterday, they posted it online:

http://www.infoq.com/presentations/Moving-to-Kanban

This was the first time I was recorded giving a presentation, so it's the first time I've seen myself give a presentation. And I must say, I am one of the presenters I've ever seen! OK, maybe not, but it wasn't as embarrassing to watch myself as I thought it would be. Seeing myself at least let me see some things I can improve on. (Dear Lord, Tim...STAND STILL for a second.)

And while I'm throwing some video out, Dave Giard recorded a video interview with me back at Codemash this past January. I finally got around to watching that one, too. For Dave's beer being off screen on one side and my bourbon off screen on the other side, it went pretty well.

Dave's Technology and Friends, Episode 71:

http://technologyandfriends.com/archive/2010/02/15/tf0071.aspx