In This Issue
- An Agile New Year's Resolution for All of Us
- Hot Links
An Agile New Year's Resolution for All of Us
I believe that the agile community is at a crossroads: It has reached the chasm point in Geoffry Moore's technology adoption curve and is looking over the precipice. Although some techniques, such as test-first design, refactoring, and daily stand-up meetings seem to have crossed the chasm it is not clear yet whether agile methodologies -- or even the concept of agile software development in general -- is going to succeed in the long term. Clearly a critical success factor will be our ability to attract traditionalists to our way of thinking. From what I've seen over the past few months, I believe that we are struggling if not out-right failing to do so. One of our problems is that traditionalists see that many self-declared agilists only seem to talk about being agile but they don't actually live up to their lofty ideals.
A common strategy for people who are interested in learning about a topic which is new to them, in this case agile software development, is to identify and then join discussion lists regarding that topic. Sometimes people will choose to post a message along the lines of "How do I do this?" or "I don't understand X, could someone please explain it to me?" but more often than not they just choose to lurk on the lists and listen in on the conversations. Other strategies are to seek out and talk with people experienced at agile development or even to become actively involved with an agile team.
Sometimes, particularly in the case of people who are highly experienced at one or more aspects of software development, they'll even suggest ideas which they think can improve the way that agilists work. Typically, they don't realize that the issues which their suggested solution addresses are already being addressed more effectively by other agile techniques. But in some cases they have valid suggestions that we can benefit from, albeit with a bit of modification to fit in with agile approaches.
With all the talk of the importance of collaboration and communication, let alone the need to respect others and have the humility to recognize that we don't have all the answers, you'd think that we'd welcome these people with open arms. Yet that doesn't seem to be the case. A few months ago I attended a user group meeting and the person giving the presentation had some incredible insights into software development. After the presentation a bunch of us went out to a local pub where I had the opportunity to speak one-on-one with the presenter. I told him that his techniques, which had been proven in practice many times over, would be of great interest to the agile community and I invited him to share his ideas with the community. He snorted and said that he had tried to do exactly that, but had been all but banned from the discussion lists which he had joined. He said that he'd been treated so poorly by the "close-minded agilists" that he wasn't interested in even trying to get involved with us any more.
Similarly, I myself have seen abhorrent behavior occur on several of our most popular discussion forums, conferences, and user group meetings. It seems that there are several "favorite whipping boys" that are commonly attacked on agile discussion lists, regardless of experience in those topics on the part of the discussers. I'm often astounded at how stupid and incompetent management is portrayed to be, ignoring the fact that these are often very intelligent people doing the best that they can in often less-than-ideal situations. Everyone knows that the Capability Maturity Model (CMM) is the root of all evil, even though some interesting work is being done in Agile CMM and in (egads!) an Agile Maturity Model itself. The Unified Process (UP) is also commonly attacked, regardless of the numerous case studies written about how it's been instantiated in an agile manner, not to mention freely available agile versions such as the Agile Unified Process (AUP), Open Unified Process (OpenUP), and Essential Unified Process (EssUP). A lot of people on the lists "just know" that quality assurance (QA) and data management (DM) groups within organizations are simply incapable of being effective members of agile teams. It seems to me that our community has many unwarranted prejudices, prejudices that could very likely turn potential converts away from agile software development.
Truth be told, I'm no saint; I've been known to give data professionals a relatively hard time (okay, a really hard time), but at least I make a conscious attempt to understand and present the philosophies and techniques of the traditional DM community in a fair light. I think that if you spend a few moments to reflect, that you'll agree with me that you've seen, if not exhibited yourself, one or more of these common role anti-patterns:
- True Believer. Also known as the "Born Again Developer," a True Believer "just knows" that their preferred approach to development is the best one and is very happy to let everyone else know it. The True Believer rarely seems to question what they know to be right, and strangely enough often struggles to justify why it's right. A better approach is to be open-minded but skeptical at the same time, recognizing that no approach is perfect and can always be improved upon.
- Mind Reader. In the middle of a discussion a Mind Reader will state what someone else must obviously be thinking. Strangely, Mind Readers only seem to pick up on negative ideas, or at least ideas which very clearly cast the other person in a bad light. A better approach is to ask other people what they're thinking instead of guessing; in other words, actively seek to communicate with one another.
- Hypocritical Preacher. A Hypocritical Preacher says one thing yet in practice does something else. For example, it's very easy to preach about the virtues of open and honest communication, or to promote collaboration with and respect for others, but it's a completely different matter to discuss ideas with those same people when their ideas are very different from your own. It's also very easy to preach about quality, yet not so easy to fund, develop and then support an automated, end-to-end testing environment. The solution is to practice what you preach, and if you're going to preach to only do so about the things that you actually practice.
- The Spammer. Need I say more?
- Unjustified Criticizer. An Unjustified Criticizer will often criticize something without having read it, often because it's about a topic which goes against their true beliefs or because it's written by someone they have disagreed with in the past. Unjustified Criticizers are easy to identify because they provide insufficient arguments to support their criticism, in fact they often make blanket statements and then refuse to justify those statements, and rarely seem willing to share their actual experiences pertaining to the topic (usually because they have none to share). The solution is to describe your own relevant experiences and then ask them to comment on them. You might not get an answer, but at least you'll provide others with a viewpoint based on fact.
- List Dictator. List Dictators are often Hypocritical Preachers, True Believers, and/or Unjustified Criticizers who find themselves in a position of power. A List Dictator will often define exactly what can and cannot be discussed on the list, but will often choose to flaunt those rules themselves as they see fit. In the extreme, List Dictators will often ban people who they feel are dissidents instead of publicly addressing their issues in the discussion forum. By limiting the discussion, List Dictators attempt to prevent others in a discussion forum from questioning the dogma which the List Dictator wishes to focus on, thereby promoting their agenda. To be fair, one benefit provided by List Dictators is that they often thwart the effort of spammers. Unfortunately there's little that we can do about List Dictators other than to try to convince them to behave more responsibly, otherwise we need to vote with our feet and create better discussion forums.
- Unknown Poster. Unknown Posters typically have list names such as "Cyber Guy", "Agile Guru-Dude", or "Object-Data Architect". Cute nicknames, if you're a teenager living in your parent's basement, but they don't tell us who you are. Unknown Posters often seem to be True Believers who don't to have the courage to be associated with the ideas that they're espousing. The rest of us reveal who we are, and we should invite everyone within a discussion forum to do the same.
- Indifferent Specialist. An Indifferent Specialist is someone who is often very good at what they do, be it Java programming, business analysis, or database design, yet they are rarely motivated to learn about things outside of their specialty. These people often underestimate the importance of these other things and in extreme cases will choose to denigrate these topics or the people who believe in them. Statements such as "Oh, that's something the programmers do" or "We need to blame management for that, they can be so dense sometimes" are indications that someone is an Indifferent Specialist. The solution is to strive to become a generalizing specialist, someone with one or more specialties and a general knowledge of IT and the business domain that they work in.
- Backstabber. A Backstabber will criticize someone, or their ideas, but their victim doesn't know that it's happened because they weren't included in the conversation. The solution is to have the courage to involve the person that you're criticizing in the conversation so that they have an opportunity to respond: In the case of online discussion forums, explicitly copy the person on your posting if you're not sure that they're on the list. If you have a strong argument, then you shouldn't be afraid of a response, should you?
- Blamer. Blamers are often Indifferent Specialists or True Believers who are a bit too arrogant for their own good. Instead of accepting responsibility for trying to solve a problem, they instead choose to blame others for the problems. Agile teams work together collaboratively and take responsibility for the project as a whole. If there's a problem, or if something isn't working well, it our responsibility. Blamers will promote division within teams, and in discussion forums, often to promote their own political agenda. The solution is to point out that we're all in this together and need to find a solution to the challenges that we face, and not to just push them off to someone else.
