Ward Cunningham, a fish of some note in our small pond, wanted to deliver software incrementally to a client in the financial sector. The client didn’t see the value in doing that as opposed to delivering in a “big bang” fashion. To help relate the idea to the client’s frame of reference, Ward came up with the “technical debt” metaphor. It’s explained pretty well in an Agile Alliance article.
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.
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.
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.
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?
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:
- 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).
- We define “success” as “the organization has deeply, honestly, and permanently changed for the better.”
- We help the people in the organization visualize a different future and guide them on a path toward that vision.
- We encourage people as the organization makes halting, slow progress.
- We encourage people as the organization succumbs to systemic forces and reverts to the status quo ante.
- We watch sadly as the people who had learned the most in the transformation initiative leave the organization.
- We hang our heads in shame; the definition of “success” has not been achieved.
- 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…”
- We return to step 1.
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.
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
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.
Many larger organizations are considering adopting an Agile scaling framework to help them extend contemporary practices beyond the proof-of-concept stage. Plenty of people stand ready to help them choose an appropriate framework. Or maybe it’s more accurate to say, to help them choose the framework the helper wants them to choose.
I put together a short ebook that addresses the problem of choosing a framework from the point of view of someone who has no product to sell and doesn’t care whether you use a framework at all. Maybe it will help you and maybe it won’t, but either way it’s cheap, and it doesn’t try to sell you anything. See https://leanpub.com/choosing-an-agile-scaling-framework.