Posted on

Balanced Professional Interest

Balanced Professional Interest

Warning: Preachy content.

In working with technical people at the individual and team levels, I often find attitudes that pull toward one extreme or the other: Either our work is inherently uninteresting, and we’re only in it for the paycheck; or our work is a boundless source of joy, learning, and achievement through which we can transcend the human condition.

Both have it partly right. But I think both are missing a thing or two.

tl;dr (Conclusion in a nutshell)

Don’t be put off when agilists seem to be demanding more of you than is reasonable. They like to use extreme language, like awesome and passionate. They really mean competent and professionally engaged. On the other hand, software work is more than “just a paycheck,” even if it’s less than “a profession” in the sense of medicine or law. You have to do more than just show up.

Extreme #1: It’s just a paycheck

Technical Coach (TC): We’re here to help improve the organization, and to help technical teams apply good practices to produce high-quality products. Are you up for it?

Software Engineer (SE): Couldn’t care less. You’ll be gone soon. You aren’t the first consultants to blow through here, you know.

TC: What about professionalism?

SE: Professionals are licensed and regulated. We don’t have letters after our names. You don’t, either. We just write code. So, stuff it!

TC: What about CSP or PMP?

SE: <tone mood=”sarcastic”>What about MD or PE?</tone>

TC: Fair enough. Even if we aren’t formally licensed, don’t you think we do better work when we approach it in a professional way, at least?

SE: <gesture type=”wave” style=”dismissive”>This is just a paycheck.</gesture> As long as I can take care of my family, I don’t care what software I write.

TC: What if they ask you to do something unethical?

SE: <gesture type=”shrug” style=”disinterested”>Not my problem.</gesture> Those decisions are above my pay grade.

TC: Did you hear about that guy at Volkswagen who got prison time for writing code to cheat emissions tests?

SE: <gesture type=”eyeroll”>This isn’t Volkswagen.</gesture>

TC: But at least you care about doing a good job on the code, right? For the sake of craft.

SE: If it’s good enough to run in production, it’s good enough. Nobody cares if it’s “clean” and all that jazz.

TC: And personal pride?

SE: Piffle (or words to that effect). Get over yourself.

TC: But at least you care if the code you write helps or hurts people, right?

SE: Pie in the sky hippie nonsense. What do I care if my work helps humanity? If I earn enough to pay my bills and feed my family, I don’t care what the software does.

TC: So, your only motivation is to make money.

SE: Right.

TC: And you don’t care how?

SE: Nah. I write software because that’s what I was trained to do. That’s all. If I were trained to do something else, then I’d do that instead.

TC: Would you change jobs if you were offered $1 a year more?

SE: In a heartbeat.

TC: And you wouldn’t care what the job was?

SE: If it pays $1 more a year, then no.

TC: So, you’d take a job as a hired killer or a human trafficker, provided you were paid $1 a year more than you are right now?

SE: We’re done here.

Extreme #2: Gotta be awesome!

Agile Coach (AC): We’re here to make the company #Agile and to make your team #Agile and to make you #Agile! It’s gonna be awesome! #Agile! Yay! #Awesome!

Software Engineer (SE): Couldn’t care less. You’ll be gone soon. You aren’t the first consultants to blow through here, you know.

AC: Oh, but you’re awesome. You just haven’t discovered your intrinsic awesomeness. Don’t you want to be awesome? Of course you do! Who doesn’t want to be awesome? Agile! Yay!

SE: Okay, sure. Awesome sounds good. How can I be awesome?

AC: Great! Awesome! The first step is you have to be passionate!

SE: Passionate about what?

AC: About your work, of course! Your work is awesome!

SE: Actually, my work isn’t all that awesome. When they hired me, they made me do a bunch of arcane technical exercises to prove I was a great developer. And for what? This job doesn’t call on any of those skills. I support an old Java Spring MVC app. Just about all the logic is contained in the no-arg constructor of a Spring-loaded bean. It’s 4,000 lines long. There’s also a utility class with fifty static methods. The whole thing runs on an obsolete version of the framework and doesn’t work with any supported version of Java.

AC: Wow, that sounds awesome!

SE: Well, it isn’t.

AC: It can be, if you’re passionate!

SE: Really?

AC: Sure! Look, it’s a question of mindset, isn’t it? Antoine de Saint-Exupery wrote, “If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea.”

SE: Hmm. I can see, maybe, yearning for the endless immensity of a better job.

