One of the key ways to keep work moving forward is to avoid working on too many things at the same time. Ideally, a person should finish what they’re working on before starting anything else. Similarly, a team should complete the work item or ticket or story (or whatever they call it) they’re working on before picking up the next one. At a larger scale, a software delivery organization should limit the number of projects in flight concurrently, and strive to “stop starting and start finishing,” as David Anderson put it. That’s what portfolio management is for (among other things).
Author: neopragma
An IT professional since 1977, I’ve served in a variety of technical and managerial roles. I’ve worked mainly as a consultant since 1984, keeping one foot in the technical camp and one in the management camp. A lifelong learner, I’ve always been interested in exploring better ways to deliver business value through information technology. I’m currently working as an independent consultant, trainer, and coach with an interest in bringing together the best of tried-and-true methods and the best of leading-edge methods to help businesses realize the maximum return on their IT investments and efforts.
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.
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
I don’t know
Why are your socks on the floor again?
I don’t know.
Don’t say “I don’t know!”
How many times have I told you to turn off the light when you leave a room?
I don’t know.
Don’t say “I don’t know!”
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.
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.
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
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.
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.
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.