Tag: mindset

Posted on by

Cats in the monasteries of IT

Paulo Coelho wrote a nice piece about how cats came to be regarded as necessary for meditation for a few generations in Japan. The story might resonate with just about anyone in just about any context.

In my case, it reminded me of longstanding assumptions about how things “must” be done in the IT field. The following quote sums up the state of corporate IT in a nutshell: “..society continues to create some systems which, in the fullness of time, lose their reason for existence, but continue to impose their rules.” Continue reading Cats in the monasteries of IT

Posted on by — 7 Comments

Why should we do code katas?

I participated in a coding dojo recently in which some of the comments I heard caused me to think about the purpose of practicing code katas. It seems that many programmers, including some pretty advanced ones, don’t quite get the point.

We were reading about some code katas online so that we could choose one to do for the dojo. We came across a description of the Bowling Kata written by Robert C. “Uncle Bob” Martin. A couple of the guys quickly dismissed it when they saw Uncle Bob’s name. “He’s too prescriptive,” said one. “I don’t want to be told how to approach the problem,” said another. They looked for a write-up of the Bowling Kata that didn’t try to guide us in how to approach the problem.

They found one and we used it. All evening we kept running into silly little issues and speed bumps, such that we really didn’t get a lot of value from the whole exercise. We went down tool-related side paths, broke our development environment a couple of times, forgot what we were trying to accomplish, and started over multiple times. It never felt as if there was any goal or even a general direction. Despite the fact the group included some very fine professional programmers, I have to say it was not the best coding dojo I’ve ever been in.

Obviously, due to the sort of democratic and participatory event a coding dojo is, I have to accept a share of the blame for that. I actively chose not to make suggestions to bring the activity onto some sort of intentional course, because I wanted to see where it might go. In the end it went nowhere, but the experience led me to sit down and reconsider the reasons we do these things, and how we can get value from doing them.

The key point is that there are reasons for Uncle Bob’s approach to katas. Rather than getting to the point directly, I’m going to begin with a couple of rambling digressions, as per my usual style. Continue reading Why should we do code katas?

Posted on by — 13 Comments

The commoditization of “agile”

Sales consultant Phil Styrlund had an insight about the way markets have evolved in the Internet age that I think is relevant to information systems consulting in general and to "agile" and "lean" services in particular: Everything is a commodity. Anyone can obtain any goods or services they want by ordering them online.

It used to be that companies offering a product or service could distinguish themselves from others offering similar products or services by highlighting the special features of their product or by bringing unique capabilities to the table. Today, customers just don’t want to hear that. They have access to all the information available about your product or service. They already know. There’s nothing you could say about your product or about yourself that would make you any different, in the eyes of customers, from all the others in the market who are trying to sell the same things. You are a commodity.

Continue reading The commoditization of “agile”

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

Posted on by — 12 Comments

Fish gotta fly

There are these two young fish swimming along, and they happen to meet an older fish swimming the other way, who nods at them and says, "Morning, boys, how’s the water?" And the two young fish swim on for a bit, and then eventually one of them looks over at the other and goes, "What the hell is water?"

None of this is about morality, or religion, or dogma, or big fancy questions of life after death. The capital-T Truth is about life before death. It is about making it to 30, or maybe 50, without wanting to shoot yourself in the head. It is about simple awareness—awareness of what is so real and essential, so hidden in plain sight all around us, that we have to keep reminding ourselves, over and over: "This is water, this is water."

(David Foster Wallace, commencement speech at Kenyon College, Ohio).

Yeah, so if you care to Google it, you’ll find lots of articles pondering the reasons why the majority of Lean, Six Sigma, Agile, Kaizen, TQM, and name-your-poison adoptions "fail." People you and I know from conferences and books and such tell the same stories over and over again of the one big success they had with organizational transformation. Everyone was stoked about their branded re-packaging of old ideas made new again through the magic of buzzwords. They achieved improvements of 4x, 10x, 50x, or more X’s than you’d care to count. One or two years after the consultants left the building, those organizations were back where they started. I’ve seen it happen myself. The organizations snapped back to their old equilibrium state. Maybe they always do. The buzzwords haunt the place like fading poltergeists, and the stories live on, but the substance is long gone.

