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

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