In the start of this chapter it was very interesting how they evaluate the teams in terms of how they did the design of the project, I consider important that the biggest team did worse than the other teams because for planning is harder to that with a lot of people instead of just few people that design everything and then divided the work to the rest of the team, but the problem with that is that you have people that is not working until the design is finished.
The problem of not making a good partition and design from the beginning is that you consume a lot of time just in meetings with your teammates to organize how you can do the job, that means more interaction that consume a lot of your time just planning something that should have been planned from the beginning and now you are wasting time in doing the planning and coding at the same time.
I agree with the graph above, the ideal form of starting a project first is to have low staff numbers, this is because at the beginning you are not coding or dividing the work, at the beginning you should be doing some planning and design how the project is going to be divided, how many modules and then with all the design you can start getting more staff and assign them a specific part of the project and thanks to that avoid a lot of meetings and the most avoiding frustration among your staff.
So in conclusion is better to design everything fist with few people that letting a lot of people to start the design, because in the last case the design would be divided into teams and then it will end like an attempt of design and at the end the design would be created while coding, instead of coding in base of the design.
Erick learning experience 