Tuesday, November 20, 2012

Translating an Epic

What do the story of Gilgamesh, the Iliad, and the Mahābhārata have in common with your project document?  They are epics that have been translated through multiple ‘languages’ and been touched by many hands during translation.  I point out these similarities because we have found the metaphor of translation of historical epics useful in describing the various stages that our own project epics undergo as they are translated.  

Your next project document is no different.

In scrum-speak user stories are the single sentence descriptions product owners (POs) use to describe their needs.  Since we refer to these descriptions as stories it is natural that we call large collections of these stories epics.  POs write the epics and pass them to the dev team in some fashion, the message changing, and changing hands multiple times.  Multiple teams.  Multiple people.  Multiple translations.  

I say ‘translations’ because intentions are easily miscommunicated and when combined with the differences in how biz and dev describe the world it can often feel like we’re speaking completely different languages.  In considering how to manage these translations we explored a number of metaphors.  It needed to convey the importance of the POs original request while providing enough layers of translation to contain all the times the message would change hands.  After considering and discarding several we settled on the Biblical.  I present this to you in the hope that it or some variation may be as useful to you as it has been for us.  

As you read this keep in mind that we use one-week sprints and the Atlassian On-Demand tools.


The raw original epic from the PO.  It has no estimates. It could very possibly make no sense.  But it does convey intent and intends to paint a picture of how users will interact with new/updated features.

  • Written by the PO.
  • Can be delivered through any channel (word doc, wiki, etc), but must be committed to the wiki in it's own epic page before the Greek translation can begin.
  • May include prototypes or flowcharts that live elsewhere, including the backs of napkins.


The first translation digestible by developers translated by developers from the original Hebrew.  It is much more coherent and sprint friendly than the Hebrew.

  • Written by a developer.
  • Is probably in the proper story format, but...
  • Stories may not be small enough to fit in a sprint.
  • Lives in the wiki.
  • Is written after the Hebrew on the same wiki page.


An in-place translation of the Greek which is sufficiently granular and organized to determine the delivery date for the epic

  • Written collaboratively by the developers.
  • Is written over the Greek in the same wiki page.
  • Contains only stories that are small enough to fit in a sprint.
  • Lives in the wiki.
  • Finalizing the Latin involves a dev team round table.  Prior to this round table, each member separately writes estimates for each story in the Greek, if necessary breaking stories down into 3-day or smaller stories in the process.  At the round table, the different breakdowns and time estimates are reconciled.  In general the longest estimate wins.
  • Estimate totals are used to determine a delivery date based on 4 development days (32 development hours) per developer per 5-day work week.
  • The final result of this effort is to be confirmed by the PO as still representative of the original intent.


The first official translation that ends up in Jira.  It's in the proper format. It's actionable.  It includes test criteria. It has been approved by the PO.

  • Written by a developer.
  • Is written/created in JIRA.
  • Each story from the Latin is a story type ticket in JIRA.
  • Tickets are labeled with a version number or name of the epic.
  • No ticket may have an estimate longer than 3 days (given one week sprints).
  • If a ticket/story estimate ends up longer than 3 days the story must be broken down into two or more stories.
  • Tickets are grouped by upcoming sprints to uncover any problems with the deadline determined by the Latin translation.
  • Story acceptance criteria are not required until the Sprint Commit meeting and should be written by the team during the Sprint Prep meetings.

This works well for us. YMMV.  This is intended to spark discussion.  I’m interested to see what the rest of you out there are doing and how this maps to what you already have in place. Hit me up and let me know.

Tuesday, August 21, 2012

How fast can you run?

I've been doing the agile thing for ages.  My first real programming gig was for a guy who had a background in manufacturing so we were doing Kanban and Kaizen before people were lumping it all under the single banner of Agile.  I've worked with no fixed cadence and I've worked with two and four week sprints.  I've never worked a single week sprint.  Until now.  I'll never go back.

Everywhere I've worked before, whether I was managing the team or otherwise, the team as a whole would collectively decide on the most comfortable cadence and go with that.  Most of the literature I've read seems to think this is a good idea.  If not a good idea, at least not a patently bad idea.  But consider this.  If I were to fill a room with random people and took their vitals, how much of their body mass would be fat?  A fair amount I'd wager.  Then ask them to start running together everyday.  What pace would they choose at first? Slow.  Pin whatever number you want to that word but the reality would be a pace not much quicker than a fast walk.

Now what if those people ran together five days a week for a year? 5 years? 10? They would be lean.  They would be running and often sprinting.  The problem with software processes is that slow sprint cadences get institutionalized and rarely once a pace is chosen does the team try to go faster.  Oh sure.  Occasionally there will be an urgent problem or feature that the team will have to push through quickly  but overall they'll be moving fairly slowly through a process bloated with overhead they don't know is unnecessary because they aren't moving fast enough to feel how much it hurts to carry the extra weight.

