This week I got to have someone from another team who has been taking part in our “retrospective facilitators” group facilitate my team’s retrospective. He had started out using the framework from the Agile Retrospectives book and with a little help from me, but this week I got to see how he had evolved the format in a way I didn’t expect.

What he had done was apply a theme to the activities that made them fun and coherent. He used a news paper/reporting theme with the following structure:

• Set Up: Paint the Iteration
• Gather Data: Iteration Headlines
• Generate Insight: Investigative Reporting
• Decide What To Do: Read All About It
• Wrap Up: Plus / Delta

I was throughly impressed… the format was fun and enjoyable yet still tied back in a kind of abstract way to the activities outlined in the Agile Retrospective book. One of his teammates also told me about one retrospective where he used a CSI theme… hehehe. I must say… it’s always a great feeling when you teach someone something, then later they teach you.

So today I tried something along similar lines… using a car theme. The iteration started with asking participants what kind of car they would use to describe the iteration. Then, transparently moving into the gather data phase, ask them why they chose that car. From here, we did the Learning Matrix, but with a twist… rather than Things to Keep, Things to Change, Ideas, and Praise, we used Showroom, Junkyard, Research and Development, and Car and Driver Awards.

From these two retrospectives I’ve found that applying a theme seems to open up participation more… people chuckle a bit and seem to be more relaxed. Best of all, it’s fun dreaming up new themes and keeps people throughly entertained… and it’s hard to get bored with the activities because they’re always approached differently, giving them a fresh feel.

Just a reminder… it seems to be best to send out a small agenda of the activities before hand so people have time to think about something to describe the iteration with. I tried a Pirate theme on Talk Like a Pirate Day without some advance notice and everyone was a bit confused on how exactly a pirate would describe the iteration. Unfortunately no one stated that they “Plunder’d dem storahs” that iteration.

No tags

Recently I’ve completed an ideas swimming in my head for awhile now… using ruby within the java world. And it couldn’t be easier thanks to Struts 2, Spring, and JRuby.

All you need is to use Spring’s Scripted Beans, define an interface for your action so it translates well to java, and just reference the bean id in your struts 2 configuration.

That’s it… from the jsp point of view you just ignore the implementation and use methods exposed via the interface. in the code behind the scenes you don’t even know you’re using java… since everything maps back to the action and the action is written in ruby, all of your application code is written in ruby.

I’ll follow up with more on this soon… I must say it’s slightly exciting to open a *.rb file in my project’s WEB-INF directory, modify it, refresh my web page and see my changes instantly versus a long drawn out recompile/redeploy.

No tags

Tonight I have more stories and thoughts to share from the trenches of facilitating Agile Retrospectives. As we’ve continued a few more iterations of participating in better organized retrospectives, I’ve noticed that there are a few interesting patterns that have emerged that a lot of retrospectives seem to follow. I’ll kind of avoid the Wrap Up phase for these, as the Wrap Up phase tends to focus more on how to improve the retrospective or ideas for the next retrospective.

The “What Happened?” Retrospective

This is a retrospective where we come into it asking “What happened? What was interesting this iteration?” This type of iteration usually begins with a setup activity of weather report or one word to describe the iteration, where participants will either state their feelings of the iteration with one word or a weather report like “Sunny” or “Slightly Stormy”. Lots of positive feedback identifies more of a “Great Iteration” which I’ll cover later, or an iteration with some issues that arose.

We usually Gather Data in this kind of retrospective with either an Iteration Timeline to identify events where time mattered or use Mad, Sad, Glad to help us identify significant events that made us mad, sad, or glad. The latter activity works well… we break up into small groups or pairs for a time boxed period of time to identify events both as a team and as individuals.

Once we post all our sticky notes or (my personal favorite) color coded sticky index cards on the board, we gather around and work together to identify Patterns and Shifts to see what events are related, what events caused other events, and briefly discuss our feelings and thoughts on these issues. For example, one iteration we had a lot of cards under Sad and Mad that were related to a failing in communication… we discussed what happened, and why. We got to see viewpoints from other perspectives regarding it.

From there we participate in a Circle of Questions activity, where we all sit in a circle and, one at a time, ask the person to our left a question regarding something that was posted, as well as ask what they think we could do to improve. After a few rounds of the circle we usually come to a goal of sorts.. something we can help plan for the next iteration to improve. Building off the communication example, this can come about by identifying four important keys to communication that make it meaningful… something we can use a radar to track daily or at the beginning of the next retrospective. When we have a goal that could be accomplished in the next iteration through tasks, we do a Retrospective Planning Game, where we come up with tasks to do towards completing a goal, size them, and prioritize them as if it was an iteration planning game. Throughout the iteration we can pick these tasks up and work on them as time allows, schedule them into the iteration, or just pick them up if they relate to a story.

