Agile*Product*AI

The best team size is one that’s small enough to stay nimble, yet big enough to have someone to blame when things go wrong! Scrum recommends a team size of seven people plus or minus two. While seven to nine people seems reasonable, in my experience, it’s hard to imagine a Scrum team size of five taking on complex commercial software - that would be something like the Scrum Master, Product Owner, Two Developers and a Tester. If we look to the popular scaling frameworks for guidance on team size, Large Scale Scrum (LeSS) defers to Scrum for team size guidance as according to its principles, “Large-Scale Scrum is Scrum” while the Scaled Agile Framework (SAFe) recommends 10 or fewer people. Interestingly, in a somewhat dated survey from Scott Ambler, he found that “roughly half (48%) of agile teams are more than 10 people in size and one-quarter are more than 20 people in size.” It’s unlikely things have changed materially since 2016. This is likely due to the state of agile adoption, awa...

Will increasing the amount of people on a team accelerate value delivery? In the short term, increasing resources on a team that has normalized (see the Tuckman ladder model - https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development) will likely decrease its velocity as it takes time for the new person to understand the nature of the work and the culture of team. People learn to work together, to improve together, they build trust, they win together and they lose together. Whenever you change the configuration of a team (by adding or removing people) they will probably take a few steps back into Tuckman’s journey or be caught by Brook's Law. The positive impact to the team may take weeks or even months to be realized. Or worst case, the new addition is a bad fit for the team and either self-selects out or is rejected and you’ve likely caused damage to the team that could take weeks or months to recover from, and perhaps impact the career of the person you moved to the ...