If you’ve done much Value Stream Mapping in information-shuffling organizations (as opposed to thing-making organizations), then you’ve probably done a double-take a few times, unable to believe process cycle efficiency could really be as low as that, and the company doesn’t sink through the earth’s crust like the superdense slug it is. It seems they’re happy as can be to spend 3 or 4 million dollars and burn up a year of 75 people’s precious time to build a routine, web-based CRUD app, fundamentally no different from a million others, that could have been delivered by a team of 4 in 6 weeks for the price of a few pizzas. Nor do they seem terribly worried about the opportunity cost of having all those people duct-taped to their desks for all those months, busily waiting for each other to "review" or "approve" things.

I’ve been wondering, lately, why none of those people wants to shoot himself in the head.

Continue reading Fish gotta fly

Posted on by

Size doesn’t matter

It’s a commonplace that large organizations tend to be stodgy and bureaucratic, and smaller ones tend to be innovative and flexible. When we see a large organization that seems to be innovative and flexible, we are amazed. The press springs into action to report on the existence of this Highly Unusual Thing. It’s an oddity, a curiosity, an anomaly, a freak of nature. The organization is cited as a case study in business books and academic papers. Executives in other companies try to mimic what they think they see the exemplary company doing.

Having participated in various change initiatives in organizations of all sizes (from around 20 people to around 240,000), it strikes me that size alone does not lead to stodginess. I think there’s something more fundamental: Identity. That is, the sense of identity on the part of the individual members of the organization. Do people feel like members of the same organization, all aiming for the same goals, or do they feel like members of a local tribe: Team, work group, department, division, etc.? As an organization grows, what factors might contribute to one sense of identity versus the other?

Continue reading Size doesn’t matter

Posted on by — 7 Comments

The machine society and how to cure it

A rigorous scientific experiment

On the morning of April 21, 2012, I submitted a Google search for the term, productivity. The search engine returned “about 244,000,000 results.” For the term, efficiency, it returned “about 362,000,000 results.”

A search for the term happiness returned “about 56,000,000 results.” A search for the term self-actualization returned “about 1,340,000 results.”

The first two terms yielded a total of 606,000,000 results. The second two terms yielded a total of 57,340,000 results. About 91% of the results pertained to productivity and efficiency, while about 9% pertained to happiness and self-actualization.

Which values are more important in modern society? Clearly, productivity and efficiency are more important than happiness or self-actualization. Have I based this conclusion on my highly scientific and rigorous Googling experiment? No. I already knew the answer before I Googled the terms. My conclusion is based on 58 years of life experience as a card-carrying member of modern society. The Google results were not informative, they were merely unsurprising.

It isn’t necessary to conduct a scientific experiment or an academic study to know that we are preoccupied with productivity and efficiency. Management training, process improvement methods, organizational models, and the like all focus predominantly on those two values.

The question, then, is “So what?”
Continue reading The machine society and how to cure it

Posted on by — 2 Comments

The Guinness model of release planning

This model isn’t based on release planning at Guinness. It’s based on drinking Guinness.

It’s the end of a work day. You and your mates are going out for a drink. Initially, you’re thinking you’d like to have three pints of Guinness. How do you place your order?

If you’re a traditionally-minded software development project manager, you’ll order all three pints at once, in the same glass. When the bartender tells you three pints of Guinness won’t fit in a one-pint glass, you’ll pound your fist on the bar and shout until he finds a way to make them fit. After all, the reason he doesn’t want to pour three pints into the glass is that he’s either lazy or incompetent, or both. Once you let him know who’s boss in no uncertain terms, he’ll get those three pints into the glass, one way or another.

Continue reading The Guinness model of release planning

Posted on by — 3 Comments

Tool mania

Sometimes people get fixated on a particular tool to the extent that they relate every topic of discussion to that tool. You’ve probably seen the pattern before.

I was reminded of it recently during a group discussion of metrics we want to use to track progress in a client’s process improvement initiative. One person kept bringing up Mingle, a tool her group uses to create story cards and track progress on software development projects. Her contribution to every subject of discussion was all about how Mingle supports or could support this or that metric.

At times, I felt as if I had taken my car to a garage and, when I asked the mechanic what the problem was and what sort of repair he recommended, all he would talk about was his favorite wrench.
Continue reading Tool mania