I speak from experience.  I recently joined a start-up where I get to help drive decisions like this.  As an experiment I asked the team to try running one week sprints to see what happened.  I asked them to hang with it for two months to see if we could make it work.  The first month was painful. We made mistakes.  We broke sprints.  But what we found was as we challenged our assumptions about how the dev process should work an interesting thing happened.  Rather than defending how much time we thought we needed to test a build for a sprint we found ourselves pushing more and more of our testing into continuous integration tests.  Rather than insisting we needed longer meetings to spin up or close out a sprint we found ourselves cutting out conversations which didn't get us deliverable demonstrable value.

I know what you're thinking. "By having twice as many sprints aren't we doubling our overhead?" Well, you can go that route, but then you're missing the whole point.  Yes. You'll be having more meetings, but it will be about half as many stories.  You'll be twice as focused because you'll have half the distractions.  The tendency to slack at the beginning and cram at the end will vanish.  It's easier to focus in meetings that are half as long. You'll spread out your test time more evenly rather than jamming it in at the end because you'll have to and your quality will improve. Suddenly CI becomes a necessity and CD becomes a possibility.  What I'm trying to say here is the effect of doubling your sprints is equivalent to cutting your diet in half and seeing your effective caloric intake drop to a third.  And that's one way that the fitness metaphor breaks down.  In life when we want to cut out a lot of fat it takes determination but it also takes A LOT OF TIME.  With your development process, as long as the whole team is on board it takes determination, but tremendous positive effects can be felt as quickly as two or three single week sprints. You get back more than you cut out because all the focus and efficiency that creates work TOGETHER.  Want specifics?  You can find more here and here.  But don't stop there.  Hit the Google.

One more thing worth pointing out is that when I say work faster I'm not talking about working 16 hour days 7 days a week.  I'm talking about increasing sprint cadence and efficiency.  If you've been in this dev game for decades we see few reasons why you'd have an excuse for going slower than two weeks. Sure if you need to transition from four to two before you can switch from two to one we'll cut you some slack, but you can do it.  And you should.

It's been three months.  We couldn't be happier.  Before this experiment I would have considered a one week sprint a pipe dream.  Having gotten our team to run smoothly on one week sprints, having cut out so much overhead, it makes you want to achieve even more.  We feel like a room full of former fatties on the fitness infomercials. Running a marathon is easy. For us, Continuous Delivery is no longer an impossible goal.  Like I've read with other teams that have gotten down to one week you wish you could shrink the cycle down to a day.  The urge is strong.  You want to go farther, faster, now.

So for those of you out there considering your options in terms of sprint size, or contemplating smaller sprints, there is no time like the present.  Stick with it.  It will be hard at first.  Push through the pain.  You'll be glad you did.  There is no reason not to go faster and you'll be much healthier for it.

Monday, June 25, 2012

Cruise control can kill you

Twenty years ago I could have died.  I had driven to Lollapalooza in Memphis Tennessee, seven hours away in expectation of having an amazing time.  An amazing time was had.  I caroused with friends.  I heard great music.  And then it was time to head home.  I got on the interstate, set the car to cruise control, and five hours in I fell asleep.

A year ago I feel asleep at work.  I stopped being passionate about my job.  I gradually stopped exercising as well.  I was in a funk.  I gained twenty pounds.  At the time I wasn't aware of the change but in retrospect I can see the trigger clearly.  I was bored.  But it hadn't started out that way.  When we started that company I was on fire, completely and fully engaged.  Everyday was an adventure.  From building the team to developing new technology, to working toward aggressive but achievable goals.  Everything I did was exciting.  Fast forward five years.  We had gone through two purchases and arguably the second, while strategically exciting, created tactical issues that seemed small at first.  Because our team was awesome I assumed these issues would be addressed.  I said my part and waited.  And waited.  And then fell asleep. 

If you've ever fallen asleep at the wheel, waking up is a terrifying experience.  You're disoriented.  You don't know how you got there.  You don't know how long it's been since you fell asleep.  When I was driving back from Memphis that wake up call came when I nudged into the wheel of a semi-trailer in the lane next to me.  The banshee howling of metal-on-metal jolted me awake.  I could have died.  I could have killed someone.  Instead I pulled the car over, got out, shook the weariness off, and drove home ashamed I'd waited so long to take a break... to make a change.

Going into cruise control with your career won't get you killed but it can kill your career.  At the very least it can kill your interest in your job, and the interest those around you have in theirs as well.  I could have been doing more at work to make a change.  I should have been doing something.  Doing anything.  Doing nothing I was guaranteed to fall asleep.  As it was, after some soul searching, I realized what I needed to do was change jobs entirely before I started poisoning the attitudes of those I worked with.

I'm not sure how your brain is wired but for me I'm either driving 90 miles an hour, hyper engaged, or I'm asleep at the wheel, dreaming about what else I could be doing.  People die that way and in a way apathy is a kind of death.  Don't let it kill your job or your love of work.  If what you're doing isn't working, make a change.  If you have to, pull off to the side, or change roads.  

So this week marks an important milestone.  I've started a new job, and a new fitness regimen.  I had become sedentary and both are an effort to cut out the apathy.  I'm on an exciting new road and I couldn't me more awake.