Like many agile shops, here at Carbon Five we use Pivotal Tracker to manage our stories. Stories are estimated and prioritized within typical “Current”, “Backlog”, and “Icebox” queues. Stories can be labelled to give them context, and one label I have seen applied to stories has gotten me thinking Greek.
This label is a word that I would argue simply does not exist within the context of any Agile project. In fact, I would like to ban this word from my vocabulary, and most definitely from my backlog. This word is “blocked”.
Currently, it is applied to stories that have been investigated by a developer (guilty as charged) only to find out that for some reason they cannot get started working on it. Sometimes, design is needed. Other times, a decision needs to be made by another individual. Research has to be done. Emails need to be sent. Phone calls need to be made.
So you label it “blocked” and save the story, then move on to another. The next day someone else is surfing the backlog and sees that label “blocked”, so they skip it and pick up the next one. After all, that story is blocked, right?
So our story cries a little and walks away muttering “nobody loves me”. It’s a really sad story. (Don’t you just feel bad?)
Blockers in Real Life
I’m starting to notice that in my own life, I mentally “block” things that need to be done. Like the sad story in the backlog, these tasks become stale and eventually die due to inaction. Here is a personal example (don’t judge me!):
I needed to do my taxes for 2008 (it’s 2011 now…) but I started a business in 2007 on a whim. I forgot to file my sales taxes for that business (because I didn’t make any sales). In order to file my personal taxes I needed to first file my sales taxes. To file my sales taxes I needed some paperwork that I either didn’t have or had lost at some point. To get that paperwork, I needed my employer identification number. I had no clue what that was.
self.projects("taxes").status = :blocked
Just like that. The concept of “blocked” became an excuse for inaction. For the last few years I felt a vague sense of urgency to get my taxes done, but I was “blocked” on something I didn’t know how to do. Until this year (when I got some very wordy letters from the IRS), at which point I started asking “Why?”.
Getting to the Greek
A long time ago there were some smart people that wore togas. They usually had gray hair and beards. Oh, and sandals. One of these guys asked “Why” a lot. A history professor, I am not.
Wikipedia tells me that “Socrates generally applied his method of examination to concepts that seem to lack any concrete definition”. He uses a technique known as “Elenchus”, which is loosely defined as “argument of disproof or refutation; cross-examining, testing, scrutiny esp. for purposes of refutation”. Keep that word “testing” in mind, I’ll come back to that later.
Perfect! This “blocked” concept surely seems to lack any concrete definition. It’s vague and ethereal at best. So how do we get started?
Form a Thesis, Start asking Questions
I am going to walk you through a little exercise that relates to my story. First, you need to define your thesis. Then, start asking questions in an attempt to refute or disprove that thesis. Here we go…
- Socrates: What is your thesis?
Me: I can not file my taxes for 2008
- Socrates: Why?
Me: Because I didn’t file my sales taxes for my business
- Socrates: Why?
Me: Because I didn’t have my employee identification number
- Socrates: Can you obtain this “employee identification number”?
Me: Um… I guess
- Socrates: How?
Me: Uh… maybe by calling the IRS…
- Socrates: And if that does not work?
Me: Hmm…. (thinking) I could ask a tax professional…
- Socrates: Your thesis is false, so the negation is true. You CAN file your taxes for 2008.
Now my project is no longer “blocked”. By forcing myself to form a thesis and then using Elenchus as a technique to cross examine and scrutinize it, I find out what my next steps are.
Agile enthusiasts may see some similarities here to test driven development. What we are essentially doing is “testing” our conclusion which leads us to the next actionable step (find out my EIN). By using a little bit of logic and further questioning, we can figure out how to accomplish this (call the IRS or a tax professional).
Applying Elenchus to Agile Projects
After seeing how this narrative method has helped me to unblock projects in real life, I decided to take a whack at a workflow for stories in Pivotal that have been “blocked”. Here’s what I’ve come up with:
Visit Blocked Stories During Standups
Our daily standup meetings involve visiting our stories in the “Current” queue and getting a status from developers and the like. I would suggest that all stories in the backlog or icebox that are “blocked” be discussed during daily standups and resolved immediately.
Scrutinize Until Actionable
To resolve a blocked story, apply the same narrative I described in my Taxes example until the next steps become clear. Once a decision on action has been reached, add a detailed description of what is needed to the story’s comments.
Now that we know what the next step is, figure out who can take action and make them the owner of the story. If it is someone outside of the team, or not in Pivotal, that person may be a project manager or team leader. Do not continue until somebody is accountable.
Now that someone has ownership of this story, it can be unblocked. There are details for what action is necessary, and accountability for those actions being completed, so start taking action. If you need to send an email, send the email. Phone call? Pick up the phone, and get it done.
Repeat Until Complete
Repeat this cycle until a developer owns the story and has all the prerequisites necessary to complete the feature. Hooray!
The Edge Case
Sometimes stories are blocked on other stories. This may be because functionality for one story needs to be implemented before another story can be started. In this case, I would suggest the following workflow:
- Change the label to “dependent_upon_XXXXXX”
(where “XXXXXX” is the blocking story id)
- Add a task or comment to the blocking story “Blocking story #XXXXXX”
(where “XXXXXX” is the blocked story id)
- If that story is already started…
Assign ownership of this story to the owner of story in flight
- If that story has not been started…
Developers should assign themselves to blocked stories once they start
- When the story has been completed…
Developer should remove the dependent_upon_XXXXXX label from other stories and release ownership
Practices in Pivotal
One habit to get into when using this method is to maintain your “My Work” queue in Pivotal tracker. By following the workflow I have described, your personal queue should now show you any stories that are dependent upon yours and give you a broader view of the impact of your work.
Whether it be taxes or the next big Rails site you’re working on, I believe you can add traction, focus, and agility to your projects by forming the habit of questioning everything until actionable. I don’t consider myself terribly well versed in the works of Plato or Socrates, so if I’m way off base please do let me know. Either way, I hope it helps you get things done.