This is a converse of another type of retrospective, where the iteration went well.

The “Awesome Iteration” Retrospective

This is a retrospective where, when participants are asked to describe the iteration in one word, you end up seeing things like:

• Awesome
• On Schedule
• Exciting
• Fast
• Productive

Since the iteration went great, why not build off of the “why” it went so well? So we follow with the activity Locate Strengths. This has followed a bit of a pattern we’ve done before… we break into small groups or pairs and jot down as many strengths that we think contributed to a good iteration, maybe even including a bit of praise here and there.

We then get back together and write on a whiteboard what strengths we identified, with a brief discussion of each, maybe even including an example or two from the iteration. For example, someone might point out collaboration or communication and explain how they were confused about a story, contacted their customer, and then worked with the customer to identify domain logic that was a key to successfully completing the story quickly. Lots of praise usually happens here for jobs well done.

Now that we’ve located strengths and agree that these are very important key ingredients for a great iteration, we want to improve so we can continue to have great iterations. We then Vote With Dots giving each person a number of votes to vote on what strengths they think are the most important, and then narrow them down to either two or one to take and try to improve upon.

I’ve found any Decide What To Do activity works here… the key is to build off previous experience or knowledge to help the team reinforce that strength.

The “How Did We Do?” Retrospective

This type of retrospective follows a retrospective where goals were set forth… we set a goal, and now we want to know how we did achieving that goal. I’ve found that a great gather data activity for this can be the Radar activity… basically you define four key concepts of that goal and have each team member vote from 1 to 10 on each concept… using the average to generate a radar graph of where the team is at on that goal, perhaps revisiting in successive iterations to see if the radar expanded (identifying improvement) or shrunk (identifying decline).

An interesting variation here is to maybe come up with averages for both developers and customers… although you must use great care not to pit the two against each other, it helps see how both groups perceive progress on that goal. A Radar helps visualize this rift in perception and aids in discussion on the difference of opinion.

This is followed in the generate insights phase with an activity that helps explain the data on the radar. Five Whys might help… so does Short Subjects and Force Field Analysis. The idea is to identify what aided in moving towards or accomplishing the goal, as well as what hindered progress towards it.

Sometimes deciding what to do feels awkward here… if the team accomplished or even exceeded the goal, what is there left to do? Any Decide What To Do activity works well here though, either something specific to help us reach the goal if we haven’t, and if we have, something to help us improve or maintain it.

Keeping Track

The hard part is keeping track of what came out of these retrospectives… sometimes as developers we hate documentation! However, we need something to help us keep track of what has happened, perhaps to use in future retrospectives. Take pictures of any graphs, charts, or time lines so that you can look back on them. Try to keep a notebook or a wiki that summarizes the retrospective. Especially when we use the team radar, we need data we can look back on from previous retrospectives to put things into perspective.

Anyway, hope this post has been helpful for those of you out there working on facilitating your own retrospectives, and I’d love to hear of any experiences or interesting patterns you might have noticed as well… and if you have any advice, I’d like to hear it too!

No tags

Recently I’ve gotten back into PHP development with some personal projects and I came to a realization… php is not as bad as people consistently make it out to be.

Whenever I mention php with other developers, the responses are mixed but fall regularly along the following lines:

“I hate PHP… it’s awful!!!”

“PHP Sucks.”

“PHP is so difficult to work with, and there’s no concept of object orientation.”

“PHP is okay for small apps, but no one would seriously consider it for a large enterprise application”

Granted, there’s a lot I don’t like about php. I hate the fact that extensions are mostly implemented as functions in the global namespace. Functional programming is neigh impossible almost (and lets face it…. eval and create_function are kinda nasty). The OO cababilities do feel like much synthetic sugar.

But, despite it’s shortcomings, php is dead simple… I feel like even ruby has a bit more of a learning curve than php has… php is something anyone and their non-programmer cousin can pick up. And for those of us who are serious developers, there are plenty of good MVC and ORM frameworks out there to choose from. And despite the myths, it is pretty solid (although I’ve had to utilize caching systems in the past).

Maybe this is why a plenty of popular sites (Flickr, facebook, etc) use php rather than java or ruby on rails. I even noticed today that cnn.com uses wordpress (which is the blogging software I use) for it’s blogs.

I guess my general statement is, I’m tired of people hating so much on php. Sure, it’s easy to write spaghetti code with it, but the same is true with other languages (I have a 500 line jsp full of java code in CVS history at work to prove it), it’s just php probably gets more exposure due to wide use. Don’t hate it until you try it…. in all honesty, give me a choice between developing a site with PHP or Rubyit’d be a tough choice that would boil down to using PHP since the client probably already has it installed or has in house developers with PHP experience. Ruby on Rails is no magic bullet you know (flame on).

No tags