Category: Uncategorized

Posted on by — 1 Comment

The fall and rise of shadow IT

Years ago, as far back as the mid-1980s if memory serves, IT managers were worried about a phenomenon they called “shadow IT.” The term refers to cases when business managers implement their own departmental IT solutions in response to poor support from their internal IT departments. The phenomenon raised alarms in the minds of IT management. They were losing “control.” Others were treading on “their” territory. Lions and tigers and bears! Oh, my!

I was reminded of this when I saw an announcement of an upcoming webcast entitled, “What’s a CIO to do About the Rise of Shadow IT?” This suggests that many IT managers still don’t get it. So-called “shadow” IT is not a “problem.” It is not an intrusion on anyone’s sacred territory. It is an indicator that something about the status quo is causing people’s needs to go unmet.

The question should not be, “How dare they try to take over our territory?” The question should be, “What are people trying to tell us about their needs?”

Continue reading The fall and rise of shadow IT

Posted on by — 2 Comments

BBUF: Big Budget Up Front

The packaging of ideas represented by “agile” includes elements pertaining to organizational culture and elements pertaining to processes and practices. Although many of us would like to see organizations adopt useful elements in both areas holistically, in my experience it is not the case that the two are welded together. Instead, cultural aspects and mechanical aspects affect work flow and outcomes differently and independently.

In most organizations that have adopted “agile” methods, people have embraced a subset of the mechanical elements of “agile” development, but they have no understanding of the cultural aspects and, in many cases, no interest. Yet, I think it’s fair to say they are “using” or “doing” agile development. It’s definitely possible to employ some of the mechanical aspects of “agile” development in the context of an otherwise-traditional organizational structure and culture. It’s happening all over the world right now. Because of this reality, I often use the word “agile” to refer only to the mechanical aspects. I sometimes run afoul of agile practitioners because of this.

When I suggest that the use of “agile” methods does not automatically mean we are doing adaptive development, some agile practitioners protest. Continue reading BBUF: Big Budget Up Front

Posted on by — 1 Comment

Choosing between traditional and adaptive development

The Iron Triangle of scope, schedule, and budget is fundamental to managing software delivery initiatives. Two general approaches are available for managing this aspect of delivery. With the traditional approach, we try to identify all needs, risks, and costs in advance and create a detailed, comprehensive plan before beginning development. With the adaptive approach, we begin with a vision for the product and incrementally evolve the solution based on feedback from stakeholders. Either way, we must deal with scope, schedule, and budget. However, the mechanisms we use are very different with each approach, and the metrics we can use to steer the initiative are different as well.

There are two key factors to consider when choosing an adaptive or traditional approach to Iron Triangle management: Urgency and uncertainty. Generally speaking, when either urgency or uncertainty is high, an adaptive approach is called for. When both urgency and uncertainty are low, a traditional approach is called for. It’s only fair to say that the choice is not always obvious.

Continue reading Choosing between traditional and adaptive development

Posted on by

Geek moments

Today I came across a coupon from Dole inviting me to enter a contest, the Big Apple Giveaway. I wondered what the prizes were. Probably iPads, iPods, or other Apple products, I guessed.

Suddenly I realized the contest wasn’t a Big <pause/> Apple Giveaway. It was a Big Apple <pause/> Getaway. Not giveaway, but getaway, as in travel. And not Apple, the company, but "The Big Apple," New York City.

I suppose I could have taken the hint, as the I in "Big" took the shape of a silhouette of the Statue of Liberty. Not an Apple logo, as far as I know. Not yet, anyway. But it just didn’t register at first.

I felt an oddly disorienting sense of being out of phase with reality for a moment. It reminded me of an incident several years ago, when a colleague came to work and told us that she had called a plumber the previous evening, and could not think of any way to describe her problem other than to say, "My kitchen sink is down."

The plumber didn’t quite know what to make of it. "What do you mean, down? Did it fall through the counter-top?"

"No, it just, like, you know, doesn’t, like, work."

I wonder of you’ve had any "geek moments" like those; moments when your computer-oriented mentality scrapes rudely against the hard sides of normality’s box? Or is it just me?

Posted on by — 1 Comment

Thor’s hammer had a name, so why can’t mine?

Mjölnir.

Thor’s hammer was called Mjölnir. Cool name for a problem-solving device.

