Any of you who grew up in the Eighties or who enjoy pop culture references from that era will remember Marty McFly. A slightly dorky teenager who is friends with a zany scientist named Doc, Marty gets sent back to 1955 in a DeLorean time machine where he interacts with his future parents. The trilogy of movies shows the potentially funny and frightening consequences of messing with time, as Marty and Doc travel back and forth across the decades meeting or avoiding their past and future selves (this link will take you to the original trailer if you’re interested: http://www.youtube.com/watch?v=yosuvf7Unmg ; otherwise just listen to old Huey Lewis and the News albums since they practically did the soundtrack for the movies).

Well in my current firm we’ve found a way to travel through time and communicate with our past and future selves through Agile. The method is easy to use and extremely helpful. It doesn’t involve a flux capacitor – just some well-maintained user stories. [For more of my thoughts on stories, check out this earlier blog posting: https://intruthitsnotthatsimple.wordpress.com/2012/12/%5D

This particular adventure began last week as the product manager on my team was preparing to present some functionality to a prospect. As he re-familiarized himself with the way this risk management feature works, he could not tie back to some of the numbers coming out of our system. And he began to suspect that maybe this functionality – which we built months ago but still have very few users adopting – might have been developed incorrectly. His specific question was, ‘what were we thinking when we designed it like this?’

And that’s where the time machine comes in. What we needed was a way to go back in time and talk to our past selves about why we had used the specific formulas we did when building out this code. Then we had to get back to the future so we could either change our calculation methodology or explain to ourselves (and the new prospect) why we had made those decisions in the past. Fortunately that time machine doesn’t require stolen plutonium or 1.21 gigawatts of electricity (http://bit.ly/89DYp); instead we have it in our Agile swim lanes and story clusters.

When we first set out to develop this feature, we started with a simple user story: A risk manager needs to measure and mitigate her financial risk on a regular basis. Next, we needed an approach to solving this identified market need; our consulting team works closely with hundreds of clients dealing with these risks and so we asked for their help in creating the correct formulas for assessing them. Then we took this information and entered it on our Agile board – a piece of freeware we use to track our sprint-by-sprint progress as well as our product backlogs. When we were ready to develop on this user story, we created a swim lane for it (used to track all of the associated tasks required to complete a given story or story cluster). This provided the basic structure for our documentation – really just a set of tickets assigned to specific sprints and outlining the functions to be built.

Attached to one of these tickets was a spreadsheet worked on by our consulting team that specified the correct calculations to use for measuring and managing the risk type in question. A simple search through this swim lane and its resolved issues took two minutes and turned up this spreadsheet when we needed it. We had successfully traveled back in time and could talk to our past selves about why we designed things the way we did. Once we found our past reasoning, the logic behind our decisions became clear and we could return to the present confident that our past selves had built this feature correctly.

As I try to write about some big picture thoughts I have on the Agile Manifesto, I keep encountering the fact that these important values are more than just abstract ideas; they inform the daily decisions we make as we develop software. I wrote about this last time when I talked about how we value individuals and interactions over other kinds of decision making tools. Here it comes up as I write about how we value working software over comprehensive documentation (point two on this basic statement: http://agilemanifesto.org/).

As the Agile Manifesto and many Agile practitioners affirm, Agile is not opposed to documentation. Writing some things down in ways that can be referred back to later can be very helpful; that was certainly our experience last week when we used our simple documentation to travel back in time and talk with our former selves. Instead the Agile approach (at least as far as I understand it in my admittedly limited way) decries extensive documentation for its own sake. I’ve worked in waterfall environments that demand business requirements documents, functional specification documents, technical specification documents, user acceptance testing documents, and change management procedure documents – all before any code is written.

Instead Agile strives for incremental advances of working software developed with coders, testers, and product owners working closely together based on market-vetted user stories and high fidelity prototypes. Good code can contain meaningful explanations within its own structure, allowing minimal but not nonexistent documentation to provide the added support needed to explain development choices. Further supported by sprint plans, sprint retrospectives, and well-maintained user stories, such a simplified structure provides all the information needed to allow the same kind of time travel that my team embarked on this past week. We enjoyed our trip to the past, and we noted our findings so that our future selves can benefit further from what we learned. I’d love to tell you that where we’re going, we won’t need roads, but in truth it’s not that simple.