Agile and the System of Professions

Added to Community

A professional writer is an amateur who didn't quit. -- Richard Bach

I've long thought that the same could be said of programmers. I for one wasn't trained to be a programmer, or a software developer, or in fact any of the titles I've held in my career of 20+ years. Neither did many of the people I worked under, looked up to as role models or learned from by observing their work.

There is, of course, one sense of "professional" that is completely straightforward and under which this definition is tautological - making a living from whatever it is you do. Thus there can be professional poker players, professional video gamers, professional tasters...

However, this is clearly not the same sense according to which one can say (as I've read in more than one place) "as a software developer, not writing unit tests is unprofessional".

This phrase, and many other signs, suggest that there is a deeper aspiration, at least within the Agile community, than to be a "professional" in the basic sense of getting paid to code.

Here are some phrases which have gazillions of hits on Google: "scrum professional" (also "professional scrum"), "agile professional". One can see offerings for "Kanban Professional training", and I'm sure diligent searching would turn up other similar examples.

One book has a section on "Hiring an agile professional". One Agile luminary, Bob Martin, is known for speaking regularly about the need for "professionalism" in software development. (In an interesting contrast, the Project Management Institute has "professional" designations for project managers, but grants only the title "Practitioner" to holders of its Agile certification.)

Professionals don't have bosses. Professionals are partners with business. They may be employed, but they are not laborers to be managed by foremen. Rather they are experts who know how best to achieve what their employers need. You hire doctors and lawyers, but you don't manage them, you aren't their boss. Imagine trying to boss your doctor as he performs open-heart surgery on you. The concept is absurd. That's the bar I want programmers to reach for. I want them to behave like lawyers, like doctors, like real professionals; not like laborers. -- Robert C. Martin

The above quote makes a direct comparison between programmers on the one hand, and on the other lawyers and doctors, two of the classic "learned professions".

So what does it mean to be a professional programmer? What does it mean to be a professional anything? Some definitions simply say to be a professional is "to make money from a skill," but true professionals also have a set of qualities often described as "professionalism." In my opinion, these qualities are [...] -- Sarah George

Many articles on "software professionalism", such as the one from which the above quote is drawn, ask the crucial question of what we even mean by the term "professional", but (as in the above quote) far too many offer little justification for their understanding of the term, other than personal opinion. Therefore, I turned to sociology for deeper insight.

The sociology of professions makes for fascinating study, and one particularly interesting book in this respect is Andrew Abbott's The System of Professions. Its take on professions aligns to some extent with what I've been writing here about "tribes".

Abbott defines a profession in deliberately loose terms, as "exclusive occupational groups applying somewhat abstract knowledge to particular cases". (Does that describe software developers?)

What is interesting to Abbott is not the identification of professions according to particular criteria (such as the ones listed in the above-linked Wikipedia page: university training, state licensing, etc.) or a particular developmental sequence. Rather, it is a "whole system" picture in which the interesting mechanisms are those whereby professions appear and disappear, encroach on one another's domains, and so on.

Abbott focuses particularly on jurisdiction, or the area of concern that a profession carves out for itself (often from territory already occupied by other professions, more rarely when disruptions due to technology or social change cause new domains to emerge). This brings Abbott to focus less on the trappings of professions, such as the organizations or associations protecting their interests, or the mechanisms of certification and licensure; and much more on the content, on the work that experts do.

As I've argued in previous posts, what is interesting about the Agile tribes is the ideas that they have custody over, ideas which are about making easier some part, big or small, of the work to be done in software development. We've seen that the Agile community, initially dominated by a few "branded" methodological approaches such as XP or Scrum, bred a number of smaller "tribes" amounting to subdivisions of the Agile movement based largely on what each claimed expertise of - what they identified as their jurisdiction.

The utility of distinguishing between the true professions and merely ‘would be’ professions can be appreciated when one looks at why so many occupations pursue the elusive status of profession. Here are the chief things that occupational groups seek when they undertake ‘professionalization’:
– Above all else, they want AUTONOMY. That is, they want freedom from supervision in carrying out their jobs;
– They want RECOGNITION based not upon the name of their employer, but upon their identity with their occupation;
– They want the POWER to determine who is ‘in’ their occupation from those who are ‘out’;
– They want to establish a MONOPOLY over a certain line of work, freeing it from influence of ‘outsiders’ (mostly employers, but also clients and the general public) who do not share or necessarily understand the ideology;
– They want the POWER to discipline wayward colleagues who deviate from their work ideology. -- W.J. Haga

The above is drawn from Paul D. Giammalvo's PhD Thesis, Is project management a profession? If yes, where does it fit in and if not, what is it? - he is quoting a William J. Haga, in Perils of professionalism (Management Quarterly, 1974). Giammalvo uses the insights from several sociologists, including Abbott, to raise - and answer - the question of whether Project Managers are "professionals". He describes Haga as an "obscure researcher", but the quote to me fits well with the spirit in which Abbott examines professions.

Someone who aligns with the values of Agile is often making an implicit claim of autonomy: "as developers, as team leaders, as Product Owners, we refuse to let our work responsibilities be dictated by what we see as outdated thinking". We are "uncovering better ways of developing software", to quote from our Manifesto.

When I accepted the Gordon Pask award in 2006, I made a little speech which embodied the desire for recognition; here is how I recalled it three years later:

Don't tell my mom I work in software, she thinks I've got a honest job as a garbage man." I didn't use those exact words, but I spoke about what happens when I run into people who are not in the software business and try to tell them what I do. It's not exactly a glamorous profession, developing software. People tell me about the horrible experiences they've had with badly written or poorly functioning software. I'm not saying that we're the most reviled profession on earth, it's probably mortgage securities traders who have that honor now in 2009. But it's not like you walk up to people at parties, tell them "I work in software development" and their eyes light up with understanding and perhaps some gratitude. So that was the important thing I wanted to hit in my speech: that what the Agile community is about, in my view, and in the long term, is transforming software into the kind of job that people view with respect and gratitude; like firemen, doctors or astronauts.

In describing the Agile community as a collection of "tribes", I have implicitly acknowledged the power/monopoly aspects; these are about deciding who is and isn't a member of the community. This is largely downplayed among the Agile tribes, who take an "inclusive" stance; this isn't without its problems and controversies. The perennial debate about certification is largely a debate about "who gets to decide whether someone Gets Agile or Doesn't Get It". The breaking away of the "kanban" tribe may have had something to do with Agile being too inclusive in the perception of that tribe's founders.

It's less clear to me than it is to people like Bob Martin that software developers should, right now, call themselves "professionals". We're still hearing way too many horror stories about buggy software, late projects, and so on. Giammalvo's thesis includes the following caution:

Much of the basis for architects and engineers claiming to be a profession is based on the legal principle of estoppel. Under estoppel, if you hold yourself out to have specialized knowledge or skills in doing something, and you fail at doing it correctly, then you are stopped or prevented from using as a defense that you didn’t actually have that knowledge or skill.

By claiming prematurely to be "professionals", we may be setting ourselves up for legal liabilities of the kind that people like Cem Kaner have been writing about.

Just as it is difficult to find a convincing history of the software professions, it is also difficult to find much analysis of where the various occupational groups in software development (developer, tester, analyst, project managers, etc.) stand as professions. (Giammalvo's thesis is a rare and therefore welcome exception.)

Yet for some years now, I've had the feeling that this analysis is crucial. Whatever the status of its "professional" claims, the Agile movement is in practice leading to a redefinition of these occupational groups. Specialties which did not exist at all a few years ago are now in hot demand with companies large and small: scrum master, product owner, Agile Coach, DevOps Engineer, etc.

Just making sense of these changes requires a conceptual framework that hasn't yet been appropriated by software practitioners, and that alone would make that research worthwhile. Beyond that, there is more at stake: steering the very future of Agile.

I claim that we cannot influence where Agile goes - whether it withers away, as some predict it will; or changes the world, as others claim; or morphs into a productive field of inquiry into the "science" of software, as I think it has the potential - if we cannot even understand how it evolved to where it is now.

 

About the Author

No bio currently available.


This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.