> I feel like the current trend of agile development process common in startups now somewhat works against senior devs' interests to mentor junior devs. There simply isn't time allocated for this.

If you're a senior dev, you should be gaming the system a bit to create the time needed to fulfill your role. Never let the keeners fill your time up to 100%, unless it's truly neccessary. There's always going to be some infrastructure that needs fixing, research that needs doing, refactoring that should happen, etc. And you should always have some slack for mentoring and whiteboard discussions.

I almost always start an agile sprint with a self-generated task or two already in my queue for just this reason.

If the system has to be gamed to achieve the best results for your team then the system is flawed.

The system is flawed.

My team counts new devs and juniors as 1/2 person from a point perspective when we are doing planning. Juniors usually get this sand bag until we start beating our sprint goals again.

Perpetually flawed. No matter how much resources you throw at fixing it.

There's a huge difference between "no system is perfect" and "the dominant process for development work in our industry completely ignores work that nurtures employees into being better employees."

The goal of agile, as implemented in most shops, is to get things done quickly and to establish a reporting cadence with management.

Nurturing employees, and indeed software quality, is the product of company and team culture.

The development process is concrete (and “SMART”), so that’s what many managers focus on. The cultural aspects are more nebulous, so they are ignored.

"...and a whole bunch of other important things."

Always.

The system sets the board rules. You play the game. No system will ever play for you.

Working in an agile team at the moment. I have zero time to be able to help the junior members of the team. Having a mentor is important but having a good mentor, somebody with the right skills and attitude is crucial. I'm watching helpless as the junior Devs take advice from the worst possible sources because they are the ones with the free time

I doubt that agile is the problem here. I've seen organizations which weren't even agile having the exact same problem, not just for devs. It's pretty much the same with manager/project manager positions.

I think a much better explanation is outsourcing. A company which does a lot of outsourcing only needs a few people managing the partners. Managing an outsourcing partner is next to impossible for a junior as they lack the crucial experience. So they try to focus an experienced personnel. I don't know if that is the way outsourcing is supposed to be done, but at least its the way I have experienced it.

There might be other reasons for this senior-only sickness, but I am pretty sure pointing at agile is the wrong direction. If you are unhappy with the 'agile schedule', maybe its time for

> Responding to change over following a plan

Agile doesn't really foster collaboration in general. You can't have one ticket assigned to two developers and have them pair program, from the business perspective rather than the best way to develop inexpensive new talent pair coding is a massive waste of time and resources. However agile works really well for remote workers who have little social contact outside of the daily standups and slack. It helps to be an autodidact in the industry in general no matter where your skill level is. I've had kids with almost no experience smoke me on react because we were both having to learn it at the same time and the kid was a better autodidact than me.

Actually you can have a ticket applied to more than one person in an agile process. You must've been thinking of Scrum in particular which does not allow the practice.

(The original agile process called Extreme Programming actually mandated pairs.)

Indeed, a task not budgeted in time is not done. That pertains to tests, static quality analysis, performance optimizations and use case analysis. None of these are explicitly budgeted in agile processes, though they say "write tests" or "definition of done", these are taken as suggestions.

Strongly agree. I would like to spend more time teaching junior developers what I know. But anything that slows down a small, agile startup can mean the death of the startup, so this tends to undercut my ability to do any kind of mentoring.

Excerpt from a real life situation I was in:

===========================

June of 2015:

Sital was a beginner. In general, there is nothing wrong with being a beginner. All of us are beginners at some point. And for the most part, I think corporations in the USA can do more facilitate apprenticeships to help people start their careers. However, we were a startup that needed to move fast. Could we succeed when we had a beginner in a critical role? I had doubts.

July of 2015:

I felt no sympathy for John. Hiring Sital had been his call, as was failing to hire Arthur. These last few weeks had offered plenty of evidence that Sital was a liability to the team. If John wanted to stick with Sital, he would have to live with the consequences.

I would feel very differently if Celolot had a formal commitment to an apprenticeship program, and if I had clearly been given the responsibility of running that program. And I do think corporations in the USA can do more to help people start their careers. But it was ridiculous to both want to run an aggressive schedule and also train a beginner. The one contradicts the other.

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

> Could we succeed when we had a beginner in a critical role?

This is core issue. This has nothing to do with startup team vs team in corporation. Neither can have beginner in a critical difficult role. Both can make use of junior, assuming they dont put him to critical role.

Where is best to place a beginner? Too easy and they get bored. Too hard and they get demoralised when somebody else has to step in. Give them side projects and the work load for the team goes up with code review etc for unnecessary work.

I agree with what you are saying in that it needs to be called out that time needs to be specifically set aside in agile / sprint planning for mentoring. My manager understood this and I was allocated at least a day sprint to just 'mentor' my junior dev through a 8 months rotational stint in the team. Mentorship is very rewarding and I found out that I got just as much out of the relationship as they did. It also helped that for the first 4 weeks I was allowed to run her through a self lead learning program that I designed for them. Giving a new hire out of univiristy time to learn enough of what they needed to tackle some high value work just made the final outcome so much more successful.

You are supposed to modify and fit Agile into your specific process, not follow it dogmatically. It's literally the first thing on the manifesto: "Individuals and interactions over processes and tools". Change the process, or change the culture around this instead of blaming a broken process.

To add an example: At this company they have the concept of an IP (Innovation and Planning) sprint. This means that one sprint out of 5 we take to fix technical debt, add instrumentation, verify documentation. You should have some time carved out for mentoring.

At the very least, don't count the juniors in your capacity. This way you'll be able to handle their pace while keeping your velocity.

We account for that during spring planning. We plan on pairing on tasks/stories for general knowledge transfer and mentoring. If this affects velocity, that is actually a good thing (tm). Velocity should decrease when onboarding and mentoring, and then should increase as those team members become more efficient.

I have the same suspicions about the agile process as well. Great to be fast and producing but it's counter-productive if not everyone is at a similar level of output.