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.
I’m not a salesman for, or even much of an enthusiast for Scrum, and yet I keep finding myself in the position of defending it (or appearing to do so). A survey was posted a few weeks ago entitled “What’s the Problem with Scrum, and How can we Fix it?” (capitalization theirs). They’ve published the results, and so here I am again, appearing to defend Scrum.
What I’m actually defending is the idea that if we want to criticize a thing, that at least let’s criticize what the thing really is, and not a strawman version of it.
Do people resist change? The consensus appears to be that they do.
Well, with all that consensus floating around, I guess resistance to change must be a Thing. It’s hard to argue with a million articles that all say the same things.
On the other hand…not everyone sees it that way.
- calories from fat: (don’t ask)
I’d like to begin with an insightful quote. Until I find one, here’s a quote from Vonnegut:
“I am a Tralfamadorian, seeing all time as you might see a stretch of the Rocky Mountains. All time is all time. It does not change. It does not lend itself to warnings or explanations. It simply is.”
— Billy Pilgrim in Slaughterhouse Five, Chapter 4 (Kurt Vonnegut)
The online debate about software estimation may well be the greatest waste of pixels since the invention of porn. Like porn, the debate comprises a never-ending repetition of the same scene over and over again, the very definition of “boring.” And the actors conclude each day in the same state they were in when they awoke. Every day the same, every day exhausting, every day pointless.
The argument, like Kenny of Southpark, refuses to die. It wakes up each morning as if nothing has happened. In a sense, I guess, nothing has.
Anyway, here’s the thing: Despite people’s best efforts and their protestations to the contrary, no one can predict the future accurately and precisely.
Nadie habrá dejado de observar que con frecuencia marcos del proceso se aplican mecánicamente.
Maybe Julio Cortázar, whose 100th birthday we celebrate this year, would have begun a set of instructions for implementing a process framework with similar words. No one will have failed to observe that many individuals, teams, and organizations are quite befuddled by the process framework they are trying to use. They struggle mightily to follow every “rule” the framework “requires,” even when their goals are ill served by those rules.
Indeed, it is typical for such individuals, teams, and organizations to lose sight of their original goals altogether in their attempts to satisfy the real or perceived “rules” of the process framework. No matter how haphazard their previous mode of work may have been, many conclude that the framework “doesn’t work,” and revert to their former methods.
It’s a familiar adage among engineers, often posted in work areas. Does it pertain to software development? The seemingly endless circular debates about software delivery methods lead me to think so. The latest chapter in the ongoing drama is the recent schism between Lean Kanban University’s flavor of Kanban Method and the rest of the lean/kanban community. And the paint hasn’t yet dried on the sumo match between Kanban and Scrum. A few years ago (mid-00’s, as memory serves) the same debate (except for the names of the methods) raged between proponents of Evolutionary Project Management (Evo) and Extreme Programming (XP). Prior to that, we kept ourselves entertained by debating whether RUP was Agile. Before we could do that, we had to settle the debate about the relative merits of Spiral and RUP, of course. And Spiral vs. linear SDLC processes. Tomorrow, next week, or next month, it will be something else. Important questions, all.
Yet, I can’t help noticing, as Ron Jeffries puts it, it’s all the same elephant. When I stopped arguing and started listening to the elephant, I heard it say "Don’t do anything stupid on purpose." What does the phrase mean in the context of software development and delivery? To explore the question, I think it would be helpful to define the terms stupid and on purpose for that context. Continue reading
In the movie, Now You See Me, a certain idea was stated multiple times, phrased in various ways: "Look closely, because the closer you think you are, the less you will see." In the past decade, a lot of people have been inching closer and closer to something called "agile," and most of them are pretty sure they can see it.
Things are very different on each side of the "hump" in the diffusion of innovations curve. On the left side, the early side, where the Innovators and Early Majority adopters live, people tend to be forward-looking, open-minded, imaginative, proactive, and willing to take risks. On the right side, the late side, where the Late Majority adopters and Laggards live…well, not so much. Some people are interested in the left side, because that’s where breakthrough ideas are vetted in the proverbial fire of the (possibly over-rated) Real World. Others are interested in the right side, because that’s where methods and practices become scaled, integrated, and institutionalized to support large enterprises. Continue reading
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
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