shhh! I have a secret to tell. As a Principal Solutions Architect in the VMware Pivotal Labs App Modernization practice I have to often scope app modernization projects where we decompose or rewrite massive monoliths, Batch processes, ETL or port legacy apps at scale to Cloud Foundry or Kubernetes platforms. After a scoping session sometimes you struggle determining the exact duration of the project. At Pivotal we always bias shipping to production and working in incremental chunks i.e. fixed time variable scope. In situations like these where I am not sure about the scope my go to default - from the gut after working in this space for 5 years - is a team of 3.25 @ 6 weeks.
As humans we always seek approval and are especially prey to confirmatory Bias. The recent ShapeUp Book from Jason Fried and DHH validated my natural affinity for 6 week projects. They have articulated brilliantly what I have been struggling to say ...
Now the next question to ask how about the 3.25 size projects ? First of all the .25 is a product manager who helps in Inception and is a client liaison at critical times. Sometimes for a challenging project we have a full time Product Manager. The rest of the team are 3 engineers or 2 engineers and 1 designer depending on a mix of frontend and backend work. But WHY a team of 3.25 and not 2.25 or 4.25 or 5.25. Here I put forth a picture to explain the communication overhead as
A team size of one is almost never recommended unless the project duration is less than a week. This leads to loneliness and burnout over the long term. There is a reason most startup founders are asked to look for a co-founder. Our projects are mini-startup projects that sometimes involve the same level of stress and entrepreneurship. With a team of two there is no fallback i.e. if one engineer is out of commission then the entire load falls on the other engineer and we are back to burnout and loneliness.
The ideal starter team is 3 people with high fidelity communication and load balancing across team members. When the team size bumps to 4, you now need 6 lines of communication adding unnecessary overhead. At a size of 4, if each developer eats 3 slices of pizza, then you are at 12 slices and two pizza team. In a product development R&D setup that is fine; however when the team is on the road on an entirely unfamiliar territory you need to extremely nimble and tight. Therefore from a people happiness, productivity and mental health perspective the ideal team size is 3.25. In case of big projects it is OK to ramp this up to 4.25; however when team size increases to more than 4 and you should split the team into two teams of 3 engineers.
TL;DR When in doubt go with 3.25 @ 6 weeks.
Happy Hunting!
As humans we always seek approval and are especially prey to confirmatory Bias. The recent ShapeUp Book from Jason Fried and DHH validated my natural affinity for 6 week projects. They have articulated brilliantly what I have been struggling to say ...
" After years of experimentation we arrived at six weeks. Six weeks is long enough to finish something meaningful and still short enough to see the end from the beginning. "In fact they have a full chapter dedicated to Six Week Cycles in their Book ShapeUp. If you would like to go on a confirmatory bias victory lap on a weekend, you would do no wrong by binge reading this chapter and the full book.
Now the next question to ask how about the 3.25 size projects ? First of all the .25 is a product manager who helps in Inception and is a client liaison at critical times. Sometimes for a challenging project we have a full time Product Manager. The rest of the team are 3 engineers or 2 engineers and 1 designer depending on a mix of frontend and backend work. But WHY a team of 3.25 and not 2.25 or 4.25 or 5.25. Here I put forth a picture to explain the communication overhead as
 |
| Brook's Law |
The ideal starter team is 3 people with high fidelity communication and load balancing across team members. When the team size bumps to 4, you now need 6 lines of communication adding unnecessary overhead. At a size of 4, if each developer eats 3 slices of pizza, then you are at 12 slices and two pizza team. In a product development R&D setup that is fine; however when the team is on the road on an entirely unfamiliar territory you need to extremely nimble and tight. Therefore from a people happiness, productivity and mental health perspective the ideal team size is 3.25. In case of big projects it is OK to ramp this up to 4.25; however when team size increases to more than 4 and you should split the team into two teams of 3 engineers.
TL;DR When in doubt go with 3.25 @ 6 weeks.
Happy Hunting!
