Hustle, v: To move quickly and with purpose.
Several years ago, I hired a small local moving company to move my belongings from one apartment to another. When the movers arrived, I was surprised and impressed to see them "hustle:" they moved quickly from the van to the apartment, not quite running, and back. This was particularly impressive because I was paying them by the hour. There was no need for them to move so quickly.
Those movers impressed me. I felt that they were dedicated to meeting my needs and respecting my pocketbook. If I still lived in that city and I needed to move again, I would hire them in an instant.
I already know what it means for a normal team to hustle. It means heads-down programming, long hours, long meetings. They look like they're working hard. Now, we know that long hours and long meetings don't help get software done any quicker. But all that busy inactivity helps give people a warm fuzzy feeling about how hard everyone is working.
XP teams can hustle too, without being wasteful about it. There are lots of ways to give a sense of working hard on behalf of the organization. One of the most effective I can think of is to simply take your customer's goals seriously. Customers have date and functionality targets. We know that we can't fix both date and scope, but we can usually adjust scope in order to meet a specific goal by a specific date. One way to hustle is to constantly think about the customers' goal as you're estimating stories. If something is expensive, suggest alternatives that still meet the customer's goal, but are easier to program.
Other options include evangelizing your team's successes. If you've got a commercial product and you're releasing trials to customers every six weeks, you can post a Big Visible Chart outside the bullpen, or near the entrance, that shows the date of each release and has a selection of customer comments. If you're updating a web-based product every day, you can post a different sort of Big Visible Chart that shows a calendar with each update prominently marked along with the new features and number of defects for each one. A brief status email each iteration highlighting the stories that were just finished and why they're valuable is a great option for an organization that respects emailed status reports.
Another approach I've always preferred is to take responsibility for estimates. Once a story has been scheduled for an iteration and I've had a chance to revise the estimate, I take the estimate very seriously. I keep an eye out for major problems and notify my customer as soon as I suspect anything will derail the iteration. At the iteration's halfway point, I doublecheck to see that about half of the stories are done. If we're a little bit behind, I let the team know and I stay late a few nights in order to get things done on time.
At one of the early XP conferences, perhaps even the first XP Universe, Kay Johansen reported about an XP project that was cancelled. As I remember the story, Kay said that the project was meeting its commitments and delivering regularly. And yet, it was cancelled in favor of another project team. Why? Because when management looked in on the other team, they saw programmers working hard, heads down, long hours, UML diagrams papering the walls. When they looked in on the XP team, they saw people talking and laughing, going home at five, and no evidence of progress.
Like it or not, our projects don't exist in a vaccuum. Changes happen in organizations all of the time, and even once-golden projects can lose their sponsor. If you're trying something that, to your organization, seems weird and different to people who aren't part of it (like XP), you're vulnerable. Not to losing your job, but to losing your project. (And after experiencing a successful XP project, who wants to go back?) A little bit of hustle can go a long way towards generating good will and inspiring people to stick up for you when leadership or priorities change.