Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Scrum
Best practices for Agile with large teams
Anonymous
Hi all,

I'm fairly new to Agile. My current team has become quite large and consists of developers, testers, business analysts and documentation. I was thinking of having an individual daily scrum for each group (one for developers, one for testers, etc). Does any one have any best practices for tracking large teams?
Sort By:
The best option is to implement an agile management software like Jira or Trello, to permit better control of the tasks and state of the project. In addition, the software can be accessed by each member of the project, with specific permission. So, members of the team can review their assigned tasks and adapt their work according to the actual status.
...
1 reply by anonymous
May 12, 2020 2:17 PM
anonymous
...
We are using JIRA, however, we are also having a daily standup. I fear having 30 people giving updates in one meeting that should only be 15 minutes.
Anonymous
May 12, 2020 2:13 PM
Replying to Verónica Elizabeth Pozo Ruiz
...
The best option is to implement an agile management software like Jira or Trello, to permit better control of the tasks and state of the project. In addition, the software can be accessed by each member of the project, with specific permission. So, members of the team can review their assigned tasks and adapt their work according to the actual status.
We are using JIRA, however, we are also having a daily standup. I fear having 30 people giving updates in one meeting that should only be 15 minutes.
The optimal size for a team is usually upto about nine or ten members. If you have 30 people then I suggest you split into at least 3 teams. Avoid splitting developers from testers however. Create cross-functional teams so that any individual team can complete an end-to-end increment of functionality, including analysis, design, development and testing.

The Scrum of Scrums approach is one popular way to co-ordinate between teams https://www.agilealliance.org/glossary/scrum-of-scrums. I suggest you start there.
Anonymous
This is great! I will look into this!
There are no "best" practices, only good ones you can consider to follow/ adapt in your project context. As a starting point, the Nexus approach is a good one to build on and easy to understand (based on scrum).
Once you get over the optimal size for a team, regardless of whether you are follow a predictive or adaptive lifecycle, there is the need to break up the team into smaller sub-teams.

Rule #40 from the 100 rules for NASA project managers rings true: A working meeting has about six people attending. Meetings larger than this are for information transfer (management science has shown that, in a group greater than twelve, some are wasting their time).

You may wish to investigate scaled agile models.

A number of them are documented within PMI's Agile Practice Guide, but I'd advocate looking into Disciplined Agile as it will provide greater depth and breadth of options than any other toolkit out there.

Kiron
We don't know the breakdown of roles among the 30 team members, but clearly 30 is way over what is realistic. Teams should max at 9 members, and be cross-functional, meaning the team has the right roles, experience, skills, etc. to perform the work - e.g. not required to look to outside the team to complete the work. This means keep a ratio of dev and QA together.
The daily scrum's intent is for a daily event of transparency, inspection & adaptation. Without the full team, the intent and value will be lost. This is a time for the team to share progress and impediments, thus providing other team members insight into what is happening in the team and can highlight state of dependent work, and more!
Before scaling, figure out what works, then scale that if needed. Without a solid foundation, the rest is moot.
GL!
Standups should be about the work done and to be done. Therefore, you want to group the teams around the people working on all the parts of a given work package.

You may find value in creating guilds for each discipline: one for developers, one for testers, ... The goal of a guild is to promote and share good practices in a discipline. Be careful though, you may find that individuals work in multiple disciplines.
In large teams normally I replace the daily meeting by walking the board by all team members at same time every day. But all depends of the team maturity and to the team context.

Alexandre Costa
If you cannot have you Daily Scrum Meeting in 15 minutes, your team is probably too big or you are getting into too many details. The Daily Scrum must include all team members.

My teams "walk-the-board" every day from right to left. Starting on the right is good because those are the stories/cards closest to being Done. It is a way to manage the Work In Progress and ensure we are working toward the Sprint Goal.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"The higher up you go, the more mistakes you are allowed. Right at the top, if you make enough of them, it's considered to be your style."

- Fred Astaire

ADVERTISEMENT

Sponsors