Project Management Central
Please login or join to subscribe to this thread
|
|||
|
|||
![]()
My team now is 6, including myself, with 3 being remote. I understand it may increase over the course of the year though. Previously, I was part of a larger team of around 15. Much of what will work is dependent on the environment and functional complexity and size. When we had the larger team, it was with a very complex system, where each team was based on system functions. There were many moving parts and several programming languages, hence the increase in members. It worked very well, impressively well actually. All team members were co-located.
In short, it depends :) ...
1 reply by Sante Delle-Vergini
Jan 20, 2018 8:37 AM
Sante Delle-Vergini
...
Great, thanks Andrew. Team size could be a theory unto itself.
![]() Jan 20, 2018 7:23 AM
Replying to Drew Craig
...
My team now is 6, including myself, with 3 being remote. I understand it may increase over the course of the year though. Previously, I was part of a larger team of around 15. Much of what will work is dependent on the environment and functional complexity and size. When we had the larger team, it was with a very complex system, where each team was based on system functions. There were many moving parts and several programming languages, hence the increase in members. It worked very well, impressively well actually. All team members were co-located.
In short, it depends :) ![]()
Sante -
if you are talking about an individual agile team or pod - I would usually go with the old 7 +/- 2 in general to avoid being impacted by the n*(n-1)/2 non-linear communication channels issue. Exceptions can happen depending on the scale of the project scope and the experience and maturity of the team itself. For example, I'd give the 80s show A-Team any project to do and they were just 4 people :-) ! However, if you are talking about the size of an overall team to deliver a product or project, it could be much larger, but you'd divide the project along logical lines (e.g. feature, component, value stream) and have individual agile teams working on each with coordination occurring between them implicitly or explicitly. Kiron ...
1 reply by Sante Delle-Vergini
Jan 20, 2018 6:29 PM
Sante Delle-Vergini
...
Interesting. Many people like the number 7, for several reasons. I would say 6, but the right choice can be subjective and is certainly project-specific.
![]() Jan 20, 2018 9:03 AM
Replying to Kiron Bondale
...
Sante -
if you are talking about an individual agile team or pod - I would usually go with the old 7 +/- 2 in general to avoid being impacted by the n*(n-1)/2 non-linear communication channels issue. Exceptions can happen depending on the scale of the project scope and the experience and maturity of the team itself. For example, I'd give the 80s show A-Team any project to do and they were just 4 people :-) ! However, if you are talking about the size of an overall team to deliver a product or project, it could be much larger, but you'd divide the project along logical lines (e.g. feature, component, value stream) and have individual agile teams working on each with coordination occurring between them implicitly or explicitly. Kiron ![]()
Although it depends on type and complexity of project, I have had 5-6 members on my team and it is because I have experienced that smaller teams have better communication, all members are better acquainted with each other and are more focused on project goals.
...
1 reply by Sante Delle-Vergini
Jan 21, 2018 2:34 AM
Sante Delle-Vergini
...
Certainly smaller teams makes communication less complex, and 6 seems like a good number. Thanks Najam.
![]()
Giuliano Caracciolo
Senior Director, Delivery Operations| Points (A Plusgrade Company)
Toronto, Ontario, Canada
I agree that 5-6 seems to be the best number to create high output without causing confusion within your team. I also noticed it's much easier to gain alignment with organizational / project goals which should be a top priority for any project manager / scrum master to enforce.
Lastly, while the team may be small, you still get a great mix of experience and perspectives if you've done your staffing properly. ...
1 reply by Sante Delle-Vergini
Jan 21, 2018 2:48 AM
Sante Delle-Vergini
...
Agreed. Team mix and cross-functionality is more important than team size,
![]() Jan 20, 2018 9:05 PM
Replying to Najam Mumtaz
...
Although it depends on type and complexity of project, I have had 5-6 members on my team and it is because I have experienced that smaller teams have better communication, all members are better acquainted with each other and are more focused on project goals.
![]() Jan 20, 2018 9:19 PM
Replying to Giuliano Caracciolo
...
I agree that 5-6 seems to be the best number to create high output without causing confusion within your team. I also noticed it's much easier to gain alignment with organizational / project goals which should be a top priority for any project manager / scrum master to enforce.
Lastly, while the team may be small, you still get a great mix of experience and perspectives if you've done your staffing properly. ![]()
Rajeev Sharma
Principal Consultant | Strategy, EA CoE | Digital Transformation, AI and Gen-AI| Tech Mahindra
Gurgaon, Haryana, India
5 +/-2 being a magic number for me in seven year expouser !
However when it came to product portfolio's or product lines ownership (in industry vertical) - i had 5-6 such parallel groups to satisfy sub domains. ![]()
Demetrius Williams
Atlanta, Ga, USA
I would agree with Najam. Team sizes of 5 or less, there is less complexity in communication. It really depends on the experience of the team and how well they work together. Have they worked together before on other successful projects? Do they know how to best communicate and interact with one another?
|
Please login or join to reply
ADVERTISEMENTS
"Nearly every great advance in science arises from a crisis in the old theory, through an endeavor to find a way out of the difficulties created. We must examine old ideas, old theories, although they belong to the past, for this is the only way to understand the importance of the new ones and the extent of their validity." - Albert Einstein |