1. Write a monolith.
2. If the project fails or doesn't really need to scale in terms of code or hardware, you don't need microservices.
3. If the project succeeds, and the code size and team size starts to grow, start looking for parts of the monolith that make sense to encapsulate as their own services.
3a. Also look to see if some parts of the monolith need to scale more than others. This can also indicate part of the code to break out into its own microservice.
4. Now that you have identified potential microservices, very carefully think through the API for each microservice. APIs are very difficult to change after they are widely used, so its important to get it as close to right as possible the first time. API design does not lend itself to "agile" very well.
5. Now you are ready to create your "two pizza" teams and start implementing your microservices.
6. Don't bother thinking about Kubernetes too much before this point. Until you really need to scale, it just adds unnecessary complexity. (But when you need it, you really need it!)
6a. Same may or may not be true for Docker, it can potentially simplify deployments, but if what you have works and isn't creating significant toil, you can always introduce it later.