I saw a tweet this morning. I thought it was funny and witty, another sign of good things to come from Glitch.
You pinched a Crab. The crab is hurt. It’s not so much the pain of the pinching as the encroachment on the crab’s job description. (-2 mood)
It prompted me to write this post because it is very true and quite applicable to agile environments.
Success of any agile team, especially a newly forming one, depends heavily on their ability to work together collaboratively and to communicate effectively. Anything that stands in their way (like not sitting together, multitasking between projects, lack of information radiators, etc.) separates the team from potential success. One of the considerable barriers for new Agile teams is existence of explicit, specific, detailed and deeply ingrained job descriptions and job titles. It is often underestimated and overlooked as a potential problem but despite good will from fresh agile team members it can come to pinch you.
Specific job description is something people can hide behind: “I’m not going to clarify those requirements, it’s not my job”. It also provides a (somewhat false) sense of security: “I’m the only person in the team who can sing-off testing”. People can feel uneasy, after all: “Only us developers can write good code”. It can undermine equality and take focus away from the ultimate goal – delivering quality software that provides business value. It creates boundaries, promotes silos, isolation, exclusion – or at least it can in some (sadly not uncommon) situations. It appears to stand in conflict with the idea of cross-functional team.
If abandoning job descriptions (and specific titles with it) sounds risky and dangerous – perhaps it is. It certainly requires commitment, transparency and responsibility. It breaks the traditional mould, it is brave. Yet it has successfully been done before and not only in IT (where it slowly becomes less and less controversial) but also in other industries and disciplines. My favourite example is that of Ricardo Semler’s Semco:
Performing multiple roles during the crisis gave workers greater knowledge of the operations and more suggestions on how to improve the business. Reforms implemented during that time led to 65% reduction in inventories, a marked reduction in product delivery times and a product defects rate that fell to less than 1%. As the business climate improved, Semco’s revenues and profitability improved dramatically.
As of 2003, Semco had annual revenue of $212 million, from $4 million in 1982 and $35 million in 1994, with an annual growth rate of up to 40 per cent a year. It employs 3,000 workers in 2003, as opposed to 90 in 1982.–Wikipedia
In practice you rarely get to influence the company so profoundly and win the battle with HR. It is nevertheless worth remembering as a potential problem, and can be addressed early on by creating a clear vision for the team and uniting around a common goal of delivering excellent software which will hopefully prove more important than any potential encroachments.