How can we make agile enjoyable for developers that like to personally, independently own large chunks from start to finish

Question

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?

Answer 1

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

Correct.

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.