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

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 2

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 3

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 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

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 7

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 8

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 9

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.

Answer 10

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