Year: 2019

Posted on by

Introversion and Agile

The relative effectiveness of collaborative work over individual work for many (not all) activities has become well-enough established by now that hardly anyone questions it. No one establishes an “agile” work space in such a way as to maximize disconnected, individual work and to minimize direct communication. That would be absurd.

And yet, people are determined to defend their comfort zones. A popular way to avoid working collaboratively is to say, “I’m an introvert.” Often, this is stated flatly, with a tone of finality, as if the word “introvert” completely explains why it is impossible for the individual to collaborate with others. Obviously, an introvert has to work alone all the time. They are hard-wired that way. It’s innate. It’s an immutable trait. There are no variations or nuances. End of argument. Now I’m going to turn my back on you and put my headphones back on. Go away.

There are a couple of problems with the way people typically throw the word “introvert” around.

Continue reading Introversion and Agile

Posted on by

Recruiting and interviewing in confusing times

For context: This post is about recruiting and job-seeking in the area of software development, testing, infrastructure engineering, and related disciplines. It isn’t general.

There’s a lot of discussion just now online and offline about endemic problems in the software industry around discrimination, pay discrepancies, hiring practices, humane workplaces, and questionable interviewing methods. Most of that discussion is highly emotionally charged, to such a degree that it’s “unsafe” to disagree with just about any comment online, or even to agree with a comment using words the “owners” (is “dominators” a word?) of the discussion haven’t approved.

That situation does not seem healthy or constructive to me. So, I thought I would take a few minutes to try and cut through some of the emotion to understand what’s wrong with recruiting and hiring in our field, and whether there are some concrete steps people can take, on both sides of the interviewing table, to improve things.

Continue reading Recruiting and interviewing in confusing times

Posted on by

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 by

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 by

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 by

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