Take the 2-minute tour ×

We’re roughly midway through our transition from waterfall to agile using scrum; we’ve changed from large teams in technology/discipline silos to smaller cross-functional teams.

As expected, the change to agile doesn’t 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 we’ve seen a few people that don’t like change, but in the cases I’m 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. It’s not a case of someone being difficult or obstructionist, or wanting to hoard the juiciest work. They just don’t find joy in work like they used to.

I’m sure we can’t be the only place that hasn’t bumped up on this. How have others approached this? If you’re a developer that is motivated by personally owning a big chunk of work from end to end, and you’ve adjusted to a different way of working, what did it for you?

share|improve this question
There’s a great story of a manager of a Coca-Cola plant whose numbers were far better than his peers. When asked what his “secret” was, he said simply that rather than take a best practice and modify it to meet what the plant did, he instead modified the plant to match the best practice. You're not doing agile until you understand why youre doing it. –  rmx Jun 1 '11 at 15:04
add comment

migrated from stackoverflow.com Jun 1 '11 at 9:48

This question came from our site for professional and enthusiast programmers.

10 Answers

up vote 11 down vote accepted

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.

share|improve this answer
thanks for your answer. I think in at least one case we are gravitating towards your last suggestion when we can. We have to think about how the off-to-the-side project by a single person doesn't derail a lot of the community ownership we have developed, but that seems to be worth it. –  Kris Jun 1 '11 at 21:28
If you are going to do that with a few people then just pay attention to how it affects the morale of others who are actually doing project work. They may feel you are giving special advantage or preferential treatment to people who complain. –  maple_shaft Jun 2 '11 at 11:03
add comment

They just don’t find joy in work like they used to.


That's a big symptom that you're doing it wrong.

Agile should not impose a bad new order on people.

Agile should permit the team to self-organize in a way that makes it most effective.

Self-organization means management does not impose weird rules. It doesn't impose bad schedules and it doesn't impose needless interaction.


Why can't they continue to do this?

Why change them?

Please read the Agile Manifesto a few times.

The Agile Manifesto says

Individuals and interactions over processes and tools

It doesn't say force people to work in a way that's uncomfortable and unproductive.

If you're forcing people into too much low-value "interaction", then you've gone too far.

Working software over comprehensive documentation.

Are they doing this? Then leave them alone.

Customer collaboration over contract negotiation.

Are you already doing this? Then don't change.

Responding to change over following a plan.

Where these folks already able to respond to change? If so, then they were already Agile. They didn't need to change.

share|improve this answer
I'm absolutely certain we are doing some things wrong. We don't consider agile to be a set of rules that you must apply a certain way to be right. We've made decisions to ditch certain constraints we used to have, and have done everything in our power to put teams together, give them a job to do, give them some boundaries to work within, and leave them alone to do it. Of course there are constraints we have to deal with; for example, teams that produce material that other teams depend on. As much as possible, we make these sorts of problems something for the teams to solve. ... –  Kris Jun 1 '11 at 20:19
We don't expect to put our pens down some day and say "yay, our transition is complete, we work like this now", because we expect it to evolve forever. In every case where a developer struggles to enjoy work, they are surrounded by others that now enjoy work more. Teams are empowered to solve problems themselves, self organise to sort things out in the way they think is best. It has been remarkable to see how people react to this. "We can't go agile! It would mean we'd need to invest all this time in to blah, and get blah sorted out, and that's going to cost!" "It is? Ok, go for it." ... –  Kris Jun 1 '11 at 20:20
Perhaps I should have stated the problem differently. We now have teams that have self-organised and evolved to work quite differently than before, and on occasion individuals within the team no longer feel rewarded in the way they used to. Primarily this seems to come from the higher level of interaction between team members, the shared goals teams have, the way teams own their problems as a collective. If it were as simple as moving folks to another team that suited the way they wanted to work, that would be easy, but across the board teams are working this way. –  Kris Jun 1 '11 at 20:20
@Kris: "on occasion individuals within the team no longer feel rewarded in the way they used to". Correct. That's because things have changed. You might want to consider that a long explanation to me (a total stranger) may not be as helpful as a long, in-depth discussion with the actual people having the actual problem. "Individuals and interactions over processes and tools". Talk to them. What don't they like? Fix what they want fixed. If they want to do away with "Agile", then do away with Agile and make them produce strict schedules. Continue to permit change to the schedule. –  S.Lott Jun 1 '11 at 20:31
@S.Lott: Yep, agree completely - have spent time (a lot of time) with the people to understand how they feel. In many cases, they see the system working better for the majority now, and they see the benefits; they don't see that it needs to be fixed. They just might not see their place in it any more. If the right thing for someone is to work somewhere else, sad as it makes me, I'll support them. I guess I'm looking for insight in to how others have adjusted, what new or different things motivate them, so we have a few more tools to work with. (Thanks for the time and answer btw, appreciated.) –  Kris Jun 1 '11 at 21:07
show 4 more comments

