25 interns to 2 mentors is crazy. An intern's job is to learn, not to be productive, and I doubt they're learning anything in that environment. I would just ditch the project and focus on setting up the interns for success later in life. But if you have to try to make this work then you'll need to spend a lot of time breaking down work into simple tasks and treat the interns as a work-stealing queue.. but you'll have to spend a lot of time unblocking them still. likely more trouble than it's worth

I know! 😅 What we did initially was to identify couple of kids who had some experience with the stack and setup tree structure for problem solving in parallel. As you said, I turned my focus full time on understanding requirements and making it simpler for them to understand and helped them write stories. Most of the kids have great enthusiasm and they put in lot of effort, and they have learnt lot of things over past few months (apart from tech) Should we just abandon the fixed time box approach and handle each business module in parallel and track the progress independently?

IMO as long as they're having fun and learning things anything else is secondary. I would treat any intern work as disposable, as you likely know the value of code isn't in the code but in the engineer's understanding of how it maps to business needs, and all that will go away once they go back to school or whatever.

It is a little different here. The org has old ties with the university and every year we get interns from a batch (current team is made of batchmates from same college) But yeah, I agree with your point.

Chop the work up and automate as much of you can in the 'testing and development', this eases unnecessary communication feedback loops. Then, break the interns into smaller teams, each led by a senior member or the most capable. Evaluate them and cluster by strengths e.g. front-end, back-end, testing etc.. > Between tools, automation and team segmentation, you will get the biggest productivity boost from my experience. For normal work-life balance I strongly discourage working late, deadlines or not. Missing timelines is to be expected with an inexperienced workforce but productivity is more important. The more you work late, the higher the chances of more mistakes due to poor thinking / reasoning. Lastly, agile just doesn't work with junior experience so I would drop it all together for the interns.

A classic case of constraining communication (in many ways), in my humble opinion. On the surface there seems like so many issues here • Too many people hired - give most of the students some courses to do to improve there skills (or side projects that don't require much/any guidance) and have a small core team working with an experienced developer to create the product/service/app. This allows progress to start and as people gain experience the core team can be slowly expanded • People working on tasks they don't understand and therefore have no idea of timeframes (rushing because of perception that they should be delivering faster and naturally making lots of errors in the rush - why have estimates and time boxes? Drop all estimates and time boxing. A senior should prioritise the daily/weekly work after breaking it down into small pieces and at least review all stories to make sure everyone working on the ticket actually understands them - a daily standup can be used to identify who needs help and who can help them • Trying to prescribed process top-down without understanding by the team (any process should be adapted to the team, the needs of the business and to what can reasonably be achieved) - agile practices should be introduced in an agile approach (e.g. incremental and iteratively) ensuring the team understands the value of them and that those practices help the software team provide value to the business. Identify the principles people should be aware of and ensure specific practices are understood (and valuable to the team) • Possibly a misunderstanding of what is meant by agile and a software process in general (there is no single agile approach, it's a collection of principles and practices to be applied where relevant) - discuss with the team how they work via a monthly retrospective, what they do and don't understand, what works, what is a challenge, etc. This can also be raised at a standup and decided if it needs to be addressed sooner All of these issues are widespread throughout the software industry (and many others). Good practices can help when introduced at the right time with the right level of understanding otherwise it's not actually following any process.

if the agile team is missing deadlines, (for large intern teams in particular, from my experience), 1. make the interns log any questions or problems they face during development every day and how they solve it, and post it in a public chat/forum so every other intern can see what other people are doing and learn from each other. This also serves as a early warning system, if one intern is stuck on something for more than 2 days a mentor has to go down and schedule 1-on-1s until the issue is resolved. 2. Intern outputs are usually 1/2 a junior level programmer, 1/4 a mid level, and 1/8-1/10 or more a senior level give or take, so that would need to be factored in while planning workloads. 3. Avoid having the interns provide estimations for agile planning. Provide a base and then let them vote on whether they think it’s appropriate or not if you want to let them participate. 4. Identify intern leaders and have them act as auxiliary tutors in the group 5. Try to avoid having interns handle communication with external groups unless your team has established SOPs for communication, these soft skills are not easily acquired, so someone senior should be handling it, or there’s alot of time wasted in communication and triage 6. WRT above, the mentors should either be full time code reviewing, providing guidance, writing documentation to establish SOPs/requirements if its just 1:10 ratio. the better ratio is 1:3 or 1:5 then you can afford to have them part time

Thanks @U01458A7CBX we are following couple of them with good results. It is helpful to see actionable points.

Thank you @U05RVCQUK7X @U05254DQM I’ll try out your suggestions

Fred Brooks' "The mythical man-month" was a seminal work on the subject. Not really of constructive use at this moment, but it could help shape intern allocation for future years.

I came here to say the same except, to get NGO management to read Brooks. They created the situation!

Given the scenario, Initially spending a month or a two doing Mob-Programming could be an effective way to ramp up the skills and awareness of quality and expectations.

Start delegating smaller tasks with appropriate level of challenges. Let the feedback loop run often. Set the tone positive and direct. Identify top performers and pair them with next level performers in a way that everyone grow. The key here is letting individuals drive themselves in learning, performing and delivering.