AC: The job is what you make of it. If you can get into the right frame of mind, it can be awesome!

SE: So, you’ve done this before, then?

AC: Well, not me personally, no. But the <ambience sound=”AngelicChoir” light=”RayOfSunlightPartsClouds”>Agile Community</ambience> has done it. Agile makes everything alright. Agile makes everything awesome! They told us so in our Certified Scrum Master class.

SE: Master, eh? It must have taken a lot to get that. I mean, you don’t throw around a word like “master” lightly, right?

AC: Oh, yeah. You said it. Three days of games and snacks, and a short multiple-choice quiz at the end.

SE: Learned a lot from that, did you?

AC: You’ve no idea. Legos®. Pipe cleaners. Sticky notes. I can draw a picture of a three-legged stool. <gesture type=”CountOnFingers”>The first leg is Transparency, the sec—</gesture>

SE: Yeah…yeah, it sounds pretty intense. Um…look, I don’t think I can be passionate about this.

AC: Well, you’ve got to find your passion, if you want to be awesome!

SE: Have you ever maintained a crufty, monolithic Java webapp?

AC: <tone mood=”hesitant”>Not…as such.</tone>

SE: But you’ve maintained some other sort of crufty, monolithic code, right? So you have an idea how awesome it isn’t?

AC: <tone mood=”hesitant”>I wasn’t actually in software before I took the CSM class.</tone> <tone mood=”enthusiastic”>But that doesn’t matter. It’s all about passion, mindset, spirit. You know, culture.</tone>

SE: We’re done here.

Words have impact

It’s only fair to warn you that I’m still in the midst of a 12-step program to get over Caring Too Much About What Words Mean, because in the next few sentences I’m about to care too much about the words passionate and awesome.

In plain English, “passionate” doesn’t mean that you enjoy doing something or that you have a serious professional commitment to it. It means far, far more than that. Your passion in life is that which motivates you to keep on breathing; nothing less.

When agilists tell you to find passion in your work, they’re literally suggesting that you place your day job ahead of your family, your deep personal interests, your country, your religion, and everything else. That isn’t what they actually mean, of course, but it is what they say.

In plain English, “awesome” doesn’t mean “pretty good.” It refers to something that inspires awe. And “awe” means (according to Merriam-Webster), “an emotion variously combining dread, veneration, and wonder that is inspired by authority or by the sacred or sublime : stood in awe of the king : regard nature’s wonders with awe.”

When you walk into the room at your place of work, do you really want to inspire an emotion variously combining dread, veneration, and wonder, as if your colleagues were left speechless before the glory of the universe? Isn’t that a little bit excessive? Maybe it’s just me, but frankly I’d be uncomfortable with that sort of attention.

Here’s something I consider “awesome.” It’s the Antennae Galaxies, NGC 4038 and NGC 4039; two galaxies that are in a slow-motion collision. (Public domain photo from Wikipedia.)

Here’s a passage from the New International Version of the Bible:

It’s pretty awesome to be able to create a universe just by saying it.

Have you written any code lately that has inspired awe on the level of those examples? Neither have I. Even if, as the poet suggests, “I contain multitudes,” how many of said multitudes can inspire an emotion variously combining dread, veneration, and wonder, as if one were left speechless before the glory of the universe? Not many, I’ll warrant. If I thought that’s what was expected of me, I’d be pretty stressed out.

Is it any wonder that people react to this sort of thing by moving toward Extreme #1? From a Reddit question:

This is only one small example of the effect the extreme language is having on people in the industry. There’s a perception that in order to have a successful career in software development, you have to sacrifice every minute of your life to it. A fair amount of angst is expressed on social media over the perceived “fact” that you can’t get a job as a software developer unless you have a portfolio of Github repositories, as if you were an architect or a fashion model with a portfolio of samples of your work. There’s worry that employers expect software developers to be passionate enough to spend all their spare time coding, and the results of that coding must be awesome.

Reality vs. Perception

It isn’t so. You don’t have to have side projects. You don’t have to spend all your time coding.

People worry anyway. I think it’s because of the constant barrage of excessive language about passion and awesomeness. Other than spending all your time coding, how else could you possibly become “awesome”: literally capable of inspiring “an emotion variously combining dread, veneration, and wonder” based on your software work?

