Several back-end developers and front-end developers want to become full stacks by taking other tasks other than their specialties. For example, back-end developer wants to take some front-end tasks. As a team lead, I did let them do it in last sprint. They are kind of like the way switching roles, but the overall development speed becomes slower.
Is there a better way to manage this situations that keep my developers happy and keep productivity?
Is there a better way to manage this situations that keep my developers happy and keep productivity?
It's good to establish a certain amount of points up-front that will go into "individual progression" time - that way you're limiting the amount of investment you're making each sprint.
That's the other key - calling it out as an investment, because it is. The more cross-skilled your team is, the more coverage you have (to cover leave, or resignation) and the greater ability you have to swarm on bottlenecks.
But like all investments, there's an initial cost to the payoff. The cost is velocity/productivity. Sacrifice some productivity now to get benefits later.
Like most things moderation is key. If you invest too many points in developer development then you'll kill your velocity. Too little and you're not progressing your team. Find the balance that works for you, pitch it to all your business stakeholders as an "investment", and make sure that you set a clear limit (may be as simple as one developer per sprint is allowed outside their comfort zone). Once it's in place make sure you measure overall velocity and ensure that it is increasing in the longer term, because it should be (more cross skilled developers should lead to greater productivity).
A good way to share knowledge is pair programming.
As a team I would watch "Niclas Nilsson & Hans Brattberg - The Pair Programming Show" (The audio is not so good, but they explain pair programming and its pitfalls as the best)
