Market Research

Your opinion, please: What are the qualities of a conference that attracts a sparkling diversity of attendees?

I'd like to gather our collective observations and apply them to increasing the variety of ideas that are brought to our conferences and the variety of people we reach with our ideas. My first practical applications will be software-oriented conferences, but I think the best suggestions may come from non-software events. Think broadly; where have you been amongst a bunch of people who differ from you, where you benefited, learned, and taught?

The question usually comes to me regarding women, but I'm interested in other kinds of diversity, too:

• interaction style
• culture
• experience level
• type of experience
• project methodology preference
• age
• outlook
• interests
• worries
• ...

So please, think about gatherings you've attended where a lot of different people harmoniously shared and challenged ideas. What gave those gatherings the opportunity to bring those people together? Once they were there, what made the space safe for them to contribute, to speak up, to risk being different?

If you don't mind, ask this question around. I'm looking for a bunch of contributions that are, well, diverse.

Lurking Under that Resistance

Some of the topics at the AgileAustin Open Space revolved around a theme. Is Agile appropriate for critical systems (medical, life-supporting software)? Can we use Agile when we have a fixed timeline and a finite budget? Will Agile work when our software supports an always-on manufacturing floor? What about when developing strategic software, breaking new business ground? Are there times when Agile is not appropriate?

I believe the conveners are primarily asking these questions as proxies. They're at the conference because they believe in Agile, but they've been asked these questions by stakeholders they need to convince. So they're looking for help in crafting their arguments.

In my experience, resistance to Agile derives from an underlying fear. That fear tends to take some mix of two forms: "I've invested my career in getting good at one way of doing things, and you want to make me obsolete," and "My rear is on the line for a lot of money. I'm not interested in risking my rear while you experiment with your touchy-feely methodology. Just deliver."

When trying to convince someone, first sussing out his concerns and then pitching your argument to address them will make you most effective.

For the fear of obsolescence, convey that, while some ways of doing things may no longer be needed, the person is still valued, and he has skills and experiences that will help the team make the transition. Give that person a clear role, an obvious place of value, and his fears and therefore resistance should relax.

To those who are inherently change-averse, you can still work to improve the feeling of safety, to make the change more palatable. There are some folks, however, whom Agile doesn't suit. Let them find jobs as SOX auditors or something.

For those who seek assurances that this crazy experiment will deliver, on time and on budget, I take two tacks. I show them burndown charts, and explain how you can clearly see, "Does this trend line look like it's going to hit the finish line when you want it to?" Burndowns are very communicative graphics; they're a great tool. Second, I ask permission to try it for a month. Just, give me two sprints. Worst case, you've lost a month, which you would have spent writing half of a Business Requirements Document. Best case, you might have a few high-value, ready-to-ship features. That's a pretty good risk-to-return ratio.

Understand what fears are hiding behind their resistance. Address those fears (usually without making direct mention of them; fear tends to turn defensive if you point out a perceived weakness). Talk in their language, using their own levers, to present your case (e.g., talk numbers to a finance person). Finally, ask for something reasonable: "You don't have to do this forever, just let us try it for a bit, and then you can decide whether to continue or adjust."

Agile Open Space: On Certifications

The AgileAustin Open Space has kicked off. I found the opening session positive, engaging, really fun to be there. I'm chuffed because I felt confident enough to suggest (convene) a few sessions. One responsibility of a convener is to capture notes from the session. This blog post is meeting that responsibility.

Y'see, one of the sessions I proposed was entitled, "Certified ScrumMaster??" I wanted to gauge people's opinions of the CSM certification: Is it valuable, is it real, or is it just résumé-padding fluff?

I got my answer. The groans, grumbles, and rolled eyes around the room confirmed my suspicions. In this crowd at least, it is worse than irrelevant. It is counter to and detrimental to the philosophy of the Agile community.

After the proceedings broke into less formal conversations, I caught up with some community members whom I respect and enjoy. They elaborated on their earlier non-verbal remarks. It is not difficult to get a CSM; you attend a two-day class. That's it. That sounds like just enough knowledge to be really dangerous.

Why do we even need certifications? What does a certificate indicate about my real skills, abilities, and past experience? No, I inherently reject any model that sets up a gate-keeper-style hierarchy to knowledge—a system that says, "We know things; you don't. Your ideas and perspectives are not as good as ours until we bless you and permit you to be one of us (and your check clears)." I don't accept religions that do this, nor governments, nor software project methodologies, for Pete's sake.

The true flaw in the CSM is the name: Certified ScrumMaster. Go to a hiring manager and ask which she'd rather have, someone with 3 years' experience as a Scrum team member, or a Certified Scrum Master [trumpet fanfare]. Those in the know, know that ScrumMaster is the role; you hear it without the space. But to those who are not yet well versed in Scrum, it sounds like Mastery of the Scrum process; they inject a space between the words.

