Reconsidering Pragmatic Agility

Posted by Keith McMillan

November 18, 2011 | Leave a Comment

I consider myself fairly pragmatic when it comes to agility in software development, or at least I used to… I’m having second thoughts.  As long as I’ve been around agile development (it’s been, what 6 or 7 years…) I’ve been exposed to what some people call Agilistas.  You probably recognize what I mean if you’ve met one: they refer to principal thinkers in the field by first name, and have a tendency to absolutist statements like “there are no project managers in agile, we don’t need them.”  I’m beginning to think they may have a point, just not the one they think they have.

I used to think that the way that “big-A Agile” proponents behaved was counter-productive. They alienate people within the business that could be made allies, and frankly, I just believe that agile provides room for local adaption (requires it, in fact).   But having been knocked around for a while now, I’ve begun to see a dark side to pragmatism.

It might be easiest to consider an example: what kinds of jobs are there on a Scrum team?  The Agilist answer is “Product Owner, Team Member, Scrum Master. There are no other roles.”   The intent here is to have a cross-functional team, and to decrease the number of hand-offs, administrative burden and all that.  These are good goals.

I used to counter that while having everyone capable of every task is a noble goal, in reality there are experts in particular fields. I’m a security guy, because that’s were my interests, experience and training lie.  That’s not all I can do (by a long shot), I can do requirements work, coding, database work, testing, and security work, just don’t ask me to design an award winning user interface.  The point is, I don’t expect that everyone on a team have an in-depth understanding of public key cryptography and how it relates to HTTPS communication: I can provide the in depth knowledge required.  Perhaps here I’m drawing a distinction I once heard as the difference between “expert” and “specialist,” the latter being someone who works exclusively in their area of expertise.  I don’t think the world at large shares my appreciation of the nuance.

What I’ve seen however is a tendency to exploit my pragmatism (my recognition that there are experts in various fields) by assigning people in traditional specialist roles (I’ll pick on “testing specialist”) to a team as a “team member,” but then not expect that they have a broader set of skills, or that the rest of the team do the things a test specialist traditionally do.  Once in this situation, the specialists seem to have a tendency to guard their own turf as well, so even if other members of the team want to expand their responsibilities, they get push back.

So maybe the Agilistas have a point: perhaps having an absolutist position puts us in better shape to achieve agile goals. Perhaps stating that “we don’t have test specialists,” while abrasive, sets out our position clearly.  Maybe my pragmatic admission of the possibility of specialization of skills starts us down a slippery slope to where we came from: hand-offs, specialists, and all that comes with it.

I had believed that the Agilistas’ point was that everyone should be able to do everything on a team: I still don’t think that’s reality, but perhaps that wasn’t the point at all. If I reconsider the point to be “we should have teams that are broadly cross-functional, where there are no specialists, but experts as required,” it’s something I do actually believe in.  But it’s much harder to convey that point than to say “we don’t have testers on a Scrum team.”

What are your thoughts?


RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.