Competencies are not roles

 

(First published on LinkedIn)

Within agile teams, generalizing specialists are valued over the specialists that permeate traditional teams - e.g. on agile teams everyone can do analysis or design on any given day - these are not activities segregated to a given person with the title of Analyst or Designer.

This lack of segregation acknowledges that competencies are not roles. But how did we come to view them as roles?

When I graduated form university  in 1978 in Computer Science and  started my first job as a programmer, we did everything – requirements, analysis, design, development, testing, and deployment.We were generalizing specialists with a bunch of different competencies. Most projects were a team of 3-5 people (or less) so the size of what we could do was often fairly small.

In the 1980’s and the 1990’s we started to move away from that model and became specialists as each of these competencies became roles and then these roles became organizational groups within IT. In the late 1980s and early 1990’s we started to add project management to that list of specialist roles.

As we became more specialized the size of projects we did (or thought we could do) grew exponentially. And so did the size of our failures as was evidenced by the various studies looking at this issue starting in the mid-1990’s.

An off-shoot of this model was that we added a lot of documents, reporting, and controls to our project and software development processes – it all became very heavy.

The Agile Manifesto in 2001 started to change all that from a software development perspective as it tried to stem the bleeding we had created with these monolithic projects and the systems they were to create by recognizing that software development was most successful when we did only what was really important, we keep things simple, and we recognized that we couldn`t know everything up front.

In many ways, Agile takes us back to our roots. On any given day on any given project, any competency can be brought to bear on the work at hand by anyone on the team. No one looks at the other person and says "well that's not your role!"

When we are born we are canvas for learning. As we grow we learn all sorts of things in all sorts of contexts; that is, we develop all sorts of competencies - some through formal education, some which seem inherent in us that we develop on our own through our  interests an hobbies, and some we learn through work. All of the competencies that we develop through whatever means are available to each of us in every context we find ourselves in - including in our work lives.

As illustrated  in the graphic at the start of this article, the people we hire show up with all kinds of  competencies - why would we want to pigeon-hole them into roles and restrict their value to us? Why would we not want all their competencies to be utilized to our collective benefit? Isn't that why we hired them in the first place?