It turns out agilists aren’t asking us to be “awesome” in any real sense of the word. They’re just talking about baseline professional performance. Consider this post by Martin Oesterberg, entitled “Team Mission and Definition of Awesome”. I’m not picking on him; I actually like this example because the title explicitly states that the post will provide a definition of “awesome” as the word applies to “agile” software teams. (His definition happens to play into my agenda, too, but that’s purely coincidental. Pay no attention to the man behind the curtain.)

Read the piece. Go ahead; I’ll wait. <gesture type=”FingerTapping”/> Done already? Good.

Martin describes several different kinds of teams. I ask you to notice something: The descriptions of awesomeness are descriptions of baseline characteristics of a team. The word “awesome” is over the top. The teams are just not dysfunctional, that’s all. Lacking those characteristics, they aren’t “teams” at all; they’re work groups. It isn’t a question of Awesome Team vs. Regular Team; it’s a question of Team vs. Clump-o-Folks.

Linguistic reinforcing loop

How did we get here? I think there has been a reinforcing loop in the “agile” space. Agilists have used extreme words in an attempt to inspire people to pause and think about ways to improve their work and their working lives. That’s a worthwhile thing to do. But people have reacted to the excessive language by moving toward Extreme #1: get off my back, it’s just a job, it’s not Life. Agilists then reacted to the reaction by moving toward Extreme #2: they amped up the rhetoric in an attempt to be even more inspiring. People then reacted…well, you know.

Maybe if agilists would resist the temptation to use extreme words like awesome and passionate when all we really mean are, respectively, competent and professionally engaged; and if people would resist the temptation to over-react to those words without even asking for clarification first, then we wouldn’t find everyone clustered at the extremes.

Okay, so if we aren’t supposed to cluster at the extremes, then where are we supposed to cluster?

Survival and self-actualization

There was this guy, Abraham Maslow, who came up with a model. The model suggests human needs exist in a hierarchy. Basic needs have to be met before people can pursue higher-level needs. It seems pretty sensible to me. I’m not going to reproduce a copyrighted image, but here’s a site that has a diagram of the model: https://simplypsychology.org/maslow.html.

If you’re drowning, your immediate need is air. You won’t be thinking about whether your day job makes you awesome, or even if it pays enough to take care of your family, while you’re under water.

Let’s say you get out of the water. Assuming you have a dependable supply of air, your basic needs might be water and food. You won’t go looking for water while you can’t breathe, but once you’ve got the breathing thing handled, your next goal might be to find water, and maybe something to wash down with it. So, even if it’s dangerous, you’re going to go out into the world to look for water and food.

Let’s say you’ve got a reliable supply of water and food. Are you still going to rush out into the dangerous world? According to Maslow, your next level of needs are physical safety and security. So you won’t go looking for trouble, as long as you have enough water and food. The ancient Romans knew people wouldn’t go looking for trouble as long as they had plenty to eat, and maybe a little entertainment to watch while they ate it.

Those are your basic needs. Once those are handled, you’re going to be interested in psychological needs, like friendships, intimate relationships, and belonging to a group. You won’t care too much about those things if you’re in direct, immediate physical danger, but otherwise you’re going to want them.

The next level up from there is a feeling of accomplishment, of recognition by other members of your group. Of course, if you aren’t in a group at all, you can’t pursue this level of needs. But once you’re accepted as a member of a group, you’re going to be looking for recognition, prestige, rank, recognition and all that.

Given all that, you’ll probably be interested in self-fulfillment. Maslow calls it self-actualization, or becoming the person you’re meant to be. This isn’t possible if you’re still stuggling to meet more-fundamental needs.

Options and Necessities

All this stuff about self-actualization probably sounds absurd unless you’re at a level in Maslow’s hierarchy where self-actualization is feasible. If you’re just barely hanging on, as many people are, even in affluent countries, then you’re still worried about where your next meal is coming from or how you’ll manage to pay the rent next week. You may have to choose between rent or medications that you need. You may have to go hungry in order to keep your kids fed, since your ex isn’t helping. Unfortunately, there are lots of people in that sort of situation. Self-actualization isn’t on the menu.

The technical people I work with are not in that category. They aren’t desperate to survive. They’re in a better position than that. Their circumstances do not compel them to take the attitude that their job is “just a paycheck.” Anyone who has a job in the software field is in a privileged position: They needn’t worry about water, food, and all that. They are in a position to pursue self-actualization. Yet, many of them complain endlessly about their jobs. I’m sure there are plenty of people around who would gladly trade places with them.

