Please login or join to subscribe to this thread
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.
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.
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.
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.
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.
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