Kanban board != any vertical surface with cards stuck to it
- Kanban is the latest cool buzzword.
- We want to be (perceived as) cool.
- Therefore, our card wall is a Kanban board.
Well, actually…
Continue reading Well, actually…
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.
Pair programming and lean software development
I have learned quite a lot from reading Lean Software Engineering, a website authored by Corey Ladas. Although I am not personally acquainted with him, I have gained a great deal of respect for his thinking and his experiences in applying lean principles to software development.
My growing respect for him may be the reason I was struck by a comment of his that I came across recently while browsing the site. In a response to a reader’s comment dated January 7, 2008, he wrote: “Pair programming is antithetical to Lean” It was just a flat assertion with no explanation.
I was puzzled. Lean software development doesn’t speak to particular development practices, as far as I know. What might cause a practice to be antithetical to lean or, for that matter, to support lean? The only basis I could think of on which to reach such a conclusion was that the practice either hinders or helps us in applying lean principles to software development. Corey did not provide the same level of careful analysis and explanation as he does with most of the useful material on his site, so I decided to reason through the question myself.
Continue reading Pair programming and lean software development
Choices, consequences, intentions
I have this concept that no one seems to like. Whenever I start to describe the concept, people interrupt me before I’ve finished in order to tell me how stupid I sound. I usually begin with a non-controversial opening statement like, “Funny that people insist on choosing pain (or failure, or high costs, or long lead times, etc.).” That’s when the interruptions begin.
Now I’m typing, not talking, so friends can’t protect me from my own words before it’s too late. Nevertheless, I choose to proceed.
The concept is this: We make choices because we think the choices will fulfill our intentions. In one of those cruel twists that the Universe seems to enjoy so much, it turns out that choices and intentions are not connected with one another. Instead, choices are connected with consequences. Each choice has its own natural consequences. The consequences apply regardless of our intentions and regardless of whether we properly understood the consequences of our choices at the moment we made them.
Continue reading Choices, consequences, intentions
Can a new dog learn old tricks?
[This was originally published on my old blog on 18 September, 2007. A friend recovered the post from Time Machine. There were some good comments on the original posting, but those were not saved by Time Machine. Unfortunately, the attitude I observed 5, 15, and 25 years ago hasn’t changed much. Enjoy.]
A few months ago, I used the phrase “the collective experience of the industry” in an online discussion about good practices in software development. I got slammed. We have no “collective experience,” I was told, we just have “a bunch of individual experiences.”
At the time, I thought it was incorrect to say that we have no collective experience. Software developers encounter many of the same situations and solve many of the same problems over and over again, in different domains and in different technical contexts. At the time, it seemed to me that the common aspects of these experiences could form the basis of a corpus of shared professional knowledge.
Continue reading Can a new dog learn old tricks?
A strategy for lopsided teams
Here is a somewhat exaggerated and sanitized description of a situation I encountered on a coaching engagement.
The stated problem was that the software development teams in a certain department were taking too long to deliver and the results tended to have more defects than was deemed acceptable.
Continue reading A strategy for lopsided teams
Beware the golden hammer
Change agents and coaches often ask me how to overcome resistance. The coach wants a team to adopt a practice or technique that he/she “knows” is good. Why won’t the team members consider his/her suggestions? It’s possible that they just don’t see any pressing need to change the way they work.
It turns out that experienced professionals aren’t slumped in their offices in a puddle of their own drool, dazed and defeated, surrounded by the smouldering remains of failed projects, hoping a savior will appear and teach them a magic trick that will make them better at their jobs. Notwithstanding industry studies that highlight general problems in software delivery, development teams aren’t “failing” left and right. Software development organizations do deliver results. Few of them deliver results as effectively as they could do, but they aren’t necessarily aware of this, or they don’t see it as especially important because it isn’t causing them any real headaches. People have settled into a comfort zone where they are respected, they feel successful, and they are well paid. When a change agent comes charging at them with golden hammer in hand as if they were in need of rescue, insisting that they change the way they think about and approach their work, why should they listen? The truth is they shouldn’t listen. They’re doing exactly the right thing when they “resist.”
Continue reading Beware the golden hammer
Warning signs of client dependency
When we function in the role of coach, our primary goal is to bring the client to the point of self-sufficiency with respect to some aspect of their work. Whether we are engaged as a technical coach or process coach, we want the client to internalize some set of values and practices that are presently unfamiliar to them, to shift their mindset in some way, and then to carry the new approach or new skills forward independently. We want to make ourselves unnecessary.
The same can be true when we are engaged as management consultants. In that role, our function is usually to advise and consent. We will be one source of information among several, or many. We may not be privileged to know all the details of the decisions the client needs to make. We are only asked to apply our best professional judgment to the situations the client wants us to address. The advise and consent function is different from the coaching function.
Continue reading Warning signs of client dependency
The Blackbird Effect
This is a re-issue of a post from my old blog that people have asked for.
SR-71 Blackbird. Photo from Wikimedia Commons.
The SR-71 Blackbird, a global reconnaissance aircraft developed by the United States Air Force, first flew in 1964, and was in service from 1968 to 2001. Even at the time of its retirement, it represented relatively advanced technology as compared with most aircraft. In 1976, a Blackbird set the speed record between New York and London at just under 2 hours. The Blackbird’s speed record for manned air-breathing aircraft still stands, although manned rocket-powered aircraft and at least one unmanned air-breather have gone faster.
Ethics vs. morality
In one of the most bizarre misunderstandings of the code of ethics I proposed the other day, a reader suggested that by adopting a professional code of ethics, a consultant or technical coach was somehow trying to impose Western morality on people in remote parts of the world. Because this is such a strange reaction, it’s difficult to know how to respond. Yet, if the code of ethics as currently written can result in such an extreme misunderstanding, then I feel I must try. Continue reading Ethics vs. morality
Ethics vs. technique
Some of the comments on “A code of ethics for consultants, trainers, and coaches” suggest that the statements in the list may not be self-explanatory. Some of thes points might be worth a longer explanation than will fit into a response to a comment. One example is the apparent confusion between professional ethics and professional technique. Continue reading Ethics vs. technique