On the other hand, it’s only fair to recognize that there are more-exciting and less-exciting assignments within the software field. Those enthusiastic Agile coaches may be asking for too much when they insist we have to be “passionate” about everything. If your job is to tweak the same Siebel work flow definition over and over, or modify the same COBOL paragraph over and over, or restart the same server over and over when the out-of-date COTS package it hosts runs out of memory, how will you dredge up anything like “passion” for the work? What the hell is “awesome” about it? It’s an unreasonable demand.

Where’s your passion?

People like Bill Gates and Steve Jobs might be able to find self-actualization through their “day jobs.” I’m not sure that works for most people. People may have a compelling interest in something unrelated to their paid work, and that’s where they find self-actualization. It may be raising your kids and being a good partner to your spouse. It may be contributing to community service programs through your church or a non-profit organization. It may be making craft furniture with wood. It may be coaching youth sports teams. It may be restoring old vehicles. It may be martial arts, music, sculpture, or amateur astronomy. It may be reading about history or philosophy.

Your “passion” may not lie in an area that has the potential to pay your bills. That’s how it goes. Human value and market value don’t always align. With a “day job” in the software field, you’re positioned to pursue self-actualization wherever you need to pursue it. That’s not a bad spot to be in.

Balance

This is a field that calls for professional responsibility; we aren’t just digging holes wherever the foreman points and says, “dig a hole there.” The attitude that our work is “just a paycheck” is inappropriate. It isn’t good enough just to show up, even if passion is an unrealistic goal. The question becomes: Is there a practical middle ground where people can function as fully-engaged professionals and yet live balanced, fulfilling lives?

From a Quora question:

When I was working with a large client in the financial sector not too long ago, one of the younger developers asked me about this. She was a couple of years out of school. Her boyfriend was also a software developer. She said he spent every evening playing video games and writing code for fun. She didn’t want to spend all her time doing that, after a day at the office. How was she supposed to manage her career development without falling into that trap?

I suggested that each of us has to decide how much of our time and money we want to invest in our professional development. Maybe we want to spend very little time and no money at all. That’s fine. Allocate whatever amount of time feels right to you for learning new things. Put it into your personal schedule and stick to it.

Let’s say you’re a .NET developer and you want to learn Python. You don’t want to spend “all your time” on software. Allocate, say, two hours every Monday and Thursday evening for learning. Use that time to follow an online Python tutorial, or more than one. There’s no cost. After a couple of weeks, you’ll have a basic understanding of Python. Then pick another topic; maybe Docker or Linux or whatever. It doesn’t have to be a big intrusion on your spare time.

Maybe you’re willing to invest more than four hours a week. Maybe you can do eight hours; two per night, four nights a week. It’s still not a big intrusion on your spare time; most people (well, most Americans, anyway) spend more time than that slumped in front of a television. Maybe, too, you’re willing to spend $10 to $50 a month on career development. That will get you a book a month, an inexpensive online course, and some small-scale resource usage on AWS or some other service.

If you’re up for it, there are numerous technical user groups and meetups all over the place. There are probably several within an easy drive of your location. Investing a little time for professional networking and learning at these events is a cheap way to keep up with new developments and create some options for yourself beyond your present job. Plus, they usually serve snacks.

The power of habit

It isn’t just about you. The attitude you bring to work affects all your co-workers. If you’re a downer, then everyone around you will be subdued and less effective in their work. They’ll drag themselves home with diminished energy, and transfer the effect to their families and friends. In turn, they will infect their families, friends, and co-workers with your attitude. Before long, civilization as we know it will grind to a halt, and it will be your fault.

Well, okay, that might be an exaggeration. But it’s no exaggeration to say that the habits you form through repeated practice carry over into other activities in your life. If you spend 2/3 of your waking life on your day job, then you’re building habits with everything you do at work. When you finally get off work and you can spend time on whatever it is that brings you self-actualization, don’t you want to have the energy and attitude necessary to take full advantage?

Conclusion

Checking out completely and treating software-related work as “just a paycheck” doesn’t cut it. You have to care if they ask you to do something unethical. You have to do your best to do the work properly. You have to keep up with new developments in the field. You signed up for those things when you chose this career, even if you didn’t realize it at the time.