The Training page on the Scrum Alliance website says it plain: "The journey to mastery begins with..." and "These courses [CSM and CSPO] provide a solid foundation to help you make the paradigm shift to managing a project using Scrum." [emphasis added] They state straight up that this is the starting point. But the name of the certification doesn't say that. The opportunity for misinterpretation will get people into trouble.

Why does it get my dander up? Personally, because it threatens to be Another Damn Thing I gotta do to stay in the game. Professionally, because agile projects can be magnificent, and certifications smack of the process-for-process'-sake mindset that turns software development into a tedium. Philosophically, because neophytes will incorrectly elevate the merit of opinions from a Certified ScrumMaster, no matter how little experience he may have, and dilute and muddle the tenets of Agile.

Mike Cohn the other night joked about the CSM culminating in a tattoo. I don't know, man, I might put more stock in that, if the tattoo embodied the Agile Manifesto. (Embodied—ha!) It would at least convey the right level of commitment.

Runs in the Family

I'm a language geek, but I try not to be a nit about it. I like the subtle nuances in choosing the "right" word for a situation, but not at the expense of connecting and communicating with real human beings. However, sometimes a small change in word choice can have a large impact on clarity.

In JP's Nothin' But .NET class last week, we had an object called "criteria." (He was creating a DSL for generating SQL statements. Neat stuff.) My brain kept tripping over the example, until I realized, "Oh! Your criteria is a single thing, and I'm expecting it to be a collection. Ah ha!" So I suggested a name-change to "criterion," not to be pedantic (I swear), but just to improve clarity.

A little time passed, and then a student raised the objection I was expecting. "Well, actually, Merriam-Webster's says..." I know this objection well; I've explored it, and I've read Merriam-Webster's editorial philosophy (Did you know your dictionary has an Introduction?). M-W has a descriptive focus, not prescriptive; their intent is to capture and document language usage in the wild. It's a good resource, but not when you want to know the "proper" use of a word.

Knowing this did not improve my image in the class.

Ah, well, I gotta be me. Teasing me, one student said, "Hey, you know so much about dictionaries. Do you have strong opinions on hash tables?" No... that's my dad!

Presenting to Managers

From Edward Tufte's one-day class "Presenting Data and Information," my key epiphany is this:

Your audience is not dumb; they are busy.

There's a common "wisdom" that we need to dumb-down presentations to managers, but this is a hindrance to your message.

No, instead, imagine you are really busy, and you have a lot of demands on your time and, more importantly, your attention. In that mindset, what information do you need, and presented in what order, so that you can make a decision?

As technical people, we like puzzles. We like climbing over multiple steps to discover an answer. We are at times prone to structuring our presentations this way, too: Here's a neat problem, and here are all of the things I tried before finding an answer.

This is a waste of time.

Professor Tufte's argument architecture is this:

• Problem
• Relevance (why it is relevant)
• Solution

Note that there is no time spent on how we came to the solution. Note also that there is no step for dumbing down the problem or the solution.

Your audience is smart, but busy.

Serving Kool-Aid

[From the Creating Passion, Spreading the Word session]

Tips collected from the discussion on spreading one's values into the rest of the organization...

1. To convince someone of a solution, you need to help them first see that there is a problem.
2. Pick your battles: Work on only the highest priority changes, to avoid overwhelming your audience.
3. Build credibility. Start with a small change, and let its success build your argument for the next change.
4. Start a forum where team members can share their ideas. Avoid being the lone pontificator on the mount, and instead create a lunch-n-learn atmosphere, where you can be one of many presenters.
5. Lead not through addition (adding followers), but through multiplication (creating leaders).
6. Experiment on your side projects. You'll never convince people to risk a wacky new methodology on their huge, stressful, already late, career-defining project.
7. Build relationships first. Show that you care about the team's success, that you are a member of the team, in order to build trust. One-on-one contact can convey this valued trust—I want to share this with you.
8. You've followed many steps to come to a conclusion. You need to help your audience down that path, too. Simply handing them the conclusion will not be compelling or convincing.
9. Passion may start a revolution, but persistence and perseverance are required to see it through. You may get tired of fighting, but lasting change requires more time than you think, so you have to keep fighting.
10. Remove friction to adoption. Make it easy to do the right thing.
11. Let your audience ask for "what's next?" Give them a taste of it, and then step back and wait. Let the quest for improvement become their idea.
12. Discuss ideas, not tools. Teach critical thinking.

Why Argue about Words?

[From the opening session]

Nearly as loud as the argument about changing the Alt.Net name is the camp saying "who cares what it's named?"

I don't have a problem with the Alt.Net name, and I'm past bored with the argument, but I do like showing off what I know about linguistics, to try and justify some of that expensive schooling.

The Sapir-Whorf hypothesis posits that the way we use language informs and constrains the way we think about the world: Language shapes thought. So arguing about the words we use may be not only relevant, but vital.

