After years of idealistically trying to adopt various forms of Agile methodology for small (actually micro: < 6 people) teams, we've come to the conclusion that either we are doing it wrong or maybe there are better methodologies?
What have you found to work best for really small teams? Is there a sweet spot in team size?
I"m hoping to uncover some useful data through my Master's Thesis research - so if you have any insights into or experience with this, I would really appreciate your input.
As per community guidelines, I've refrained from adding the link to the research instrument (2 minute survey) here. However, if you are interested in participating and would like to hear about what the data and research uncovers, I'd be happy to share this.
Adaptive approaches need to fit the context of the work being done. Assuming the work lends itself to an adaptive approach, picking the right set of roles, practices & tools can avoid the "square peg in round hole" outcome when a particular framework or methodology is applied "as is" without profiling your context or tailoring your approach.
And, you do need to ensure that the right "system" is in place to support the tenets of adaptive delivery. If your leadership team is unwilling to empower the team to make decisions about their ways of working, team members are multitasking excessively, or any number of other dysfunctions, any delivery approach will be equally challenged.
I have led, worked as part of, and coached small delivery teams of under six members using adaptive approaches successfully but have also seen my share of teams of all sizes struggle when the environment was not conducive to delivering in this manner.
Kiron Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Your question is not only timely but essential — especially as the “Agile for everything” mantra is being increasingly scrutinized in real-world contexts.
From my experience leading both small and large teams across different domains, I’d argue that Agile doesn't inherently "suck" for small teams — but it does require thoughtful tailoring. Many Agile frameworks were originally designed for small, cross-functional teams (Scrum, in particular), yet ironically become over-structured when rigidly applied to micro-teams.
Here are a few key insights I’ve found valuable:
1. Team Size and Cognitive Load
For teams under 6 people, the main challenge is not process overhead — it’s clarity of purpose, autonomy, and rhythm. Lightweight methods like Kanban or Lean with daily standups and visual boards often outperform a full Scrum implementation, which may introduce unnecessary ceremony (e.g., Sprint Planning + Retrospectives + Reviews).
2. Beware of Dogmatic Agile
When frameworks become the goal instead of the delivery of value, small teams can quickly feel stifled. Agile should be adaptive, not prescriptive. It’s perfectly valid — and even advisable — to blend elements from Agile, Lean, or even traditional task tracking, depending on the maturity and dynamics of the team.
3. The Real Sweet Spot? Psychological Safety and Focus
In very small teams, collaboration is intense and interpersonal dynamics matter more than processes. Psychological safety, clarity in roles, and a shared understanding of value tend to drive performance more than sprint velocity or story points.
If it helps your thesis, I’d also recommend exploring case studies where micro-teams operate under Design Thinking + Agile hybrids — particularly in startups or product discovery contexts. These often reveal the limitations of textbook Agile and the strengths of principle-driven adaptation.
I’d be glad learn from what you uncover. Saving Changes...
I'm curious what issues you found that you believe were due to the team size. The first step in problem solving models is clearly identifying the problem.
I have certainly encountered many people who "tried agile" and had very bad opinions about it. My experience is that they took an approach from elsewhere that didn't fit their situation and tried to follow a structured methodology like dogma without tailoring it to their own situation.
I find it easier to introduce agile methods in small teams than large ones. A couple reasons are that it is easier to gain concurrence on our methods when there are 6 rather than 100 voting parties or getting critical people dedicated to the project rather than splitting their time among several projects.
In short, in what way did agile in small teams suck? Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
The first error and big mistake is do not understand what agile really is. Agile was created in 1990 in manufacturing field, not in software field. I was part. And I was part of the movement that move agile to software field. Agile is an approach that was created as an alternative to Lean. And in software, people that had object oriented methods to create software products took the word agile time after but not in 2001 when the manifesto was created. By the way, the word software is in the manifesto´s name for a reason. Saving Changes...
Agile can use any field, especial the idea not the shap.
The one use the agile thinking, but he can not know it is using.
I think need join and act the PM about over 5 year,and lead >10 sucess project, then you will know the thinking. Saving Changes...