It’s as if you picked up a shiny coin you saw lying on the ground. Your intent was to enjoy the shiny side of the coin that caught your eye. You didn’t care about the reverse. But you can’t have one without the other. You may have entered the software field because there are lots of jobs around and the work pays well. But the only way you can have those things is by accepting the other side of the coin, as well. The level of responsibility that goes along with this field of work is the reason it pays more than digging holes for a living. We all have the obligation to be worthy of the pay grade. You can’t choose just the pay grade and not the professional responsibility that goes along with it.

On the other hand, you don’t have to be “passionate” and “awesome” and all that stuff. You can be a responsible, engaged professional without sacrificing your personal life. It’s up to you to choose how much time you’re willing to devote to professional devleopment, alongside all the other things you want to do.

The balance between “passion” and “just a paycheck” is professional interest. Take an interest in your work and in yourself.

Posted on

Seeking to Understand

The original working title of this post was A teleological perspective on the reconciliation of antinomies in interpersonal interactions and the implications of reconciling ambiguities for clarity of communication and improved understanding, because I wanted something bright and punchy, but ultimately it ended up different. Hope it’s okay.

tl;dr version

Notwithstanding the wide range of disparate disciplines involved, our field is characterized above all by endless, circular debate over seemingly-trivial differences in word-meanings. After many years as one of those irritating people who’s always harping on word-meanings, I’ve come around to thinking it’s not the precise use of clearly-defined words that fosters useful communication, but rather the process of reconciling ambiguity. Not the reconciliation itself, if indeed it happens at all, but the process of reconciliation.

If we take antinomy at its meaning in philosophy rather than in law, “a contradiction between two statements, both apparently obtained by correct reasoning”, then a teleological view of debates over word-meanings reveals they serve the function of inviting alternative perspectives, questioning assumptions, sharpening arguments, and broadening understanding. From this viewpoint, debates may actually be the core method of learning, growth, and improvement rather than the childish distraction they appear to be.

Slightly more annoying version

I used to be fond of saying, “Words don’t mean what they don’t mean.” I thought each word had (or ought to have) a single, unambiguous meaning. Communication amounted to a straightforward process of arranging words in some deliberate order or sequence that could be interpreted in exactly one way. The only reason a person might not understand a statement is that the person was unfamiliar with (or mistaken about) the meaning of one or more words used in the statement.

The philosophy was comforting in its simplicity and consistency. However, a few recent experiences have prompted me to reconsider it. Well, actually, that’s not quite right. Thousands of experiences have pointed to the same lesson, over a period of decades. It would be more accurate to say that recently I started to pay attention.

The details of these instructive experiences are irrelevant. The general nature of them is this: I question the use of a word, with the gentlest of intentions, of course, and I get verbally beaten to a proverbial bloody pulp by all other participants in the discussion, each of whom has somehow arrived at a unique and yet equally inaccurate understanding of what I meant to say. I slink away and tell myself never to get involved with a discussion of any kind with anyone, ever. Then I do it again.

Anyway, the message I’m getting from all these well-intentioned beatings is that I’ve been mistaken in thinking that a word must have a clear meaning. The meaning of a word can be conditional on the context in which it is used, and on the frame of reference of the person using it. The particular words we use probably contribute little to our message. How could they, when they have no intrinsic meaning?

Words mean nothing

While this perspective does offer a path to improved understanding, it also introduces challenges in communication; or perhaps those challenges were present all along, and are now unavoidable.

If we have no commonly-accepted definitions for any words, then how can we even begin to understand another person’s frame of reference? And if we can’t count on a word to mean anything in particular, how can we convey ideas to others? They will simply interpret the words as they please, and their interpretation may well be surprising and even incomprehensible to us.

Why hasn’t the world devolved into a never-ending performance of the Monty Python sketch, “Spectrum” – Talking About Things. “What do we mean by the word what? What do we mean by the word do? What do we mean by the word we? What do we mean by the word mean? What do we mean by the word by?”

Derrida’s notion of deconstructionism suggests that the logos, or objective nature of a thing, is different from its “institution” (programmers might prefer to say “instantiation”) in language. Naive interpreters of deconstructionism are fond of saying that a “text” is reduced to nothing but the naked words, which have no inherent meaning at all. To them, the collected works of Shakespeare are equivalent to graffiti scrawled on a bathroom wall. It’s all just “text.” There is no meaning. We don’t even have an unambiguous way to ask the question, “What do we mean by the word word?”

Words mean something

Of course, I’ve been taking things to an extreme. What about the opposite extreme?