my company attempted (and still attempting after years of trying) to do the same transition and so far personally, I haven't seen much success with it. During this transition, I did a whole lot of reading up on agile development and different ways/aspects/concerns/techniques and one thing I strongly agree with is that pure agile development is best suited when entire team consists of senior, high-quality people (or at least all people of the same level).

Last release I was on an "agile" team that had IMHO too many developers with skill levels all over the place and we attempted to get everyone involved in the same project. It was a disaster. We did more talking/arguing than work, and in the end what the team produced was an average work (read Peopleware or Mythical Man Month about taking average). Forget about design patterns, forget about low coupling or breaking code into small classes and methods. Forget about trying to make anything interesting because a) that couldn't be explained and understood by all team members (at least not in timely fashion) and b) since we were agile, whatever I started this iteration, someone else with absolutely no understanding would continue in the next iteration. Personally, I just gave up and simply waited for scrum or whoever to assign me tasks, did them, went home and coded my own personal projects.

I absolutely hated the fact that I couldn't do anything with C++ templates, or write some cool (but somewhat complex) low-level framework libraries which would have made our lives so much easier. How can something like that be done when no one else on the team is even capable of reading STL header files but we are all supposed to be working on one thing at a time. Entire project ended up being brute-forced feature by feature because that's what agile seems to emphasize.

At the same time, there are few (very few) people in my company that I would absolutely love to work with side by side and share all of my code.

But now you face a choice. A) Take all your good, senior developers who produce high-quality code and put them into their own team and put the rest into a separate team. Or B) attempt to balance out teams and put good ones with not so good ones. In (A) the problem is that one of your teams will be way underperforming and won't pick up good skills/habits from the good guys. In (B) your good guys (in pure agile environment) will feel frustrated and will start working on their resumes. Mine is up-to-date.

So what are you to do?

I do not know if this is the right solution. Ask me again in about a year or so. But what if instead of "pure agile" you formed a team, but clearly identified which person(s) has more influence (design, code reviews...) and make sure that person understands that and is rewarded for extra responsibility. As the team members start working together, identify those that are picking up good habits/practices and elevate them to the same level as your good people. Hopefully as people spend a release or two working together, they will learn what the other person thinking and how they work, so they'll be more compatible to work in the same code at the same time. But until that happens, if you just throw people into a project, it'll be nothing but frustration (again, just my opinion). This way if senior guys have to work with less experienced ones, at least they have more weight (not dictatorship, just more weight) in decision making.

Some of my thoughts are based on how I started professionally in software. When I was a co-op I worked with a guy who was my mentor. He taught me everything from coding ethics to good design to reading thousands upon thousands of lines of code you didn't write. In the beginning we were nowhere near on the same level and it would be laughable if we were placed in an agile team and told that we can work on each others code. But over time (few years), we started thinking very much alike. I could understand his code with a simple glance and he told me multiple times that he had absolutely no problems (and was suprised by that) navigating my code that he has never seen before. This took years, not something that happened over night. After experiencing disaster after disaster in agile environment in the last few years, I would jump in a heartbeat at the chance to work together with that guy in an agile team

This is not really an answer but it sums up my experience/observations. I do want to see what others would say about this.

share|improve this answer
add comment

What is Agile?

Is it:

  • a set of rules that you must follow to achieve what the rule-setters intended?

  • a best-guess approach for getting things done within your particular strengths, requirements and limitations?

If you think Agile is the first, and you always follow each and every one of the Scrum rules and worry constantly whether you're doing it right or not, perhaps this link will enlighten you a little.