Many years ago I went to a play where an actor presented a monologue as if he were Buckminster Fuller. I never know how to attribute quotes from this event; I probably need to find the playwright. Anyway, this non-Bucky gave an example of how language changes our thinking. Why do we say "up" and "down," when we live on a sphere? We should say "out" and "in."

Dizzying, isn't it?

So it is important how you name your test methods, and whether you review 'defects' or 'items', ...and what you call your social movement.

But debate about it later on blogs. While we're all here, let's talk about code, man.

BDD without Friction?

[From the Behavior-Driven Development session]

I could not discern a clear why from this session. Despite that, I think I agree with the tenets of capturing user stories using business-y language and executable code, at least to give your project an executable to-do list.

The debate swirled around whether codifying user stories was better than note cards, should replace note cards, or was just a way to translate human language into something developers could understand (which left me wondering what species developers are, then). I can't speak to BDD's relative merits, but I know a thing or two about having conversations with humans.

Above all, we want to avoid the scenario where the business user says they've changed their mind (their process, their requirements...), and we roll our eyes. We express frustration with their so-called indecisiveness because we're mentally translating that into a big pile of work. A note card has nothing invested in it—throw it away! whatever—but code, a test, a requirements doc, these things all introduce overhead. Overhead = friction = resistance to change = not building the highest priority thing. Your strategic advantage hinges on your ability to change.

Where is the middle ground here?

Because I can surmise benefits in favor of BDD. I love automated unit tests and the confidence they give me to refactor and create code with speed. I'm not alone in hating the maintenance of requirements docs, so they invariably become out-of-date and worse than useless. Executable requirements sound like an appealing alternative. Thinking in the business domain while coding, bringing code and user needs closer together, sound like important contributors to success. I get the impression that BDD brings a change in paradigm that is too subtle to explain to someone not experiencing it, but profound in the way it overhauls your perspective. But I just don't know yet.

Beginners, Speak Out

[From the Creating Passion session]

Beginners to a given topic (TDD, BDD, NHibernate, whatever) should recognize the value of their own voices on that topic.

Brad from University of Phoenix complimented Jean-Paul on the quality of one of his webcasts, but lamented that it was at such a high level. We need a more introductory overview of the concepts. I would suggest to Brad (if I could get a word in edgewise, but that's my own problem) that Brad should make such a webcast.

Those who have just learned a concept, or are exploring and actively learning a new concept, are uniquely qualified to explain it to other beginners. You're close to and you still remember what was challenging about learning it, and what concepts you needed presented to you in what order.

As someone else in the session mentioned, when you are well versed in a philosophy, are a believer in a concept, you followed many steps to reach those conclusions. When you are teaching someone else, you can't present the final synopsis and expect them to ingest it and agree. You need to lead them down the same path.

Those who have most recently walked that path have the best memory of the steps, twists and turns, and points of interest. Beginners have a valuable perspective, and should feel encouraged to toss their voices into the fray. I am reminding myself in this as much as anyone else.

Ladies Night at the Dev Con

Attended the kick-off and agenda-setting of the Alt.Net conference this evening, and I'm already enthusiastic. The guest list is such a who's-who of the development community, there are many topics I'm looking forward to, and the Open Spaces format affords interesting social observations.

I'm the only woman, out of 100+ attendees. I'm relatively used to these ratios—when you're a developer, a rock climber, and a sci-fi geek, you spend a lot of time with boys—but I'm still puzzled as to why. This evening was unusual because someone actually commented on the imbalance; it's usually the Awkward Unstated Obviousness that seems too gauche to acknowledge.

I've been formulating some guesses about why there are so few women at software conferences. Do you have any ideas?

1. This was only the kick-off. Two or three more may show up tomorrow. This doesn't really change the point, though.
   
2. The programmer community is not as gender-balanced as I had thought. The multitudes of women around my workplace are actually managers, project managers, business analysts, test leads, dev leads, and administrative assistants.
3. Women don't hear about the conferences. (I'm only starting to tap into the info channels, myself.)
4. Women feel less entitled to ask their employers to fly them to an expensive conference. (Although this one is free. But, in general.)
5. It takes courage to jump in and be the only girl. When all of a conference's featured speakers are men, you know most of the attendees will be, too. (I was heartened to see Wendy Friedlander on the organizers list of Alt.Net; I hope I get to meet her.)
   
6. Women prioritize relationship-building over career development or skills growth, and so do other things with their weekends.
7. A roomful of men can be tiresome. They shout a lot, often fruitlessly and without seeming to listen to anyone else.
8. Math is hard.
   

One nice thing about being a programmer: I can go to a large event and not have a line for the bathroom.

I don't blame the men. If anything, they are guilty only of being men. I always find them to be polite and inclusive. When they're shouty, it's because it's their nature to be shouty, and you need to shout right along with them (They like that.), or communicate with your own quiet confidence (They'll listen.). You don't have to be like a man to hang out with men. You don't have to be like a girl, either. You can just be a developer, be a thinking person with ideas, be yourself.

But you have to show up.