A term may have a precise meaning in a given context. For example, the term paroxysmal supraventricular tachycardia has a single, unambiguous meaning. If it happened to you, wouldn’t you want your doctor to know exactly what that meaning is? What do we mean by the word dead?

Your friendly neighborhood agile coach can’t say, “Well, when we say paroxysmal supraventricular tachycardia ‘in agile’, it means buttered toast.” Actually, I guess they could say it, but…well, moving on.

Finding the center

Maybe what the deconstructionists are trying to get to is the fact it’s hard to convey the true nature of a thing via the imperfect vehicle of human language. As Douglas Harper writes in The Impossibility of a Dictionary (2015), “What is an English dictionary today? It would have to be written each dawn; it would list every word used in an English conversation, chat, printing, and journal, anywhere on earth, in the previous 24 hours. The definitions would be whatever the users meant when they spoke or typed.”

Between those extremes lies open territory wherein a word’s meaning may shift one way or another depending on context, intent, and interpretation. Most words in human languages do not have a single meaning, immutable across time and space. Instead, most words convey a general sense of some sort of meaning. New words are coined based on the original, taking nuances of meaning in various directions. The exact application or “institution” of a word in a given context may differ from its “institution” in another context.

Words can mean what they don’t mean, and a lot of them do.

Words mean more than nothing, but less than something

That said, I think it’s fair to say there are certain words we tend to use in our field of work whose usage has migrated rather far from their basic meanings, not just the supposed precise meaning but even from the general sense of a meaning, and that such migration does result in misunderstanding. For instance, the English word sprint doesn’t mean what we mean when we say sprint in the context of software development (or “in agile”, as your coach might put it). If anything, it means something quite contrary to what we mean, because sprinting is not indefinitely sustainable.

You sprint as hard as you can, and then you collapse and rest for as long as you need to. That’s perfectly fine, because that’s just what you’re supposed to do when you sprint: Push yourself to the limit, or even push yourself beyond and discover a new limit, with no expectation that you’ll have to do it again immediately, without a chance to recover. After all, you don’t run a marathon by stringing a bunch of sprints together end to end, with no breaks in between. That’s not how it’s done.

It’s not how software development is done, either. We’d like software development teams to work at a sustainable pace, so they can deliver value consistently without suffering burn-out. The idea is that you do keep iterating, over and over, indefinitely, and without burning out. Yet, instead of that, we keep saying sprint. Then we have to keep explaining what we mean by it, over and over again. Instead of, you know, like maybe using a different word, or something.

The fog’s the thing

What I’m coming to understand is ambiguity, and even contradiction, may be more valuable than consistency. It may be better for us to use words in surprising ways. Gets the blood flowing. When people feel they must defend their understanding of a word, it’s a gateway for them to question assumptions.

A teleological assessment of debates about word-meanings looks for the function served by such debates, and not the motivations of the people involved, the underlying philosophy, or the precision of terms. The function of debate doesn’t require the argument to have a resolution at all; doesn’t require any answer to be the “right” one. The process of exploring the conflicting understandings of a word may, in itself, generate value.

When we search for a definition everyone can accept, we may be searching for the wrong thing. Maybe we shouldn’t try to see through the fog. Maybe the fog’s the thing, after all, and not what lies beyond it.

Given a single, precise, unambiguous, and fully agreed-upon meaning for each word, I can imagine conversations consisting of nothing but bland observations, with everyone comprehending things in the same way because everyone’s thinking is conditioned by the same language, without variation.

The all-Vulcan crew of the Intrepid couldn’t cope with an unknown threat in the Star Trek episode, Immunity Syndrome (1968), not because they were stupid but because they were subject to groupthink.

Seek dissonance rather than harmony

It isn’t necessary to end up with a common definition for any word. Maybe that’s not even a worthy goal, and we should stop trying. It’s only necessary to explore the differences in understanding, and learn from them.

Can’t believe I got through all that without referring to Humpty Dumpty. Glory!

Posted on

Is collaboration really so difficult?

In episode 79 of Dave Saboe’s excellent podcast series, “Mastering Business Analysis,” Dave interviews Paula Bell about effective collaboration. Here’s the link: http://masteringbusinessanalysis.com/mba079-effective-collaboration/

One point in particular stood out for me in this episode: “It can be challenging to collaborate under the pressure of deadlines. It’s worth taking the time to get to know one another and to some team building.”

It reminded me of situations that were common in the 1980s in corporate IT work: The “sweatshop” environment, in which working life comprised an unending series of death marches punctuated by physical/mental/emotional crashes.