If you think its more about the second, then congratulations - you 'get' Agile. Any Agile methodology can only be a suggestion of how to go about getting things done. If any aspect of your chosen agile method doesn't feel right to you, then you have the duty to stop using it, change it or otherwise be agile about it. What's important is that you achieve something, that you're not held back by artificial constraints - not just the ones that we all know and love from our old waterfall days where the PM would hassle you for full documented diagrams that no-one would ever read just because "that's what the process says to do", but also from the constraints of whateve it is you're using. If a daily scrum feels like its a constraint then don't blinking have them! To blindly have them because the rules say so is no more agile than the old ways.

Now if you have some guys that get things done by being locked in a room with only a gallon of cola and a hatch for pizza, then utilise that fact. Give them some part of the system that is mostly self-contained and lock them away. When they're done, then you should get them to integrate that work (or get someone else to do that if they prefer it) with the rest of the system.

Alistair Cockburn described this in his methods. If you have "level 3 practitioners", then a perfectly valid agile method is as follows:


As you have a mix of people, you need to work out a way to get them to work constructively together, and that means a 1-size fits all approach probably isn't going to be very efficient. So you need to divide the tasks up, all the while ensuring that the common goal is emphasised. Its ok to send those guys off to code, but they have to be made aware of how their stuff will be an integral part of the rest of the team's work and that failing to achieve that is a failure of whatever it is they're producing. Once they understand that (ie they cannot just do whatever they feel like and deliver something unusable) then your job's done.

share|improve this answer
add comment

Let say agile is not for everybody and agile is not for every project. In the same time agile is very broad term and Scrum is only one implementation of an agile process - I can somehow say the implementation with probably the most constraints which tries to set up standardized process with well known steps.

Another area to think about is what is the purpose of agile? Is agile about the way how developers work? Perhaps - some methodologies indeed go that direction. But agile itself covers areas outside of the development. Agile is more about driving the whole process, the way how an interaction works, the way how you delivery the working product with the most important features on time and the way how you control resources, how you see where in the project you currently are, etc.

There are methodologies which doesn't try to change anything from your development process - Scrum is not the one. All agile methodologies emphasize continuous improvement. You will detect some inefficient step in your process and you will try to improve it / change it - that is the agile way. Check another popular agile methodology - Kanban.

You / Your company have decided to use Scrum and it can lead to fact that some people will not like it and leave. You should deal with each one of your developers separately. You should talk about that with each one and you should try to find some interests which would allow them enjoying the work again.

They can have role of mentors, they can teach others, show them how to refactor code to better architecture when working iteratively. They can form together some global architecture blueprint use across projects. They can also work on proof of concepts, participate in RFI (request for information) when customers make enquiries to think about feasibility of requirements. They can work in pairs with less skilled developers and do the complex task together, etc. Their main value should be in using their skills and allow others learning from them.

Scrum and agile globally indeed somehow keep down individuals and prioritize teams - teams deliver application, not individuals. This idea is based on the fact that you will never have a team where everybody have same skill set and experience.

If your transition to Scrum will be successful they should see that the overall process has improved, delivery times were reduced, quality has improved and customers are more satisfied. They can still believe that developed applications themselves are much worse then they could be but that is the point - customer doesn't want the best code ever written. Customers want the minimal / the cheapest / the fastest developed working code which satisfies their requirements. If brute force is enough for that then be it. This is something that can cause problems to high skilled developers but it is not failure of agile, it the place where business demands and perfectionism go against each other.

share|improve this answer
add comment

It will benefit the entire team if you take some of the major problems and hand them off to a great developer. Everyone can get up-to-speed afterwards and learn something in the process. Just don't build an entire application this way.

You don't water-down the code to the lowest common denominator. You make the inexperienced catch up to the better developers.

share|improve this answer
add comment

There's been a lot of discussion about what is or is not "agile" and a lot of personal feelings, experiences, and misgivings about the agile process shared here, but I haven't really seen an actual answer to the question. The original question was how to keep your top developers motivated when they see their code that they've written at the level of pure artform, and invested their sweat and blood into, hacked around by someone else and "corrupted". Note that, agile or not, this is going to happen at some point, it's just more visible now because they're still working on the code at the same time as others, instead of there being the typical handoff to support, at which point they just wouldn't see those changes being made.

