Empirically (or "anecdotally," if you’re academically-inclined), practitioners know that high work-in-process (WIP) levels tend to lead to a variety of problems. Thanks to Rally Software, we have some hard data to help us make that case with clients. Continue reading Correlation between high WIP and defects
In a pressurized system that contains a liquid or gas, when the pressure is too high the system can rupture at its weakest point, causing a halt to operations, damage to the system and, possibly, leakage of dangerous materials into the environment. To protect against this, people install relief valves. The valves guard against excessive pressure and wrong-way flow. One type of relief valve vents into the atmosphere. It is used in applications that do not have hazardous liquids or gases. Another type can direct dangerous fluids to an alternate route, possibly collecting them in a reservoir of some sort, while protecting the system from damage.
In large organizations that use an "agile" process with a formal role similar to the Product Owner (PO) role defined in Scrum, a common problem is that the individuals assigned as POs are asked to work on more projects concurrently than they can handle with due diligence. Often, they are simply asked to add PO responsibilities to their existing workload. Thanks to the historical preoccupation with maximizing individual resource utilization in management "science," the PO’s existing workload usually does not provide any slack. In short, they are already too busy to begin with. Continue reading Relief valve for Product Owners
The question was posed in a discussion on LinkedIn. It received the following response:
Is the question "how does collaboration begin" or "how do specialists become generalists"? I assume the latter.
Um, well, that wasn’t the question. What’s the value in assuming a different question, because you’d prefer to answer the other question? After a number of comments extolling the virtues of the generalizing specialist, a person showed genuine interest in moving himself and his team in that direction. He want to get started. That’s a good thing.
Instead of helping him get started, however, people just reiterated the end state. Just do. Just be. Just blah blah blah. There’s a certain word in the question. It’s a little word; nothing ostentatious. But I think it’s kind of an important word. The word is begin. Continue reading How does collaboration begin?
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 Don’t do anything stupid on purpose
Open-plan offices, in particular, seem an impressively terrible idea. "Open plan layouts create massive distraction, damaging productivity," according to a recent analysis by the U.K.’s Channel 4. See also the related Hacker News commentary, which includes gems like "Most modern office layouts seem to be designed to screw with people’s fight or flight instincts all day," and "I’m a quiet type, and I often need time alone to think and write code and documentation. The ‘rah rah’ social types railroaded us…I am becoming bitter and resentful."
From time to time, something happens that reminds me that our espoused theories aren’t always congruent with our theories in use (see this summary for some quick background info on those terms). The author of an article I had cited as an example of "binary thinking" posted a comment asking how I had gotten the idea that he was pro- or anti- anything. I took the question literally, and started thinking about how any of us might get the idea that another practitioner was pro- or anti- any given software development practice. Continue reading What development methods and practices do you support?
There’s no shortage of advice about best practices. Naturally, commercial enterprises like IBM and Construx have advice. Their advice is designed to lead people toward their products and services. Of course, that’s because they believe their products and services support best practices. After all, they designed their products and services on the basis of what they consider to be best practices. So, it’s all good, right? They’re financially successful, so we can trust them. Besides, everyone knows that commercially-packaged best practices are carefully designed and well proven.
Individual practitioners are also eager to share the practices they have found "best" in their work. Their advice can be helpful, provided we remember it tends to be opinionated ("Git:Mercurial = Assembler:Java" — not "practices," BTW); haphazard and idiosyncratic (not to mention sexist and poorly written); specific to a single technology (and poorly written); or a rehash of generalizations (supported by questionable references). Like this Wikipedia article (as of 24 July 2013), such advice "has multiple issues." Continue reading Best practices for software development
It’s common to borrow terms from the physical sciences and apply them to other domains. A football team can gain momentum during a game. People tend to cling to habits because they have inertia. A software development team tracks its velocity. When we investigate the nature of the interactions of individuals in a group, we talk about self-assembly and self-organization.
I suppose there’s no harm in this, provided we remember we’re using metaphor and we remain aware of the context. As the saying goes, "The map is not the territory." Continue reading Elevator etiquette and self-organization
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 The Shimmering
No point to make. No particular order. No particular themes. No particular agreement or disagreement. Continue reading These are a few of my favorite things