Greg Skerman

To me, the whole idea of managing scope is antiquated and not particularly useful. It assumes a fixed up-front plan from which you can deviate. It assumes a schedule based on that up-front plan. However, scope defined upfront does not work, and it never has. The notion also assumes project thinking, where you estimate based on that up-front plan. To me, all of this is dysfunctional. It's best to figure out what to do next by doing the current thing (and getting feedback). Talk to your customers to figure out where to start. Pick the smallest core of the core of the core idea and build that. Get feedback. Use that feedback to decide what to do next. Release immediately to get revenue sooner. There are no projects. There is no "scope" to creep. There's just a continuous stream of added value. Stop when there's nothing valuable to add.

Rule #1 of Software Architecture: YOU ARE NOT NETFLIX! If you don't have 270M users, a quarter of which can be on the system simultaneously, you don't need the complexity necessarily to support that. Build exactly as much architecture as you need. Build it so that it can grow incrementally. Do not future-proof.