(This is part one in a series I have titled “Soft Skills in Software”, which came out of points I came up with for a panel discussion at CodeMash 2008.)

Let’s get right to the point, then we’ll unpack it. If you do not believe in what your company is doing, seriously consider finding work that you can believe in.

This was the first point in a series of observations I wrote down in preparation for a panel discussion on the topic of “talking technology to humans”. (The astute reader will have noticed that this recommendation does not directly relate with how to convey one’s thoughts on technology to others with a less-technical bent. My hope is that those shining stars will read on before posting a comment or sending me flame mail.) I put this recommendation first because introducing change in technology practices is a taxing process. Since introducing change requires so much of your energy, I’d only recommend it if you believe that your organization’s work is worth what you will expend of your emotional energy.

If you don’t think that a lack of belief in your company’s work is affecting you, I’d challenge you to try a few things:

• Ask your spouse or significant other if they think your mood and attitude toward things in general are affected by your job.
• Ask your spouse, significant other, or children if they feel like they are walking on egg shells when you get home from work because they don’t want to “set you off”. If they look uncomfortable and say “no”, that means yes, and it’s so bad they aren’t even comfortable admitting the problem to you for fear that you may erupt. I speak from experience here.
• Pay attention to how you answer the question “and what do you do for work?” the next time your are in a social context where that comes up; is your explanation apologetic or do you use a tone of sarcasm that indirectly lets the person know that you do not identify strongly with your company and/or the services it offers?
• Pay attention to how you feel on the average day as you commute to work; are there more positive days than negative days?
• Does reading this blog post incense you for reasons you can’t fully explain, and you already have a litany of reasons who people shouldn’t expect to be able to feel good about what their company does? :-)

Here’s the thing; life is short. Too short to while away most of the hours of years of your life contributing to something you don’t even agree with. Too short to have your family members’ memories of their years with you be colored with how negatively your work affected you. You don’t need the hypertension, and your loved ones don’t need the unjustified bile.

Am I saying that finding work you believe in will eliminate stress and make you some fount of perpetual positive emotional energy? Why, of course not. Work is going to take something out of you, but it is going to take even more out of you if you’re doing it against your conviction, without the benefit of an additional resultant gain.

Oh, and one last thing. There may be some who say, “well my company does sell anything.” Sure they do. Everyone is selling something, a service in exchange for a form of compensation. The consumer may not be the payee, but something’s being provided. Don’t let that semantic keep you from examining whether or not your employer’s work resonates with you.

I found out yesterday that Mike Cohn was going to be speaking at Agile Atlanta. Given that our AJUG meeting had fallen through, I pulled some schedule gymnastics in order to make the meeting. Don’t pass up a chance to hear Mike. Succeeding With Agile: A Guide To Transitioning And Improving will be his new book that fleshes out the principles of the talk he gave tonight; I scribbled down some notes below.

Agile Transition Planning

• Have goals in a transition backlog, to help you figure out how you’re doing on those goals and what you can do to assist those goals.
• Set quarterly transition goals,having those be like releases for software
• Have monthly iterations where you talk about what you can do
• Have weekly meetings talking about how you can do it
• Establish a “guiding coalition” that includes a sponsor and area managers who can help ensure success

Establish transition teams, they’re pursuing the tactical elements of some of your goals; some will be organic, some will have been formally established. Organic tends to be preferred; these will have the internal motivation necessary to get the most out of Agile.

Transition Team Members

Who to include

• Be aware of power distribution
• Know where expertise and credibility lies; passion alone does not a team member make
• Know who benefits and who loses from this
• Know what groups might have a tendency to resist this and/or may align to blockade this as an allied force; strategic inclusion can defuse this

Who to exclude

• Avoid “snipers”
• Avoid big egos
• Avoid snakes who poison relationships
• Avoid conscripts

Leading an Agile Transition

Transition team and other formal leaders must lead the transition, but not in the way they may have in the past.

Prerequisites of Self-Organization

• Container – boundaries along which people align
• Differences – enough difference to provide a vibrance
• Transforming Exchanges – interaction meaningful enough to provide value to participants

NOTE: I have had to tweak this via changes to agile team organization

Patterns of Agile Adoption

• Technical Practices First – high impact, does not scale well, partial adoption is risky
• Iterative First – not as controversial, but teams can get very complacent, scales relatively well
• Requirements First – if you’re there, OK, but meh; wait for the right project?
• Start Small – has been de facto, but less so these days, cheaper, good for those on the fence as to whether to commit, it’s slow
• All In – it’s over quickly, no organizational dissonance of having two systems at once, risky, costly, usually requires a reorganization
• Stealth Mode – no additional pressure, no one knows until you tell, no one can say no, no organizational support
• Public Display of Agility – over the top, can reduce resistance, obvious need for organizational support
• Impending Doom – can shock team out of complacency, admitting pending disaster can free team to experiment, can help overcome resistance, transition can be quick, not always an option, big change in time of trouble can increase stress

Patterns of Agile Expansion

• Split and Seed – split team up, add in newcomers
• Grow and Split – get team big then split
• Internal Coaching – develop team, give team members additional responsibilities to coach other teams

Addressing Resistance

• Sell the problem, not the solution
• Understand the types of resistance you are encountering and address them in appropriate ways

So tomorrow I fly out to Cleveland for the 1-hour ride to Sandusky, Ohio for CodeMash. The first CodeMash ever took place last year, and I was very glad to have been a part of it. I had intended to submit proposed talks for this year, but alas my schedule was already a bit full and I honestly lacked the energy to put together the topics I would have wanted to present. I cannot wait to be there, several of my colleagues from Bruce Eckel’s OpenSpace conferences will be attending.

One benefit of being an independent consultant is that I am able to choose the conferences I attend without having to justify it to some management or department head. Most of the things I choose to attend would probably not be approved by an organization that insists on being able to directly relate the entirety of a conference’s content of focus to the attendee’s daily tasks. Still, there are numerous conferences throughout the year that appeal to me, and I can only afford to be unbillable for a certain number of weeks out of the year. CodeMash makes my shortlist, and here are a few reasons:

• CodeMash is a multi-language conference. There’s a breadth of exposure and a cross-pollenation of ideas that are simply not available at single-language events.
• The attendees drawn to such events are typically more open-minded about software development approaches and the fact that there is no “one way” or “one language” for anything.
• The speakers drawn to this type of conference tend to have a perspective that is broader and more in touch with software development realities than insisting on foisting some delusional monocultural vision for their language/platform/tool of choice.
• There’s a strong OpenSpace element to CodeMash, and I have experienced first-hand how amazing and energizing it can be.

So, that is why I am going to CodeMash. Looking forward to sharing my experience with my readers, all three of them.

So tonight I finally received the PayPal info to get registration set up for AJUG’s Open Space event “The Practice of Java in Atlanta“. I am looking forward to facilitating this event; the rich pool of Java talent in Atlanta should make for a passionate, dynamic group to hold conversations about Java and where it’s going. If you’re going to be in town, I can assure you that the $75 (US) will be worthwhile.

So, for the latter half of this week I have been at CodeMash in Sandusky, Ohio. It has been one of the best conferences with traditional-style presentations that I have attended for some time. We have had some remarkable Open Space sessions interspersed throughout the regular agenda. I think most of us are saving up our posts for afterward; it’s been a pretty non-stop pace. The last group I was talking with yesterday wrapped up after 1:00 AM, if that gives you any idea. This has had that same cross-platform, cross-disciplinary feel we had last March at Bruce Eckel’s Programming The New Web. Lots and lots of great stuff. I only hope I can capture a good bit of it and share.