Shifting and Stretching the Specialist


Yesterday I described one of the more pronounced side effects of transformation to agile organization, that is, generalization of the specialist. In today's post I'll present two remedies that makes such transition easier and less painful for programmers. I've seen it at Zemanta and I've seen it at several other places, too, that an organization transforms itself to agile only to find out that it's product development process is flawed. It makes no business sense to try building the product right if what you're building is not the right product. And if you're team feels that it's building the right product with real user adoption, it will be much easier for them to adapt themselves to do different things or to do things differently. Therefore, I'd really recommend to start transformation to agile with the definition of product development process and roles, and with the product roadmap and backlog in place.

The second remedy I'd recommend for easier generalization of a specialist is to start encouraging people to take more responsibility for their work already today, that is, before starting with transition to agile. So instead of having a programmer doing only coding, encourage him to take responsibility also for design, quality assurance, and operation of his code. Even a guy fresh out of college is capable of coming with design for some part of the system, if he's only allowed to do it by his more senior colleagues. And if you put continuous deployment in place, quality assurance will no longer be someone else's business. Similarly, if the developer is called late at night to fix his malfunctioned code in production, he will never again just throw the code over to operations people. And once you manage to stretch person's scope of work outside of pure coding, it will be much easier to get him involved with product discovery or customer support, too.

Enhanced by Zemanta