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?

  • 7
    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.
    – Nobody
    Commented Jun 1, 2011 at 15:04
  • Show them that it's more fun to collaborate, because then they will write better code, learn more and have less problems.
    – user28662
    Commented Jun 22, 2011 at 15:35
  • Although the details are specfic to programming, it is a generic workplace problem of manageing change and would be better asked over at workplace.se.
    – mattnz
    Commented Jun 10, 2014 at 3:05
  • FYI, in addition to the responses below, another thing to keep in mind is that agile doesn't mean you can't ship Facebook or WhatsApp. It means "how" you ship is different, but individuals can own large pieces. For example, in one case, I owned a large deployment system, and our ship milestone was every two weeks. Shipping and process should not have an impact on feature design, development and release, etc. (except for of course, the mechanics).
    – Omer Iqbal
    Commented Jun 25, 2014 at 7:22
  • I'm one of these type of developers.. Sadly it's now 8 years since this question was asked, Scrum has completely taken over the landscape and I've never learned to like it.... it makes me miserable. Now, how long until I can retire... hmm..
    – Benj
    Commented Mar 5, 2020 at 8:47

11 Answers 11


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.

  • 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
    Commented Jun 1, 2011 at 21:28
  • 4
    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
    Commented Jun 2, 2011 at 11:03
  • Also, take great care to keep everyone engaged and communicating with each other, even if a few members are working on trailblazing. Examples: everyone attend the daily and planning meetings; the trailblazers should give an overview of their work and demo their results regularly (maybe less frequent than the Agile team, but still bi-weekly or monthly), keep the team leads informed of the impediments seen by the trailblazers (so the latter don't keep pursuing a dead-end). Disclaimer: I am exactly this kind of person and I think it can work out really well.
    – rwong
    Commented Jun 7, 2014 at 19:16
  • 1
    On the other hand, if a company's development workforce is primarily composed of trailblazers, and it is their consensus that they won't adapt to an Agile development style, then maybe this workforce will have much difficulty adopting Agile development practice. Other approaches need to be sought. As trailblazers love experimentation, new hires need to be brought in to take care of the productization needs so that the company can monetize its R&D.
    – rwong
    Commented Jun 7, 2014 at 19:19

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.

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

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.

  • 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
    Commented Jun 1, 2011 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
    Commented Jun 1, 2011 at 20:20
  • 1
    @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
    Commented Jun 1, 2011 at 20:31
  • 1
    @Kris: "they don't see that it needs to be fixed. They just might not see their place in it any more". That's contradictory. That sure sounds like two parallel monologues: they have serious problems and management is telling them that their complaints don't fit the overall organizational objectives. That sounds like no part of the Agile manifesto has been read or understood by either party. They're not really "interacting". The disgruntled aren't aren't allowed to propose a fix. So they don't see that it can be fixed.
    – S.Lott
    Commented Jun 1, 2011 at 21:11
  • 1
    Big +1 for "It doesn't say force people to work in a way that's uncomfortable and unproductive." One of the reasons I shy from all methodologies -- especially when they get popular to the point of being fashionable -- is precisely the cookie-cutter mentality they almost invariably seem to engender in those who implement them. Commented Jun 9, 2011 at 15:14

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.

  • 3
    Commenters: comments are meant for seeking clarification, not for extended discussion. If you have a solution, leave an answer. If your solution is already posted, please upvote it. If you'd like to discuss this question with others, please use chat. See the FAQ for more information.
    – user8
    Commented Jun 1, 2011 at 19:46

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:

“Put 4-6 people in a room with workstations and whiteboards and access to the users. Have them deliver running, tested software to the users every one or two months, and otherwise leave them alone.”

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.

  • "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." I 100% agree with this. Common sense as it is, I find very few people who are willing to let go of their standup meetings, however useless they may be. Commented Dec 14, 2019 at 21:09

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.


I will try to illustrate some aspects that have not been addressed by other answers and that, IMO, are important.

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.

This kind of developers may find it difficult to adapt to an agile environment and their attitude is often dismissed as "unwillingness to change", possibly related to ego or to being old-fashioned.

What is often ignored is that in order to solve complex problems one needs to handle a lot of information, and that this may need a lot of analysis, thinking, trying, sketching a solution, throwing it away, trying another one. Such a complex problem may require from a few hours to a few weeks of focused work until you have a finished solution.

One approach is that a developer takes the problem specification, goes to her room, and comes back two / three weeks later with a solution. At any time (when needed), the developer can initiate some interaction with other members of the team or with stakeholders (asking questions on specific issues) but most of the work gets done by the developer who is assigned the task.

What happens in an agile scenario? The team breaks up the problem into small chunks (user stories) after a quick analysis (grooming). The hope is that the user stories are independent from each other but often this is not the case: in order to break up a complex problem into really independent chunks you would need a knowledge that you normally only get after working on it for several days. In other words, if you are able to break up a complex problem into small independent parts, it means you have basically solved it already and that you only have diligence work left. For a problem that requires, say, three weeks work, this will probably be the case during the second week, not after a couple of hours grooming done at the very beginning of the sprint.

So, after a sprint has been planned, the team works on different chunks of a problem that have probably dependences between each other. This generates a lot of communication overhead trying to integrate different solutions that may be equally good but are, well, different from each other. Basically, the trial-and-error work is distributed over all the team members involved, with an additional communication overhead (increasing quadratically). I think some of these problems are illustrated very well in this article by Paul Graham, in particular point 7.

Of course, sharing the work between team members reduces the risk related to one team member leaving the project. On the other hand, knowledge about the code can be communicated in other ways, e.g. using code reviews or giving technical presentations to the colleagues. In this respect, I do not think there is a silver bullet valid for all situations: shared code ownership and pair programming are not the only option.

Furthermore, "delivery of working functionality within shorter intervals" results in an interruption of the work flow. This may be OK if the chunk of functionality is "add a cancel button in the login page" that can be completed by the end of a sprint, but when you are working on a complex task you do not want such interruptions: it is like trying to drive a car 100 km as fast as you can and stopping every 5 minutes to check how far you have gotten. This is only going to slow you down.

Of course, having frequent checkpoints is meant to make a project more predictable, but in some cases the interruption can be very frustrating: one can barely gain speed that it is already time to stop and present something.

So, I do not think that the attitude described in the question is related only to ego or resistance to change. It can also be that some developers consider the approach to problem-solving described above more effective because it allows them to have a better understanding of the problems they are solving and of the code they are writing. Forcing such developers to work in a different way can result in cutting down their productivity.

Also, I do not think that having some members of the team work in isolation on specific, difficult problems is against agile values. After all, teams should be self-organizing and use the process that they have found to be the most effective over the years.

Just my 2 cents.


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.


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.

  • 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
    Commented Jun 1, 2011 at 20:26
  • 1
    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
    Commented Jun 1, 2011 at 20:38
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

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.

  • 3
    -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
    Commented Jun 22, 2011 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
    Commented Jun 27, 2011 at 18:03

If Joe (your Hero developer) is a bit flexible, then I don't see a problem:

As said above, let the team self-organize: If some problems are best tackled by letting Joe chew on it by himself, then you would expect an open-minded self-organizing team to reach that conclusion on their own.

The only challenges that remain within the few constraints that Scrum imposes:

  1. Delivering functionality at regular intervals: If you let Joe chew on a problem for months, with nothing to show until the very end, then Joe is indeed not agile: He is taking the product owner hostage and not allowing him an opportunity to re-spec that part of the product. With this practice there is also a risk that he is running late, and nobody is noticing it. (But according to your description that is not so likely). Remedy: Would it be too much to ask from Joe, to sit together with the PO, break up the user story and agree on intermediate deliverables, preferably (but not necessarily) with user value?

  2. Honoring the priorities set by the product owner: If pieces of code are owned by experts, then you risk a situation where the evolution of the product is determined by the availability of each expert, rather than the commercial priorities: The rest of the team might be working on less important features, whereas the top 3 features are stalling because "only Joe can do it". That's bad. At that moment, the team should (temporarily) change their habit and divide the Joe work over more team members.

In short: If Joe, the hero-developer, agrees with the PO how he will show progress each sprint, then the team can assign certain stories to him and leave him alone. But if PO has too much work for Joe, and not enough for the team (or vice-versa), then Joe and the team have to adapt, not the PO.

  • Also the team may have to ask themselves if there is a skills shortage on the team, when considering that Joe is only "partially available" to the team.
    – rwong
    Commented Jun 25, 2014 at 7:18

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.

  • 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.... Commented Jun 9, 2011 at 15:21
  • Do you assume someone who needs some time and concentration to work on a difficult problem is an introvert? Can it not be that one needs to concentrate to work on difficult stuff and does not want to be distracted?
    – Giorgio
    Commented Jun 7, 2014 at 18:25
  • I am preparing to write my own answer, in which I highlight the criteria for performance appraisal for such "specialists in agile teams" : Instead of paying for "amassing an irreplaceable amount of knowledge", specialists shall be payed based on their "ability to raise overall (special-domain) knowledge of the whole team".
    – rwong
    Commented Jun 8, 2014 at 2:29
  • @rwong: I do not think that you need to be agile for that: any team using any kind of development process can profit from a better distribution of knowledge among the team members.
    – Giorgio
    Commented Jun 8, 2014 at 7:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.