Liza Wood commented on a recent post of mine in which I lamented the overuse of the word, "agile," and the ill effects of that overuse. She wrote, in part:

I completely understand why you have become disenchanted with word "Agile", but I am sticking with it for now. For the majority it’s still at least a starting point to have a pragmatic conversation about product development (not just software).

I wonder about that. Is the word really a starting point for pragmatic conversation? Different people have had different experiences with that. My experience has been that people already have some pretty firm ideas about the implications of the word, "agile." A recurring pattern is that a change agent goes into an organization and happily proclaims, "Oh, boy! We’re going Agile!" To his/her surprise, the people in the organization do not react to the proposition joyfully. The word "agile" connotes Happy Things to the change agent. What does it connote to other people? Why are they not happy to hear it?

Ron Jeffries’ classic article, We Tried Baseball and It Didn’t Work, suggests an answer.

Continue reading Thor’s hammer had a name, so why can’t mine?

Posted on by

Value streams and value networks

Lean thinking is based on a model of delivery in which raw materials are progressively developed into a finished product that is consumed by a customer. This linear path is called a value stream. Many in the software community have criticized this model as too simplistic at best, and harmful at worst, as it risks ignoring key stakeholders by focusing on "the" customer.

In real life, a software product has many stakeholders. There may be multiple customers who have different needs and different usage patterns for the software. There may be people involved who are affected by the functionality or quality of the software product who are not, strictly speaking, customers. The process of building and delivering a software product is far more complicated than a simple, linear "stream" of activities. For those reasons and more, some people prefer the term value network to the term value stream. Continue reading Value streams and value networks

Posted on by — 1 Comment

The Vulcan choice

We tend to make decisions based on emotion, intuition, gut feel, and wishful thinking. At the same time, we assume these are the wrong tools for decision-making. In our culture, there is a belief that all decisions and all conclusions must be based purely on logic, reason, science, or statistical evidence. It seems that people feel there is something wrong with conclusions or decisions that are arrived at by any means other than cold, calculating logic. (Never mind, for the moment, people’s demonstrated ability to apply logic.) There is an apparent desire to rid ourselves of emotion, morality, and even personal preference when making choices, even though this seems to be contrary to our nature.

This assumption is so deeply ingrained in our culture that we have formally defined decision-making on any other basis as an error. We call it Base Rate Neglect (regarded as a cognitive bias) or Base Rate Fallacy (regarded as a logical fallacy). But which is the true fallacy: The use of non-logical decision-making methods, or the belief that such methods are to be eschewed categorically?
Continue reading The Vulcan choice

Posted on by — 3 Comments

Intuition and cognitive bias

In the past five months or so, I have been in on-again, off-again negotiations with a prospective client to participate in fairly large-scale organizational transformation initiative. The engagement would involve coaching, mentoring, training, consulting with management, travel to interesting cities, the chance to introduce effective methods to some 1,200 people, and the opportunity to work closely with some of the top people in the field. The agreed daily rate was just sufficient to cover expenses in the pricey home city of New York and still provide nominal income. Everyone involved was enthusiastic. We signed. I started to outlay cash to arrange for housing, and purchased the initial airline ticket.

With less than 24 hours remaining until flight time, a new manager took over at the client company. He abruptly terminated the entire organizational improvement initiative and all associated contracts.

This sort of thing happens from time to time. It isn’t the sudden reversal that caught my attention. Something else about the situation piqued my curiosity. It has nothing to do with the client, although one might justifiably question their handling of the matter. It has to do with the way I arrived at the decision to accept the engagement.
Continue reading Intuition and cognitive bias

Posted on by

Perception

A post on this blog received a very interesting comment from a reader with the nom de pixel Malapine:

"…my problem isn’t boredom but fear: the codebase sucks, we have no idea whether the features are what customers want, and if the product doesn’t sell, some of us may get laid off. If that’s ever me, I am screwed: my resume will show two decades with the same employer, the vast majority of it on Waterfall or ScrumBut projects."

"Off the job, I read books on Agile, go to monthly dojos, etc.; but on the job I can’t even do TDD properly — builds take 20 minutes just to compile, and nobody else seems to care."

I felt this called for more than a response in the comment thread. It seems to me it illustrates that perception can be more important than reality, and that is of interest to me presently.

Continue reading Perception