What I would see as the key here is to expand the responsibility of these developers and help them change their focus to the bigger picture. Maybe that means a new title, like Software Architect, or Team Lead, or Senior Software Engineer. Then show them that this is an opportunity to have a greater impact, not just on a single project at a time, but across multiple projects. The sense of ownership can still be there, but their focus should no longer be on delivering a single great project, but on helping to set the bar for ALL projects. Help them key in on their strong desire to build something great, but shift the focus to building up your company's software engineering practices, and the other developers. Instead of cringing at the thought of their coworkers hacking their code to pieces, this can be a chance for them to step up to the next level and mentor their teammates and bring them up to their level.

share|improve this answer
Hi - my intent was not related to seeing one's code hacked about by the rest of the team. I have seen the "What have you done to my code!! Aargh!" thing a few times, in waterfall and in agile, but that's a different issue. It's about people that find they aren't able to take a piece of work and work independently to finish it. –  Kris Jun 1 '11 at 20:26
Ok, my answer may have been tempered somewhat by the discussion taking place here, but if these are capable people who are feeling a lack of ownership now, I think it's still valid to help them change their focus to something else they can have ownership of and still be major contributors to the team. –  Joel C Jun 1 '11 at 20:38
add comment
extended period of time

It sounds like they are "Lone Rangers". In the canonical Scrum, these people just can't fit the Team (they miss the "interaction" bit).

If they are not "Lone Rangers", then there is hope. If you're doing Scrum properly they must be part of the design of the feature they will be working on (during the Sprint Planning). This is about the only time they need to interact with others. You can even "assign" all the stories related to that one feature to them.

During the Sprint, they will only be "bothered" by the daily Scrum... until you can prove them (by actions, not by words) that it will be just 15 minutes of their time, and only to guarantee that everything is running smoothly. Keep close to the three questions and most people will stop complying.

On our team, we have a special group just for performance enhancements. We don't see them very much, just at the start of the sprint to talk about the changes to be made, and at the end in the retrospective. They have their own "scrum leader" which reports to the Scrum of Scrum team. I can tell you, they are enjoying themselves.

share|improve this answer
-1 - for assuming the exceptionally productive people are lone rangers because they don't care for the agile approach. Did you ever hear the phrases "Living up to one's potential" or "Enjoying a challenge". Perhaps they miss that while practicing the agile approach. –  Dunk Jun 22 '11 at 18:11
I didn't assume that. My bell was triggered by "with only minimal interaction with others" which is the definition of a Lone Ranger. Sometimes Lone Ranger are like that because they like it that way. There is a place for them but that place is not in an Agile (The "Interaction over Process" thing) team. Sometimes, Lone Rangers are like that because they dislike the politics, PM "practices" and burocracy that just rob all fun from programming. In that case, changing the environment the way agile tries to do will change them from being Lone Rangers to enjoy themselves in the team. –  Soronthar Jun 27 '11 at 18:03
add comment

The rules for an agile team should be customized to fit the team -- this can be really personal customization; For example, I worked on a team where the rule was:

All Code must be written by a pair, except David may write code alone.

David was a senior developer/architect, who worked primarily on tooling that others would use in their own code. He very much owned the code that he wrote. It was maintainable and tested, and everyone on the team knew that he was probably the best coder there, and that the team would be served best by letting him build certain framework pieces and present them as complete to the team.

I don't have an answer for garden variety introverts, but for exceptional introverts, the team will happily take different rules to get the benefit.

share|improve this answer
Reminds me of a dress code at one company back in my antediluvian days. Marketing staff insisted that developers had to have a dress code because marketroids sometimes wanted to show the development area to customers. Helpfully the bosses came up with a developer dress code: "No developer may come to work in a dress. Except Debbie." It helps when the company is run by hackers.... –  JUST MY correct OPINION Jun 9 '11 at 15:21
add comment

Show them that it's more fun to collaborate, because then they will write better code, learn more and have less problems.

share|improve this answer
-1 - No evidence to support more fun, write better code, learn more or have less problems. –  Dunk Jun 22 '11 at 18:06
add comment

Your Answer


