Generalization of the Specialist

One of the most pronounced side effects of an engineering organization transforming itself to agile, is the generalization of the specialist. In most engineering organizations engineers are handled with great care. Even so much, that product priorities are adjusted to fit the needs and whims of engineers. The priorities defined by engineers are usually quite different than priorities of customers and when an organization becomes agile development priorities almost always change. And they keep on changing as the product discovery keeps on unearthing different pain points the users are having with your product. Consequently, a programmer is forced to get acquainted with all the systems in place and all technologies used, but with all of them, only in passing. In a true agile, there's  no place for people interested only in one type of technology or just a part of the system.

In addition to frequent shifts in product priorities, agile programmers are expected to do not only coding, but also testing, system administration, planning, designing, interviewing users, and making many other decisions outside of their core technical expertise. These people, who build their identify and self-esteem upon their technical knowledge and skills, consequently lose their grounds and become utterly lost. Quite many programmers have big problems abandoning their specialist status and if left to their own devices, they will at least grumble if not outrightly sabotage the transformation to agile.

Since this post is already rather large, I'll leave for next time the description of some effective remedies that makes transition from specialist to generalist easier on programmer.