[ Content | Sidebar ]

Archives for Lean / Agile

finished book queue; rorty

Looking back, I had my lean book-buying revelation more than a year ago. As I said at the time, “right now, I have … lots of books to read before I can start buying again”, and while I have hardly sworn off from buying books since then, I have made an effort to read down […]

rejection in person; printf debugging

One of the least pleasant aspects of hiring is rejecting candidates. (More actively unpleasant for them than for me, to be sure.) It’s something which, until recently, I did almost exclusively over e-mail. Sometimes, rejection over e-mail makes sense. I typically put candidates through up to three stages of filters. (Not counting the initial resume […]

groovelily; regret

I learned about the band GrooveLily from an episode of Next Big Hit. I wasn’t paying too much attention when the song, “No Room In Your Bag”, started: a patter song over a drum backing. But then some chords on the piano came in, the instrumentation started getting richer (electric violin, yay), and I started […]

random links: april 21, 2007

As presentations about how the world is changing go, this one is well done.

random links: april 8, 2007

Housing prices as shown on a roller coaster. I had no idea that the ups and downs had been so small until recently. An Agile Toolkit interview about movie making. (This one had some interesting non-programming analogies, too. Go Steve! Different ways of looking at the world.

schiphol queues

For the non-EU flights in Schiphol (at least where we were), they place a metal detector at each gate, instead of having a central bank of metal detectors that everybody goes through. And I can’t figure out why. This seems like the worst possible solution from a queuing theory point of view: you get your […]

mike cohn on estimating and planning

Last week, I went to a talk by Mike Cohn on “Agile Estimating and Planning”. Good timing: I’d been thinking that I should get around to reading his book on the subject. Which I won a copy of at the drawing after the talk; apparently my recent remarkable good luck has (correctly) decided that I […]

codification of experience

Another quote from The Toyota Product Development System (p. 102), in the section on checklists: A company that cannot standardize will struggle to learn from experience and is not truly engaged in lean thinking. Indeed, any company that simply tries new things without standardizing along the way is “randomly wandering through a maze,” repeating the […]

don’t broadcast information

A quote from Morgan and Liker’s The Toyota Product Development System: Toyota does very little “information broadcasting” to the masses. Instead, it is up to the individual engineer to know what he or she is responsible for, to pull what is needed, and to know where to get it. Here’s the full context (pp. 95-96; […]

following distances in traffic

When I mentioned my earlier post about questions I had about driving in traffic, Jordan pointed me at this article that claims that a single driver, by leaving a large amount of open space while entering a traffic jam, can actually (at times) break up the jam. Which is pretty amazing, if true. The author […]

curious about queueing theory

Now that I’m seeing queues everywhere, I’m getting curious about both the underlying math and the underlying pragmatics. Take a highway, for example: say you want to get the most use out of one. What does that mean? I guess it means maximizing total throughput, or more specifically the car miles driven on the road […]

podcast queue management

Sorry for the lack of posts. I might have a post stuck in me, or I might just be getting lazy, or might not be thinking enough; hard to say. Maybe I’ll get unstuck over the holidays. Anyways, I present another banal application of lean to everyday life: Using my mad queue-management skillz, I’ve finally […]

exploratory testing

The Poppendiecks’ latest book gives an interesting analysis of types of testing. (Taken originally from Brian Marick’s blog.) They propose that you divide testing up in two different ways: on the one hand, you can classify tests as either intended to support programming or to critique the product. On the other hand, you can classify […]

random links: november 21, 2006

I should really catch up on my blogging; in the mean time, some random links: Will it blend? I know where I’m buying my next blender from. John Baez on the state of fundamental physics. Just the link for the panda fan in your family. A followup to a traffic experiments article that I mentioned […]

response time

One thing that’s been bothering me at work recently: our response time to bugs is absurdly slow. Even bugs that are marked as high priority take a while to get worked on; bugs that aren’t marked as high priority may well never get worked on. Now, some of this is a classification issue: maybe a […]

lean thinking, shared purpose

I just finished Lean Thinking; it’s my current favorite lean book. One thing that made me jealous: they give several (to me) convincing examples of companies wanting to try out lean, and that brought in some people who really knew how lean worked. After doing what those people said, they immediately got some fairly impressive […]

scrum and bottlenecks

In response to a not-very-coherent question of mine on the lean development list, Tom Poppendieck posted an interesting response. From it: Over a decade ago, when Jeff Sutherland invented Scrum, he was faced with a situation in which his product development process bottleneck was the capacity of skilled developers. He designed Scrum specifically to exploit […]

throughput and latency

I’ve been kind of obsessed with the theory of constraints recently, which has gotten me wondering about bottlenecks. One of their points is that, in general, a system has a single bottleneck; you should do everything you can to make that bottleneck as productive as possible. For a simple bottleneck example, say you have a […]

benefits of slack

After some discussions on the leandevelopment list, it would seem that slack has has more benefits than I realized. My current list: If you’re not the bottleneck in your process, adding slack won’t decrease throughput and may well increase it (since it makes it easier for you to avoid stealing resources from the bottleneck). Leaving […]

how to improve?

I am currently awash in confusion about how we (my team, but also everybody working on the same product) should improve. Tough stuff; I hope I’ll have something more coherent to say here soon. Fortunately, the good folks on the leandevelopment mailing list are helping me sort through my difficulties. The fact that I’m so […]