Posted on

Annoying Travel Article

As someone who travels frequently for work, I found the advice in this article pretty annoying: 10 Tools for Getting Work Done on Long Plane Rides.

Annoyance #1: The very idea

Summary: What the hell are you doing trying to work on a fricking airplane?

Life and work can be somewhat unpredictable, so there may be occasions when you have to do some work on your way to a client site, presentation, or business meeting. But the general rule for normal people is that you’re not “on the clock” 24×7.

Learn to manage your time. Get prepared for your event before you leave. On the flight, try to relax. When you arrive, you need to be rested and have a clear head. You won’t do your best work if your tired and stressed.

Continue reading Annoying Travel Article

Posted on

Scrum as a belief system

I came across a post by Damian Synadinos, dating from August 2017, entitled Thinking about Beliefs. He explores the idea of belief systems; how they come to be, how people interpret them, how adopters implement them, various things that can go right or wrong when people apply them, and what can happen when we question our belief systems.

After presenting a general model of belief systems, Damian goes on to illustrate his ideas by describing how he set out to question his beliefs regarding software testing; that is, his belief system around his work. He discovered that some of his previously-held beliefs about software testing seemed sound while others had room for improvement, once he began to question them systematically.

Continue reading Scrum as a belief system

Posted on

For the love of stress

This tweet resonated with me:

The comment applies to the author’s area of focus, but the pattern she observes occurs broadly in our field. How is it possible circa 2019 that the majority of people in the software field are not routinely using:

  • rolling-wave planning to avoid premature investment in undeveloped ideas and to enable business flexibility/agility?
  • flexible funding models to avoid locking up funds in early, long-term budget allocations?
  • product-oriented experiments to steer development work toward target capabilities, as opposed to a portfolio of projects with rigid, predefined objectives and timelines?
  • collaboration with stakeholders, Specification by Example, Personas, Story Mapping, etc. to understand user needs?
  • cross-disciplinary collaboration to build solutions, including cross-functional teams, sitting together, swarming, mobbing, pairing, etc.?
  • development techniques that yield multiple forms of value for a single effort, such as test-driven development and test automation, both for infrastructure and for applications?
  • general automation to reduce errors and ensure consistency, such as continuous integration, static code analysis, dynamic infrastructure management, etc.?

…and, of course…

  • observability rather than monitoring?

Do people actually prefer

Continue reading For the love of stress

Posted on

A different wall to bang our heads against

Throughout my career, people involved with software development and support have done their best to make software perfect; or at least to eliminate all the bugs from it. We’ve come up with more and more design principles, development techniques, testing methods, system monitoring and self-correction schemes, and tools aimed at avoiding, preventing, detecting, working around, recovering from, and removing bugs from software.

Continue reading A different wall to bang our heads against

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.

Continue reading Balanced Professional Interest

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.

Continue reading Seeking to Understand

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