In the past I’ve talked about peer reviews, on the idea that you will always get some negative feedback, no matter how hard you try. It’s partially the concept of “done”. As in, is anything ever done, complete, there’s nothing else to do?

What’s fascinating to me is how this intersects with the concept of Agile. Think about some modern software applications, especially APIs and microservices and web-based apps. Are they ever really done, as in complete? They seem to just iterate new versions forever. Would something like Netflix or Facebook or Slack ever be done? There’s always more features to build, more optimizations to add, more defects to address. Same with IT projects. Is the corporate network ever “done”? Are your IT management processes, like patching, ever “done”? Pragmatically, many modern engineering and IT efforts are never really done. And that’s what Agile tries to embrace. You’re never done, you jut continuously prioritize your backlog and work on tasks with as much velocity as you can.

The same goes with a document, presentation, or even your software product. It will never be 100% done. That’s why there’s the concept of Minimum Viable Product (MVP). At what point is the thing in question “good enough” that it can be used, sold, or deployed and bring value and use?

Keep this in mind, as you are both reviewing and building. When reviewing you can always find something wrong, or have a suggestion to do better. And you don’t want to keep those thoughts just to yourself, but it doesn’t always mean that the thing you are reviewing is not in an MVP state. And when you are building, this is why “iterate early and often” is a good approach. Find your path to MVP, get that usage and value out to your customers early!