It still amazes me how a process created by engineers for engineers can make so many engineers so unhappy.
Unfortunately in my experience there are really good engineers out there for whom Agile in all its manifestations, from Scrum to XP, just doesnâ€
The top four reasons why Agile doesnâ€
- You have to like to talk to people. Engineering as a profession self-selects for people who find human-machine interactions more interesting then human-human or human-animal interactions. People who like to talk to people become salesmen or lawyers not programmers. But for some engineers human-human interaction is down right painful. If you are not into face-to-face communication Agile is not for you.
- You have to need and accept help. I love to remind people that intelligence is a side effect of evolution not its goal. (The gold of evolution, if there is one, to enable a species to adapt to a changing environment. Intelligence is just one experiment in adaptation and probably not the most successful one since itâ€
s only worked for one species.) Iâ€ ve found that some really intelligent engineers are so smart that itâ€ s difficult for them to accept help (like a prioritized backlog or a bug report) from people they view as obviously less intelligent. You can call this arrogance but then would Mozart have accepted help on his symphonies?
- You have to embrace change. Many people from all walks of life have difficulty handling changeâ€”rapid or slow. They just donâ€
t like the idea that the world they have finally gotten used to and mastered no longer exists. Some of these change-adverse people happen to be engineers. You can spot them easily. They are programming in languages and paradigms that are no longer on the leading edge. I often have to say to them: Yes, you can still write desktop applications but nobody under 40 is going to care.
- You have to like focusing and working on a schedule. Whether your sprint in two weeks or two months isnâ€
t important. What is important is that you stick to itâ€”even it means, and it usually does, modifying your work to fit the time window. For the Agile-challenged engineer this is a blasphemy akin to chopping eight inches off the left side of the Mona Lisa. They see their software as a whole that isnâ€ t finished until it is finished. Scrumâ€ s timing boxing technique is admittedly arbitrary. The creative process cannot be bounded by deadlines without losing its integrity. At least thatâ€ s their argument. I see it differently, and can give lots of contrary arguments, but rational argument has little impact on personal preferences. These engineers find sprinting to be stressful where the Agile-friendly engineer finds sprinting to be liberating.
At the end of the day itâ€
The first thing to do is get them out of Agile. These engineers are wasted on Scrum and will simply quit and make a lot of other miserable on their way out. Smart unhappy people can make a lot of mischief!
The second thing to do is to create a lab, give them a mission, and turn them lose. Itâ€
In the end the secret to managing the de-motivated is finding a place for them in the organization where they are motivated to be. Agile is great but it cannot be applied to all problems.