In my current firm we’ve been working with Agile for over six years.  Our process has evolved as has our understanding of Agile methodologies.  We started with six-week sprints, shortened them to two weeks, and are now talking about a move first to one-week sprints and then perhaps to continuous deployment (not to be confused with continuous integration which is already part of our practice – more on these ideas can be found here if you’re interested: http://en.wikipedia.org/wiki/Continuous_delivery).  There’s a lot we’ve tried and a lot we’ve learned throughout this process, and in this set of posts I hope to share some of that.

One of the key questions I am trying to answer in this set of posts on Agility is this: what does Agile look like in practice? Over the next set of postings I will provide one answer to that question by sharing ‘a sprint in the life’ of one of the projects I work on.  Our company uses two-week sprints for our software development process and so over the next two weeks I will share both some of the details about decisions we are making as well as some big picture thoughts on why we approach things the way we do.  My hope is that this will paint a good picture of the specific ways in which we are applying Agile – knowing that each company using this approach and even each individual project within the company might employ Agile techniques differently.

If you’ve been reading my blog from the beginning, you know I’m a big fan of Stephen Covey’s book 7 Habits of Highly Successful People (you can check out a posting back from July 2013 in the archives of my blog if you missed this).  His second habit urges people to ‘begin with the end in mind’ – that is, to know your goals and your vision before you simply start working hard at something.  It is very hard to know if you are making good progress if you haven’t defined where you want to end up.  This is a habit we apply as part of every sprint with a combined meeting looking both backward and forward.  In this meeting – on the last day of a two-week sprint – we do both a retrospective on the sprint just ending and a planning session for the sprint about to begin.

The retrospective focuses on three questions: What went well in the past sprint?  What did not go well? What can we improve for next sprint?  The answers to these questions touch on our communication across the team, the efficiency of our process, and the progress or impediments we faced during the preceding two weeks.  Each person on the development team for the project answers each of these questions, and sometimes someone raises an issue that other people want to share their own perspectives on.  I have been working with a fairly consistent team on one project for nearly two years and this regular retrospective has had significant impacts on how well we work together.  I have learned a lot as a product owner about the best ways for me to construct user stories, the most effective ways to work with our testing team, and the least appreciated way to communicate feedback about problems.

Coming out of the retrospective, we move into planning for the next sprint.  This usually involves some quick reflection on our overall product roadmap to set the context for the specific tasks that will occupy the team for the next two weeks.  We talk about anything that needs to get wrapped up from the sprint just ended, who would work best on which pieces of functionality, and what if any help we are going to need from people not on our team.  One project I work on assigns estimated times to each task and then allocates a specific number of tasks to the sprint based on the number of ‘person days’ we have, while another team focuses more on the user stories we want to accomplish and breaks these down into small enough units so that we are comfortable tacking them in a single sprint.  In both cases the entire team plans together – since Agile teams are self-organizing and group planning tends to enhance group motivation – and agrees that the stated goals ought to be achievable in the sprint.

Combining our sprint retrospective with our sprint planning has been a very helpful approach for the project teams that I work with.  It allows us to actively learn from our experiences and to make sure that we keep the end in mind as we begin each new sprint.  We aren’t perfect yet; many of the same themes about communication and task estimation continue to recur in our retrospectives.  We also don’t always deliver on all of the plans we make – sometimes through unforeseen events impacting our progress and sometimes through mistakes we make along the way.  Bringing together a backward and a forward view at the start and end of each sprint makes a lot of things easier, but of course in truth it’s not that simple.