Continue reading Is collaboration really so difficult?

Posted on

Definitions and meanings

This is a brief follow-up to the post, The power of words, on this blog.

Recently I posted a question on Faceboook and Twitter about the origin of the phrase “hold teams accountable.” The phrase is used frequently in “agile” circles. The only answer anyone suggested was that it probably pre-dates the agile movement, as managers have been thinking in terms of holding people in one sort of grip or another for a long time.

But that single answer was not the only response to the question (uh-oh; another pair of words, there).

Continue reading Definitions and meanings

Posted on

The power of words

The “agile” world seems to have devolved into a cloud of buzzwords and catch phrases. People repeat them without giving much thought to what the words might actually mean. They say things like passion and commit and fail, and they threaten to hold you accountable.

When agilists say these things, they understand one another perfectly well. They have internalized the deeper meaning of these “standard” agile buzzwords and catch phrases.

But it is not plain English. It is jargon.

What does a normal person hear, when the agilists speak their magical incantations?

Continue reading The power of words

Posted on

Seeds of change

Seeds of change

This one is for all the change agents out there who, from time to time, may have felt as if their work has no meaning or value.

Here’s what we do:

  1. We win an engagement with a client whose management want to institute organizational change (e.g., to implement Lean and/or Agile methods and practices, or to shift the organizational culture and management style toward a 21st-century model, or some other lofty goal).
  2. We define “success” as “the organization has deeply, honestly, and permanently changed for the better.”
  3. We help the people in the organization visualize a different future and guide them on a path toward that vision.
  4. We encourage people as the organization makes halting, slow progress.
  5. We encourage people as the organization succumbs to systemic forces and reverts to the status quo ante.
  6. We watch sadly as the people who had learned the most in the transformation initiative leave the organization.
  7. We hang our heads in shame; the definition of “success” has not been achieved.
  8. We use tales of the engagement to convince others to try the same thing, as we go forward in our careers. “It got off to a good start. If only…”
  9. We return to step 1.

Continue reading Seeds of change

Posted on

Does your organization need an agile scaling framework?

In collecting information for the ebook, Choosing an Agile Scaling Framework: A handbook for decision-makers, I was surprised to notice that the Kanban Method kept bubbling up to the top of the list of choices in nearly every scenario. For every business need except one, it was the best or one of the best choices. (The exception is the case when the organization only intends to pretend to change. For that purpose, less-expensive alternatives are available.)

Why would that be true? I wondered.

Continue reading Does your organization need an agile scaling framework?

Posted on

Do IT consultants want to be professionals?

The title expresses the first part of a two-part question:

  1. Do IT consultants want to be professionals?
  2. Do clients want IT consultants to be professionals?

Note the wording: I’m not asking whether IT consultants want to be professional (adjective). I’m asking whether they want to be professionals (noun).

The question isn’t about what it means to be professional in our work. It seems to me that amounts to our desire to do the best job we can. I don’t think there’s much debate to the contrary. The question is about what it means to be treated as a professional by our clients; conversely, whether our clients really want to treat us as such.

Continue reading Do IT consultants want to be professionals?

Posted on

Looking at TDD through a lean-agile lens

It’s a commonplace to say there is no “silver bullet,” and everything we do in the software field has to take context into consideration. In fact, this is quite true. TDD is a useful technique to know. To know TDD well, you must understand why and when it is useful, and how to do it correctly. If you apply TDD for the wrong reasons, in the wrong places, or in the wrong way, then it will not yield any value.

Many of the complaints people raise about TDD and about unit testing in general boil down to a misunderstanding or a misapplication of practices. Some complaints, however, are completely valid. You have to make your own professional judgments about such matters. To be equipped to make such judgments, you need to understand how TDD can add value in your work; and when it will not.
Continue reading Looking at TDD through a lean-agile lens

Posted on

Where Agile goes to die

There’s something I started to notice around 2011, but didn’t quite understand until recently. Now I think I have a handle on it.

From time to time I hear agile coaches describe a particular client company as a place where agile thinking never penetrates, or where agile methods are never properly adopted. It seems as if most of the larger markets have at least one such company or governmental organization.

One (that I know of) is known in its local market as “the place where agile goes to die.” Coaches in other markets have been less poetical in their descriptions, but many of them are aware of at least one client company that has a similar local reputation.

Continue reading Where Agile goes to die