Were roughly midway through our transition from waterfall to agile using scrum; weve changed from large teams in technology/discipline silos to smaller cross-functional teams. As expected, the change to agile doesnt suit everyone. There are a handful of developers that are having a difficult time adjusting to agile. I really want to keep them engaged and challenged, and ultimately enjoying coming to work each day. These are smart, happy, motivated people that I respect on both a personal and a professional level.The basic issue is this: Some developers are primarily motivated by the joy of taking a piece of difficult work, thinking through a design, thinking through potential issues, then solving the problem piece by piece, with only minimal interaction with others, over an extended period of time. They generally complete work to a high level of quality and in a timely way; their work is maintainable and fits with the overall architecture. Transitioning to a cross-functional team that values interaction and shared responsibility for work, and delivery of working functionality within shorter intervals, the teams evolve such that the entire team knocks that difficult problem over. Many people find this to be a positive change; someone that loves to take a problem and own it independently from start to finish loses the opportunity for work like that.This is not an issue with people being open to change. Certainly weve seen a few people that dont like change, but in the cases Im concerned about, the individuals are good performers, genuinely open to change, they make an effort, they see how the rest of the team is changing and they want to fit in. Its not a case of someone being difficult or obstructionist, or wanting to hoard the juiciest work. They just dont find joy in work like they used to.Im sure we cant be the only place that hasnt bumped up on this. How have others approached this? If youre a developer that is motivated by personally owning a big chunk of work from end to end, and youve adjusted to a different way of working, what did it for you?
How can we make agile enjoyable for developers that like to personally, independently own large chunks from start to finish
agile;scrum
I will say that there are very few software shops that are fortunate enough to have the rare distinction where Agile truly doesn't make sense as a methodology.  If your entire team consists of truly exceptional software developers with a deep understanding of aspects of the business and longevity with the company and each other, and if your business requirements and client needs are typically always similar and rarely subject to changes in the middle of a release then you are fortunate to work in such a rare environment where Agile can probably actually HURT.It is designed to be the most effective approach amidst chaotic and constantly changing business requirements and customer needs, evolving or changing project resources, and tight or shifting deadlines.  Such an environment spells certain doom for typical waterfall development as it is vulnerable to team changes mid project, vulnerable to changing requirements, and extremely vulnerable to a changing date.I feel for your valuable team members who don't find joy in their work anymore.  They very well may be exceptionally talented people who engross themselves in their work but in the end, a number of factors outside of their best control can still kill the project.  The best way to approach feature development is for them to lose the individual attitude and expression and think in terms of the team approach.If you find that this won't work for them then you can find special use for them.  If they are exceptionally talented and experienced, see if they would be interested in an architectural role, laying out high level designs, approaches, experimenting with new technologies and evolving best practices.  Have these people control and review design documentation.If this doesn't suit them still then perhaps have them work seperately on extremely complex technical refactorings on a seperate branch, hugely involved prototypes and proof of concepts, or other trailblazing work that sometimes needs to be done but doesn't fit well in the scope of a single project or release.