Running a Retrospective

Luis,

These are great questions. I’ll take a stab at giving some brief answers:

-1. How do you deal with budget constraints?

We are in active communication with our clients all week. At our weekly retrospective, we’re reviewing how much we’ve gotten done, and how much budget we have remaining. In the event some parts took longer than we had planned, we are recalibrating how we plan to spend our remaining time to make sure that the best product gets built with the available budget. Sometimes budget discussions are between a project advisor and the client after the retro (to reduce the amount of team time used), but this is a pretty transparent process.

There’s sometimes an instinct to run away from what can be a tough conversation (talking about limited remaining scope), but it’s always best to discuss these things early and in a transparent fashion.

-2. How do you control how far you are in terms of features vs. budget burn rate?

The answer here is related to what I wrote above. We are shipping code and design several time a day and our clients are reviewing and approving those improvements, so it’s not a surprise how far along we are. Our clients are in standup with us every morning, and we are careful to bring things to the team’s attention if something is at risk of not getting in under the budget early enough that we can course-correct if need be. One corollary of this practice is that we try not to have the last week of a project be aggressively scheduled for new features so that there’s time to tweak anything before our time with the client pauses.

-3. We don’t do fixed budget projects. They are bad for us and bad for the client. You can read why in a response that @croaky wrote on Quora.

There’s a lot more about how we run our company’s consulting and billing practices in our Playbook.

2 Likes