Retrospective Principles

I’ve talked about the goals of a retrospective. Now I’d like to talk about four principles of effective retrospectives. I generally find that principles help me more to be effective while doing my work than do definitions. Principles help to connect the abstract to the actual practice.

One of the principles is that it’s important to understand the goals. If you don’t know where you’re going, any road will take you there. That road is, however, unlikely to be a retrospective. As a facilitator, I find the general goals helpful in planning a retrospective. I think that the specific goals are valuable to the participants, and generally discuss them as part of Setting the Stage at the beginning of the retrospective. As always, this is moderated by the understanding of the participants and the time available. Read More

Goals of a Retrospective

In my previous post, I talked about what a retrospective is not. Understandably, I got immediate questions about what a retrospective is. This post is a partial answer to that.

My current definition of a retrospective is “looking at the past to guide choices for the future.” That definition, however, is insufficient to offer guidance on making your retrospectives effective. It’s even insufficient to distinguish what I would call a retrospective to those who use the word for other similar or related activities. A retrospective is different from a “post-mortem,” a “lessons learned,” or many other forms of “process improvement,” but is often confused with these.

A retrospective should have a purpose. If it’s merely a formality, it’s unlikely to provide much benefit. Perform your retrospectives mindfully, thinking about your goals prior to the retrospective and choosing activities to meet those goals.

You may have many different specific goals for different retrospectives. Whatever the specific goals, the general goals of a good retrospective seem to fit three categories. Read More

The Wrong Impression about Retrospectives

People get the wrong impression about retrospectives. They read that it’s a meeting where you list what went well, what didn’t, and what you want to change. They describe it like this:

The Sprint Retrospective is an opportunity for team members to bring up anything about the Sprint they feel needs improvement.  For example, a team member might say he felt he had to complete work that should have been completed by another team member.  Or a team member might say she received emails constantly which prevented her from getting any work done….

Or like this:

The format is a discussion and brainstorming. The ScrumMaster facilitates the retrospectives and let the team choose what aspect they want to improve for the next Sprint. Because the team is very technical, most of the discussion revolves around improving engineering practices, i.e latest frameworks, continuous integration, BDD, etc. Improvements get accomplished. But the point is the team thinks that rather than allocating special time to do retrospectives, they said why can’t they just do that within the sprint? The team gets the idea from Kaizen that is implemented in Toyota where the team gather in an instance to find a way where they can improve rather than going to a specially allocated sprint retrospective. Read More

Post-Agile?

Seen on Twitter

“Most people doing Agile today are actually doing Waterfall with Agile terms. Agile is dead.”

There are a lot of people talking about “post-agile” now that the word Agile has been taken up by the masses, including those selling products and services with the word without ever doing what some might consider to be truly Agile. Read More

Build a Cache, not a Stash

There are many times where a call to get some data is time-consuming or expensive. Perhaps it makes a webservice call, or a network connection to a database, or iterates over a large collection to perform a calculation. If the values isn’t going to change rapidly, and might be needed again soon, it’s natural to want to save the value for that use. Read More

Technical debt comes in various varieties

Ward Cunningham originally coined the term Technical Debt and described it at OOPSLA 1992

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

In this, Ward was not referring to poor programming practices, Read More

Lessons from Sailboat Racing

Recently, I was attending a sailing seminar on racing small keelboats. As the lecturer talked about the crew requirements for winning races, I noted a lot of similarities with effective software development teams. Both situations require a small group of people to work in coordinated concert to achieve a common goal. No one on the team succeeds alone–they all reach the finish line together. There is a mix of specialized skills and general work that almost anyone can do. And there is a constant need for improvement, coupled with a desire to go fast. Read More

Running cucumber on jruby under ant

I’ve just spent more time than I expected getting this to work. It seemed like it would be easy, since running cucumber from the command line is so easy. But ant is very helpful in sanitizing the environment for subprocesses–a little too helpful, perhaps. After chasing a number of dead ends and increasingly complicated detours, I ended up with this target: Read More