In my post summarizing some of my thoughts from the latest Philly ALT.NET meeting on Planned Agility I alluded to the fact that the retrospective is a key component within our agile process.  Since it sounds like we have a slightly different flavor of retrospective then some others I thought I'd put together a post detailing how we run our retrospectives.

A couple times over the last few years our team had the pleasure of working with Jim Shore, author of a great agile book entitled The Art of Agile Development.  Jim introduced us to the style of retrospective that we're using "today".  While we've strayed away from the format I'm about to outlay a couple times, we've found that it provides us with a good foundation within which we can get to the root of the things that we want our retrospectives to uncover.

We typically start our retrospectives off by reminding people of the Prime Directive (should we?).  Once that bit of housekeeping is out of the way we try to get everyone involved by going around to everyone that is participating in the retrospective and have them answer a question.  The primary purpose is to get people engaged, and speaking as early as possible.  The moderator chooses the question, and a "fan favorite" seems to be "What do you hope to get out of this retrospective".

Next, we review our team objectives.  As I'll get to in a bit, we try and end each retrospective with a team objective.  By starting off each retrospective with a review of our objectives we ensure that we maintain focused on the objectives that we've defined.  During this time we evaluate how we're doing with each objective, whether or not they need to be altered, dropped, or given a kick start.  

After reviewing our objectives, we go into an information gathering session.  The purpose of this phase is to gather information from everyone in the team, and hopefully identify an item, or set of items that should be further addressed.  We use index cards for everything under the sun so it shouldn't be surprising that we use them for this process as well.  The way this stage works is that everyone on the team is given a handful of index cards and a pencil.  Each person reflects upon the last iteration (or whatever period of time it's been since our last retrospective), and identifies things that fit into one of the following topics:

• More
• Same
• Less
• Enjoyable
• Frustrating
• Puzzling

We usually take 5-10 minutes to allow everyone to write whatever pops into their head on their index cards at this point.  When I'm leading the retrospective I often encourage people to prepare ahead of time for this phase.  Once everyone has had enough time to write their cards, we go around and everyone reads the topic that their card goes within, and then gives a short overview of what is on their card.  Once everyone has had a chance to go we allow people to put up cards that they've thought of as everyone else was going around.  Once everyone is satisfied that they've gotten their major items identified on the board we begin the next phase.

Once all the data is collected on the board, we have everyone organize the cards into categories.  The categories are pretty loose and can be whatever anyone sees as fitting.  There is usually some debate at this stage as people discuss whether or not things really belong in category X instead of category Y.  Once this stage is complete, we review the categories that have been identified.  Often there is some slight re-organization at this point.  Once everyone is happy with our categorizations we do a quick vote to see what category people feel is the most important.  We then tally the votes and identify the item that is going to be the focal point for our next phase.

With our primary category (or sometimes item) in hand, we begin the discussion portion of our retrospective.  This can take the form of a fishbowl, roundtable discussion, or 5 why's.  The goal at this stage is to drill down into something within our team, process, work habits, communication, or whatever else that needs particular attention.  As part of this discussion a theme usually starts to emerge.  Once it does we identify it, and bring it to everyone's attention.  The primary theme typically turns into a new team objective.

As we go through our retrospectives we try to stay focused on things that we can do to help improve our team, and/or our software.  Since the human side of software is the most important and most problematic, you won't be surprised to hear that our objective usually has something to do with improving the dynamic between some members of our team.  We write our objectives on a wall in the development area for all to see with the idea being that if it's in everyone's face all the time we'll be more likely to meet our objectives.

I breezed through a lot of the details of our retrospectives above in order to get a reasonable summary up and out into the wild.  If you have questions about anything mentioned above or would like me to further expand upon anything mentioned drop me a comment.  If you haven't had a retrospective in a while, now is a great time to schedule one! :)

One of the best things about working in a software shop that has embraced the principles and practices of agile software development is the continued focus on what's really important.  Every week, our product manager and our business analysts are forced to think about what the most important piece of functionality is that can be added to our software.  I'm sure it's frustrating for them to have to, week after week, put things that seem relatively important on the back burner for those things that are most important. 

Focusing on the most important things can be frustrating, and it can lead to business trying to slip "easy" things into iterations whenever possible.  I believe this is a symptom of having to make so many concessions each and every week.  Since they never get everything they want, it's the "easy" things that are the most tempting to add.  However, I'm of the belief that "easy" is never good.  Doing something because it's easy, is doing something wrong.

It's no secret that a lot of software that is developed today is total crap.  It's loaded with feature upon feature.  It's hard to use, and doesn't do anything that helps the user kick ass.  Anybody can do "easy"....you don't want to be just anybody do you?

Most of the stories I hear about using an agile/iterative development "methodology" are from those in the consulting world.  It's nice to hear about people in product organizations, such as Adobe, using agile/iterative development successfully.  I've heard a number of people say it isn't possible due to the nature of product organizations, it sounds like the Photoshop development team might disagree.  They switched to a more agile approach and cut their bug count by approximately 1/3, ended up with a higher quality product with plenty of features, and ended up working fewer nights and weekends.

I'm always amazed by the editable grid.  Everyone wants it, everyone loves it, why wouldn't they....it's just like Excel!  I don't know why, but I always have and always will hate the editable grid.  Grid's are good at displaying information, not editing.  Checkout Chris Stevenson post, "The Editable Grid Antipattern" for reasons why you should always ask 5 why's when someone asks for an editable grid.  Here's to hoping I never see another one in the UI designs for the apps I work on! :)

In addition to being reminded that readability is more important than "clean well factored code" in unit tests, I've also recently been reminded how wonderful small, focused classes can be.  As designs evolve, classes tend to grow.  If you don't keep a close eye, they can grow out of control and take on way too many responsibilities.  As classes grow, they become harder and harder to manage.  All the sudden, it becomes harder to find things, and harder to figure out what the code is intended to accomplish.  By breaking classes apart into small, focused classes it's much easier to understand the things that each class is responsible for.  Rather than taking on a handful of different responsibilities, your classes should have a single responsibility. This will help keep them focused on doing one thing, and doing it well. 

We've had several internal discussions about how we should allow our customers to extend and customize their data.  We considered a lot of different options and thought about a lot of the tradeoffs that need to be made for each approach.  It's because of this that I'm very interested in people's opinions, and as such would like to direct you to Jeremy Miller's "How do you extend and customize a database" post.  Please go and drop him a comment describing what approach has worked best for you so that we can all learn from your experiences! :)

One of the things that draws me to Ruby on Rails is the passion that I see from those who use it day in and day out.  Ryan McMinn from Unspace, falls squarely in the passionate for Rails camp. He recently gave a short talk about the approach that Unspace uses to build software.  They don't do specs, they don't do contracts, and they don't "conform".

With all the talk of being Agile, one has to wonder if anyone cares about shipping.  We focus a lot on the methodologies and practices that go into creating software, but we don't talk all that much about shipping.  Software doesn't exist until it's shipped.  No money is made from a great piece of software that isn't available.  No money is made from having a really kick ass Agile process if you don't ship.  It's not all about money, but without money we don't get to "play another game of pinball".  As Sam reminded me today, it's all about getting that next game.  It's all about shipping.

Those of us living in the world of software need to remember why we're in this business.  It's not about process, it's not about methodology, it's not about how Agile you are. It's about creating kick ass software that users love.  Users can't fall in love with something that isn't shipped.