malvasia bianca

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 improvement. But they then managed to improve on this continually over the next few years.

Which, among other things, serves as a counterpoint to some thoughts I’ve been having, and that seem in the air in general. (See, for example, Martin Fowler on agile imposition.) It’s been clear to me for a while that my team’s agile adoption would have been vastly improved by bringing in an outside expert some time ago. (It would probably still be vastly improved by that.) But, among other things, doing so would be tantamount to my saying “we’re going to do XP, plain and simple”. People may hear me as saying that already, but I don’t intend to be saying that. What I would like to be saying is “here are some things that are really important to me” (high quality standards, sharing knowledge, responding quickly) and “I haven’t heard of anything that sounds as effective as XP to reach that goal”.

So one aspect is that I’m jealous of people who have built up the support where bringing in an outsider to show them what to do is effective. But another aspect is that I’m also jealous of people who have concrete touchstones that they can use to continually approve. This is something that, perhaps, XP isn’t so helpful at. The concreteness of the practices can be very useful if you need something specific to try. But they have a finality about them that (to me) makes it hard to use them as guideposts for continuous improvement. For example, we don’t pair program all the time. I’m willing to believe that we’d be more effective if we did, but I don’t have any great way to convince people (even to convince myself) that doing so would be a good idea, and taking it on faith will only go so far. In a current thread on the XP mailing list, Ron Jeffries proposed telling people to find a way to “deliver working software monthly”; a lot of people are willing to believe that that’s a noble goal, but getting from there to XP is a pretty big step.

So what are intermediate goals that can help you see ways to continually improve? (Through which you might end up at XP or might end up somewhere else; if we can continually improve, I really don’t care about anything else.) Here, I think lean manufacturing has a leg up on agile software development: they have goals at a similar level to agile goals (single piece flow or just in time / pull are probably at a similar level to incremental development and no bugs), but I get the feeling that they have more ways to see flaws and to translate those flaws into concrete improvements. (Categories of waste, or stop the line when you see a bug, combined with root cause analysis, for example.)

Or maybe agile is just as good at that; it could (in all honesty, I’m not being facetious) just be my lack of knowledge combined with my lack of skills in the appropriate areas.

Something to work on.

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 the capacity of the bottleneck, to subordinate everything else to ensure maximum throughput through the software development process, and to elevate the capacity of the bottleneck by removing impediments.

I’d never really thought of Scrum in that sort of Theory of Constraints terms; hmm.

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 linear, five-step production process. So there are steps A through E, with A’s output being B’s input, and E’s output being the final product. Assume they can produce at the following rate (assuming the previous step has completed): A can produce 10 per day, B can produce 5 per day, C can produce 10 per day, D can produce 3 per day, and E can produce 10 per day.

If you look at where work is piling up, both steps B and D might look like bottlenecks: A can produce tons of stuff, so step A might get annoyed that B can’t consume its output fast enough. Looked at from the whole system point of view, though, only step D is a bottleneck: no matter how fast the other steps get, the whole system can’t produce more than 3 per day.

This example is very simple, but actually a lot of its similarity is irrelevant for this analysis: even if the paths branch and join in interesting ways, ultimately the rate of production of the whole system is limited by its least productive step. (For more complex graphs, though, the actions you take get more interesting - for example, typically there’s some day-to-day variation in the productivity of any given step, and you have to pay more attention to that on the steps feeding the bottleneck than elsewhere. But that is a discussion for another day.)

This, however, doesn’t mean that you can’t get a lot of good from improving the non-bottleneck steps. The first level of analysis is simply to look to make sure that the non-bottlenecks aren’t stealing resources from the bottlenecks. But, aside from that, the above discussion is about throughput; in many situations, latency can be just as important, or even more important.

So, in the above example, consider step C. It can produce at a rate of 10 per day. Maybe that means that it can carry out its step for 10 items in parallel every day; maybe that means that it can carry out its step for 1 item every .1 days. (Or maybe it can carry out its step for 100 items every 10 days.) From a throughput point of view, these are all the same; from a latency point of view, though, doing it for 1 item every .1 days is the best: compared to the 10 items in parallel version, that reduces the time from when raw materials enter the door to when a finished product leaves the door by .9 days. Which is great.

In fact, from the point of view of the whole solution, even a version of C where it could carry out its step for 1 item every .2 days would be better than a version that could carry out its step for 10 items every day. The latency of that step would go from 1 day to .2 days, which is good. The throughput of that step would go from 10 per day to 5 per day; that looks bad, except the throughput of the whole system is 3 per day, so that reduction in throughput is irrelevant.

Which doesn’t mean that you should go around reducing throughput willy-nilly: you’d better make quite sure you know you’re not the bottleneck before doing that! Fortunately, one lesson of lean and agile is that, if you work at it, you can increase latency without decreasing throughput. (Single Minute Exchange of Dies, as opposed to taking two hours to change dies.) Look for waste, find ways to reduce or eliminate it, and you’ll be happy.

It’s not at all clear to me how to apply this at work: I don’t know where the bottleneck is, and our process isn’t even well-enough defined for me to be confident that there isn’t something big that this analysis is missing. One tool to give clarity on this matter is a value stream map; I’d like to try producing one of those some time over the next week or two. If done right, that will help identify potential bottlenecks, and will probably help with ideas for reducing latency. The other tool is waste reduction; the value stream map will help there, too, and I should go through the traditional lean categories of waste to see what examples I can come up in my organization.

After some discussions on the leandevelopment list, it would seem that slack has has more benefits than I realized. My current list:

1. 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).
2. Leaving a little slack makes your schedule more predictable: you can work harder to make a date if that should prove to be necessary.
3. It gives people time to recharge.
4. It gives people time to experiment, to try to find improvements that they might not have found if their nose was constantly at the grindstone.

One nice thing about lists like this is that you can turn them around to find places where you should be wary of applying it to your situation. In particular:

The first point suggests that, if you are the bottleneck, slack isn’t a particularly good idea: the bottleneck controls throughput, so the less the bottleneck works, the lower the throughput. And, even if you aren’t the bottleneck, you shouldn’t stick in so much slack as to become the bottleneck. (And you should consider spending some of your slack time figuring out how to help the bottleneck.) Exercise for the reader (actually, an exercise for the writer): what’s the bottleneck in your organization?

The second point suggests that you should have enough control over your schedule to know when you should eat into your slack. Mary Poppendieck mentioned a company that had been working on an 8-week cycle, with 6 weeks development and 2 weeks testing. They got the 2 weeks of testing down to one week; they turned the second week into slack intstead of adding it to development. That way, if problems show up after release, people can jump on them immediately. (And people are motivated to make sure problems don’t show up after release!)

The third point is a reminder that, if necessary, people will create their own slack whether you like it or not; if you try to avoid that, your reward will be burned-out employees. The flip side is that you don’t need vast amounts of slack to get this benefit.

And the fourth point is the most interesting one, and the one whose benefits are potentially largest and hardest to predict. Which means that I have nothing coherent to say about it.

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 confused suggests that a top priority should be getting more visibility into the situation. If I’m taking a lean point of view, we need to eliminate waste, which means that we should make that more visible. (Red cards? Probably start by just listing forms and manifestations of waste.) If I’m taking a theory of constraints point of view, we need to focus on bottlenecks, which means we should make that more visible. (Maybe create a value stream map?)

The latter is where I started: how do I figure out if my team is the bottleneck? (Is there really only just one?) I have no idea; I can see the card piling up before my team, but I don’t really know what happens after the card exits my team. So I can’t tell where work is piling up.

I’ll try to find time over the next few days at work to create some wiki pages on waste and bottlenecks. One fun thing about work is that enough people are subscribed to the wiki notifications that, if you’re thinking about something, you can just create a wiki page on the subject and you’ll attract some random, insightful questions or comments.

Now does seem like a good time to think about this. On the one hand, there is reason to believe that executing efficiently now could be particularly useful. And on the other hand, my boss has too many direct reports, so some sort of reorganization there may happen over the next month or two. So, if I could actually think of something useful to inform the reorganization, with solid reasoning behind it, I might be able to have an effect.

One of the times when I’m happiest is when I’m wandering around in a confused daze. (Don’t get me wrong, figuring things out and getting things done has its pleasures as well.) But I do need to get some concrete outputs from my wandering.

Today’s book: It’s Not Luck, the second of Eliyahu Goldratt’s business novels. Which I actually read after the third; cleared up a few issues, but the reading order didn’t matter too much. (I would recommend starting with The Goal, though.)

This book presents some thinking tools for analyzing situations that confuse you, where you’re stuck in a bind and don’t know how to get out of it. On the surface of it, this doesn’t have much to do with other aspects of the Theory of Constraints; there may be some sort of deeper pattern going on here, though. After all, agile methods are usually linked with retrospectives, and root cause analysis / five whys is part of lean (as are other thinking tools, for that matter), so it would seem that methodologies that I’m currently interested in each recommend some sort of disciplined introspection.

Certainly something that I’m interested in these days: one of my problems is that I sometimes leap to canned answers of the “right” way to handle a given situation, which has obvious (and less obvious) flaws. Don’t get me wrong - the opposing attitude of “it doesn’t really matter how you do things” is also a real loser, but I/we could use some help looking closely enough at my/our concrete situation to figure out how to improve. I’m glad we started doing retrospectives before the teams changed; I don’t think I want to revive that quite yet, but hopefully we’ll be able to have one by the end of the month. And the ToC thinking tools might well be a good match for resolving issues that I have personally; if nothing else, they seem admirably concrete. (I imagine there’s also a book explaining lean thinking tools in concrete terms, I just don’t happen to have read it.)

I also liked the comment from this book (on one of the more elaborate tools) that it’s not that hard, or even that time-consuming to do, you just have to force yourself to do it. I certainly have experience with watching myself shy away from doing things that I know are important, for all sorts of unsatisfactory reasons. (And perhaps occasionally for satisfactory reasons, but never mind that.)

Some of the examples that they worked to led to interesting places, too. The “local optimization is the root of all evil” example was a bit too canned for my preference (though the methods that they used to come to that conclusion were interesting). But I did like the idea that business can benefit much more from segmenting markets, including segmenting previously undifferentiated markets, than they currently do. One point of view that lean books rightly attack is the cost view that the appropriate price for a product is its cost plus a reasonable profit margin: the market is under no compulsion to agree with you that a price determined in that manner is worth paying, so if you can’t convince them that a product worth what you charge for it, any amount of whining about a reasonable profit margin is useless. Instead, find ways to tweak your product offerings so as to maximize their perceived value; if you do it right, and if other people can’t easily copy you, then your profit margin can be quite a bit larger than what might a priori seem “reasonable”.

In this light, Sun’s recent strategy of selling hardware while giving away software, or giving away hardware while selling support for software, or providing subscription plans for hardware, or probably other variants that I’m forgetting, starts to make rather more sense. Find ways for customers to choose the package with highest value for them, do so in ways that almost no other companies can easily copy, and do so in ways that put excess capacity to use, and you will start making money. Sounds good in theory; we’ll see if recent positive news is a sign that this strategy is starting to make traction, or if it’s just another mirage.

As I mentioned at the time, one of my fellow managers gave notice two and a half weeks ago, with the result that his team got combined with mine.

Interesting couple of weeks. I had some ideas about how I might handle the transition, but they mostly got blown out of the water, for two reasons:

• One of the members of the other team also gave notice (for apparently unrelated reasons).
• We had some unusual high-priority interrupts. Of a positive nature, fortunately, but it did mean that normal planning went out the window.

Which, in its own way, turned out to be a good thing, because it admirably focused all of our minds. Rather than worrying about how the cultures would fit together, or having philosophical arguments, it was clear to all of us that we had to focus on doing two things as quickly as efficiently as possible: gathering what knowledge we could from the two departing programmers, and servicing the interrupts. Don’t get me wrong, I very much wish that both the departing programmers were staying with us, but at least their departure gave us a clear goal; the high-priority interrupts were all for the good, because it let us work together towards an important concrete end.

And those efforts were, as far as I can tell, quite successful. We all worked more than normal, and had to overcome problems (in both teams’ former domains); none of us had to work so hard as to burn out, and the code in both teams’ former domains was very much up to the task at hand. There were several opportunities for cross-team collaboration, too. So we know each other a little better (not that we didn’t know each other before - we’ve all been working in the same group of cubicles for the last few years, talking and eating lunch together all the time), and we’ve shown that we can get stuff done by working together.

Having said that, there’s a lot of stuff that didn’t get done. There were several things that I really would have liked to start two weeks ago that I only got around to starting today. (One-on-ones, for example.) We only just got started on September planning; honestly, I’m not completely sure we’ll get a good monthly plan in place until October.

What planning meetings we’ve had were instructive. In the first meeting, we tried to do full card estimation in the same manner that my old team had. And that took forever, for a few reasons: half the group was unfamiliar with what was involved in any given task, deciding between a half-point and a whole point took too long on many cards, and we went off on tangents. So in our second such meeting, we gave up on points, instead identifying candidate cards as either “too big” or “not too big”; we didn’t get on almost any tangents; and things went much more smoothly. But we still have a lot of task breakdown ahead of us, and very little estimation backlog built up, with the result that we might have to just play it week by week for the time being. (Another contributing factor is that more high-priority interrupts of an unpredictable nature are coming.)

Everybody is happy with daily standups, as far as I can tell. A reasonable amount of pairing going on. A reasonable amount of people working on tasks that had, in the past, belonged to the other team, though demarcations are very clearly present. I’m still managing to get my hands dirty occasionally.

Don’t get me wrong, we still have a lot of challenges ahead of us. But now that I’ve finally been able to take a bit of a breather, I’m optimistic.

I just finished another one of Eliyahu Goldratt’s business novels on the Theory of Constraints. I didn’t lose sleep over it the way I did with The Goal, but it was quite good. And useful to see ToC applied to product development situations, instead of just manufacturing situations.

One thing that caught my eye: not only does it speak somewhat ill of Just in Time, it lumps the latter together with assembly lines. Only somewhat ill, to be sure: assembly lines and JIT are both successful in limiting the amount of inventory that can accumulate between stages, limiting the waste of overproduction. TOC agrees that that’s a good idea in general; but it’s really focused on alleviating the ill effects of bottlenecks, which means that while it’s happy to have production stages that aren’t involved in bottlenecks be idle when not needed (as JIT supports, but perhaps assembly lines have a harder time with?), it wants to make sure that there’s material ready to allow bottleneck production stages to be active whenever possible. Mind you, TOC doesn’t want pre-bottleneck stages to produce for the sake of production, but they definitely shouldn’t run the risk of letting the bottlenecks be idle.

So: who’s right? TOC or lean (of which JIT is a component)? I’m pretty sure I’ve run across favorable mentions of The Goal in lean discussions, so I doubt they’re too strongly opposed. (It would, of course, be inconceivable that both are wrong: I couldn’t possibly be obsessed with two areas of thought that are both mistaken.)

Of course, lean isn’t just JIT: there are other tools in there. And doubtless part of the answer is that, because of the increased predictability that lean’s high quality gives you (via its other tools), the need for TOC-style production buffers is lessened. And kanban, the technique by which JIT is maintained, could probably be used to get TOC-style buffers. Kanban is the pull-style mechanism where each step requests new material from its predecessor by handing it containers to fill. The simplest example is one-bucket kanban: if you have a sequence of steps where each step requires one item from its predecessor, then this is the situation where each step keeps one piece of inventory on hand. That way, if a request comes in from its successor, it will be able to quickly build what is required. (While, at the same time, putting in a similar request to its predecessor, to make sure its one feeding bucket remains full.)

This works great if all steps take the same time, but sometimes different steps take diferent times. In those situations, you can add buckets as necessary. Or, I suppose, remove buckets - for example, when buying books, Amazon normally ships books to me a little faster than I want to buy them, so while I normally use one bucket, I don’t always worry about keeping the bucket full.

If we wanted to adapt this to the TOC concerns, then, I suppose they might recommend that your bottleneck should have more buckets preceding it than would otherwise be strictly necessary to fill that step’s demands: you’re trading off excess inventory before the bottleneck for the risk of having your bottleneck not working at full capacity if something goes wrong. Given TOC’s focus on bottlenecks, that seems like a reasonable tradeoff.

I’m not sure that lean would agree, though - they would probably see this as a failure, and focus instead on improving the predictibility of the bottleneck’s predecessors. Given the apparent effectiveness of lean’s tools for improving predictibility of manufacturing, that sounds like a reasonable response to me. Non-lean shops might want to focus more on the bottleneck’s buffer, though. (Don’t get me wrong, buffers in TOC situations are much letter than buffers that other methods find acceptable.) Also, lean covers more than just manufacturing; maybe it takes more of a TOC-style approach in, say, product development? Honestly, I have no idea.

So: what does this mean about my situation at work? Again, I have no idea: I’m having a hard time finding the sequence of steps that will enable me to even ask the question of what the bottleneck is. For now, probably the best thing is for me to watch and figure out where something inventory-like is piling up, because it will naturally appear before bottlenecks. If the bottleneck is under my control, though, then probably the right thing to do isn’t to focus on the chains leading up to the bottleneck, though: the right thing to do is instead to eliminate the bottleneck by, say, increasing the number of people who can work on that area of code. (If it is an area of code.) So lean over TOC for me.

Kanban calculations have started to appear. For example, one of the questions that my team had been recently asking in its previous incarnation is how large a task backlog we needed from my boss. We’d been doing a monthly planning cycle with my boss, combined with internal weekly planning cycles; it’s not clear that’s a great mix, though. If we really only had a month of cards then, at the end of the month, we’d be mostly done with them, and might be unnecessarily idle because we wouldn’t have quite have enough to work on. So, at any given time, it’s useful to have, say, an extra week of backup cards built up. There’s also a problem at the start of a month: we have a whole month of backlog then, and that can actually be a bit much - sometimes, for example, we had a hard time accurately predicting how long it would take for us to do a card a few weeks off, because we needed to get our hands dirty with the preparatory work first.

So the lesson seemed to be that two or three weeks was about the right size for our kanban bucket: that’s best for production leveling, keeping us working at our maximum productive pace. And, actually, I suspect that that size is actually a bit too large - we need a bit of a buffer in case we’re more productive than expected over the course of a week, but lean suggests that you don’t want buffer for the purpose of making sure that people can’t still work on something if, for whatever reason, they’re not suitable for working on tasks that would otherwise be higher priority. You should instead see the latter as a bug, figure out its root cause, and try to eliminate it.

Lots and lots of stuff for me to learn. Lean concepts are starting to fit together for me, but I’m also becoming increasingly aware of just how little I really understand lean. And how little I really understand several other things…

One thing that I never got around to blogging about when I first became lean-obsessed: Toyota never fires anybody. Or something like that; at any rate, one thing that lean bloggers claim is that, for lean manufacturers, employees are a fixed cost instead of a variable cost.

Which has interesting ramifications. In general, it’s a good deal more humane, which I certainly approve of. And it fits in well with constantly asking your employees how to improve matters: if both parties are committed to each other, then it’s natural to see your employees as resources whose insights are to be valued. (Similar to the way they treat their suppliers.) All to the good.

Having said that, there are a few things that I wonder about. In the first place, what if your business isn’t constantly growing like gangbusters? I know, I know, that’s a sign that you can’t possibly be doing lean right, but it still strikes me as conceivable that even the leanest of businesses might have efficiency improvements that aren’t linked to sales increases, or might be hit by an economic downturn that it can’t ride out solely by lowering prices enough to maintain market share. So what do you do? In the former case, you could simply give your employees the excess profits by paying them the same for working fewer hours. The latter case is harder.

At the very least, this suggests that there’s more to this production leveling idea than is obvious at first glance. Even if you have a surprise hit on your hands, a lean company may decide not to provide enough of their product to meet demand, because that could lead to a rate of expansion that would lead to overstaffing in less sucessful times.

That’s one problem; the other is rather darker. I don’t know what matters are like now, but if Womack and Jones are to be believed, not only will Toyota not kick you out, but you won’t be able to leave if you want: salaries are set based on service time with Toyota, not overall skill or experience. So if you change companies, you start again at the bottom of the salary level, which few people are willing to do. And that sucks.

So I’ll go with the Semco model in this regard. You get the same respect for employees, the same benefits of treating them as resources, but without the gilded cage aspects. And they get advantages from an entrepreneurial spirit, where employees not infrequently leave to form companies that turn out to be valued suppliers for Semco; victory all around. They don’t seem to manage their ups and downs quite as smoothly as Toyota does; that’s okay with me (makes them feel more human, at least), and they’re certainly leery about excessive expansion as well. And, I suspect, the highs and lows in Brazil were more extreme than they were in Japan, once the worst of the WWII effects wore off there.

I’ve read a couple of business novels recently, and I confess that I hadn’t properly appreciated the genre before. I’m not going to stop reading nonfiction or anything, but it seems like a quite decent way to learn something about an area that I don’t want to currently pursue in depth. Which is the case for most business topics - I want to figure out what I can do to help increase the chance that the product I’m working on will succeed, and there are doubtless skills I don’t have that I should be thinking about, ways of looking at situations that I could productively be informed about. But that doesn’t mean that I want to delve into these areas in depth: for now, I’m just browsing for ideas. So the lack of depth in these novels doesn’t bother me (and, for all I know, these topics might be situational enough that learning more theory wouldn’t have a huge payoff, though that’s probably my bias showing), while I’m surprised to find how much having a bit of a plot to follow helps keep my interest.

I’m currently in the middle of The Five Dysfunctions of a Team, by Pactrick Lencioni. (Almost done with, actually, even though I started it yesterday and have done several other things in the intervening time; admittedly, it’s a quite short book, a little over 200 pages with very little text on them.) Don’t get me wrong, I don’t see any of the various teams I’m a part of being particularly dysfunctional; the book was actually a little comforting in that regard. Having said that, there are certainly scenes described here that are pretty familiar, and if I were more at ease with conflict, I could doubtless do a better job of helping us get productively aligned. A fun, fast read; I’ll probably check more of the author’s books out of Sun’s library.

The Goal, by Eliyahu Goldratt, however, was completely and utterly absorbing: I brought it home and spent more than one night reading it rather later than I normally consider wise and then lying awake for way too long after turning off the light trying to figure out what, if any, concrete actions I could take. It’s about queue theory, or the theory of constraints, or leanish ideas, or something; basically, taking a manufacturing plant, figuring out what results are actually important to the plant, and figuring out how to alter the behavior on the floor (and elsewhere) to dramatically increase the quality of those results. With some quite surprising twists, if you haven’t seen this sort of thing before; I really should dig up a link to a Theory of Constraints simulator that I found somewhere and try playing with some variables.

Which is all pretty interesting, but what kept me up at night was: what does this mean to me? One of the basic principles, for example, is that, when considering the productivity of a system, the bottlenecks are almost all that matters. So, for example, keeping people working on non-bottleneck tasks just for the sake of looking busy probably isn’t doing you any good and may in fact be actively counterproductive. Which is pretty interesting, and I can imagine trying to apply that on a manufacturing floor. Does it apply to a software team, though? I’m pretty sure the answer is “yes”; how do I then go about identifying the bottlenecks that determine my team’s effectiveness?

There are probably several lessons to be learned here: my difficulty in even starting to figure out how to identify the bottlenecks is a warning sign in itself, for example. (There are other related warning signs, e.g. the fact that I have no clue in how to draw a value stream map for our situation.) But of course that’s the wrong place to start: following the title of the book, the first question I should ask is: what is the goal? Which my boss and I had a talk about recently, and it turns out that we came up with the same answers: that alignment is certainly a good sign, and it’s greatly clarified some decisions that we’ve had to make this month.

So what are other interesting novels out there on topics that would normally be covered in nonfiction? What other nonfiction genres does this work with? (I have a hard time imagining learning, say, algebraic geometry by reading a novel.) I am curious.

When I first saw Brian Marick’s complaint about the prevalence of the term “leadership” at Agile 2006, my first reaction was “hmm, that doesn’t sound so good, and here I am being part of the problem.” After thinking about it a bit more, though, the Christopher Avery talk that I blogged about doesn’t sound like the sort of thing Brian Marick is bothered by - that was really about responsibility, a concept which is equally applicable to all levels of the organization.

Still, I was pretty sure he was onto something. (Side note - where did I read an article recently complaining (intelligently) about bossism?) But then, a couple of days later, I saw Brian Marick on a stage helping present the Gordon Pask award. So it would seem that my understanding of the “Great Man theory” and his understanding are somewhat different. I guess he’s more focusing on the ills of executive leadership than on other forms of leadership? The team leads the Scrum Master but the organizer leads the XP day participants? Seems a bit odd to me.

This seems to be the focus of his post:

We know how to do software better. It’s the executive’s job to support us in doing that—to clear obstacles out of the way of our practice—and not to lead us. We already know where to go. We know how to do our job. We need to be assisted, not led.

On the one hand, I sympathize with that a lot. I’ve had one notable experience with an executive pushing his pet theories on a development team, and it’s one that I hope not to repeat. I’m a fan of the notion that you should move decisions to the lowest responsible level. And it’s unquestionably the case that people who are doing something out of internal motiviation will work at it much more effectively than people who are doing it out of external motivation.

On the other hand, I can’t uncritically accept the statement “We know how to do software better”. Another past experience that I’d like to avoid in the future involved a project where decisions were supposed to be made relatively communally, yet where dysfunctions seemed to me to hurt the effectiveness of the team’s operation; while I can imagine other solutions to that problem, I’m sure that an effective executive would have stepped in and resolved the issues much more quickly. To be sure, an ineffective executive could well have exacerbated the problem, but I won’t argue that that group as a whole “[knew] how to do software better.”

And just what is the better way that we allegedly know how to do software, anyways? Given the context, I assume it’s agile in some form; my experience is that many/most programmers aren’t particularly well steeped in agile ways of thought, and that, when exposed to those ways of thought, most programmers find some areas they agree with, some areas they are suspicious of, and have good reasons for their suspicions. Also, if we know how to do software better, did we also know how to do software better 10 years ago? Were our answers the same then? Will our answers be the same 10 years from now? Are we sure that teams will always come to those new insights before executives? I’m not. This stuff is hard; I can use all the help I can get.

On the third hand, just who is the “we” who know how to do software better? Agile practices bring in a large number of stakeholders. In particular, even if we want to move decisions to the stakeholders most directly affected by those decisions, a key stakeholder is the gold owner, who is likely an executive. I can understand arguments that, say, the gold owner shouldn’t have much to say about the details of your refactoring strategies. But I think the gold owner might well have a lot to say about the composition, frequency, and quality of your deliverables, or about the reliability of your estimates, and hence has every right to feel strongly about, say, the planning game, frequent releases, and the quality of your test plan.

The most interesting examples I know of of companies that have productively moved decisions to lower levels are Toyota and Semco. My understanding is that, in both cases, executive leadership played a strong role. I won’t say that it was the only factor, but surely we can learn a lesson from that? One of the key agile tenets is the importance of communication; we should embrace productive communication with executives, accept them as potential active resources for change, not limit our vision of their job to simply be “to clear obstacles out of the way of our practice”.

 

After writing the above, now I’m starting to understand why some people say that retrospectives are the single most important agile practice. Communication is key, getting people at all levels to think about how we could best do our work is crucial. And I can imagine how increasing the openness of conversations could potentially have helped greatly with some areas where we’ve functioned at less than peak effectiveness over the last few years. I’m looking forward to our team retrospective on Monday.

As previously threatened, I asked my team members if any of them would like to take charge of retrospectives. To which I got the response “but that’s not the way to do things: we try to share knowledge and skills wherever possible.” Oh, right - I’m glad somebody remembers that sort of thing, since obviously I’m not up to the task!

Anyways, after a bit of discussion, we decided that it didn’t make sense for us all to go off and read the book right now. So one of us volunteered to read the book, run one retrospective, and rope the rest of us into running subsequent retrospectives, while sharing an overview of the ideas from the book and being available to suggest techniques from the book. In other words, taking ownership of the task without unduly linking that to carrying out the work (or hogging the knowledge). Yay.

I spent this morning hanging out in open space. The first discussion was a followup to last year’s talk by Arlo Belshee on promiscuous pairing. It turns out that a couple of experience reports were presented here on teams’ experiments with the practice. The good news: both teams saw similar productivity/quality/etc. boosts to the team from the original experiment. The bad news: both teams gave up the practice in spite of those boosts, one after about a month and the other after about three months. (The original team had been doing it for 18 months, with no plans to stop, by the way.)

I don’t remember the details of why one team stopped after one month; something about thinking that it’s too hard, or not enjoying it. So it would seem that the practice can, for some groups, bump up against Sustainable Pace. (I got the impression that the original team had a higher tolerance on that front than the norm.)

The story behind the team that gave up after three months is apparently that they’d run into a few team issues after a month or so, which they’d solved, and some bigger team issues after three months, which they might have been able to resolve but were hindered from doing so by management shuffles. Arlo said that his team had also seen big issues surface at around that time, as well; they’d managed to deal with them successfully, and doing so improved their performance.

This is a phenomenon that shows up more generally in lean discussions: once you reduce buffers / cycle times in various ways, problems start to turn up that you hadn’t seen before. It’s not that the problems weren’t there before: they were always there, hindering your progress, but you just hadn’t been forced to deal with them. Which manifests itself in other ways in agile processes, of course - e.g. continuous integration makes breaking the build a much more serious problem than it would be in other environments, but that’s not a problem with continuous integration, it’s a problem with breaking the build! This particular manifestation of the problem does seem scarier, though: in particular, it suggests that a team that wants to try it should probably be comfortable with introspection and retrospection.

After that, I participated in a discussion on what agile might have to learn from open source. About which I don’t have much to report.

I spent the afternoon at a tutorial on retrospectives, run by Esther Derby and Diana Larsen. Retrospectives are one of my current sore spots: I’m bad at running them, but I hear over and over again how important they are. And I believe that, too - I very much want my team to continue improving, and to do so in a collective fashion.

And I’m glad I attended the tutorial: we got some hands-on practice, we got some ideas of other things we could try, and I picked up a copy of their book to get more ideas. So I’m rather more confident now that I can get this to work - if nothing else, I can try format after format and topic after topic to shuffle things around, and I’m pretty sure that something will click with us. (And will then get stale after a few months, after which we’ll be able to shuffle again.)

On the other hand, I still don’t feel that it’s an area where I’m particularly skilled. So now I’m thinking that I should ask my team members if any of them wants to volunteer to design and run retrospectives. If none of them do, fine, I’ll do it myself; if one of them does, that will move more decisions down and there’s a good chance that one of them is more talented in this area than I am. And I’ve got a book full of suggestions for whoever volunteers for that.

Back to work tomorrow. I’m glad I came; certainly useful for me, and I hope it will prove useful for my employer. No revelations, nothing that’s going to have a huge concrete effect on my work, but I learned about and got practice with some useful techniques, and learned a few things about myself. And if, for example, higher-quality retrospectives can cause my team to gain just one extra week’s worth of work over the next year, then that will pay for the conference a couple of times over. Also, being at a conference made it much easier for me to concentrate on the subject: I left the hotel a grand total of twice during the conference, and spent the vast majority of time during the five days thinking about what I wanted to learn, going to talks, thinking about what I’d learned at those talks, and blogging here to get some of those thoughts out. I’ve spent some time keeping up with other tasks or doing reading on other topics, but it has allowed me to be much more focused than I normally am. I wouldn’t want to spend all my time doing this sort of thing (Sustainable Pace again), but doing it occasionally is refreshing.

I spent this morning at a talk by Mary Poppendieck on lean. It was billed as a tutorial, but there were too many people for that, so it ended up as just a talk. As far as I can tell, the main thing that I missed from its not being hands-on was a chance to do my own value stream mapping; too bad, because I think that’s a useful tool and I’ve never tried it out, but I don’t see it as being directly applicable to my situation.

Pleasant enough talk, but pretty familiar, given that I’d read the Poppendiecks’ excellent book. One thought that it did bring to mind: she brought up the fact that 3M and Google both encourage their engineers to spend a fair amount of time exploring whatever suits their fancy, and gave a queuing-theory justification for this. So: should we institute such a policy at work? What would be the effects, both positive and negative? Does the queuing theory justification really hold up; if so, does it hold up for reasons that are applicable to us?

One concrete situation where I think we might benefit is that one of my coworkers recently posted a list of gripes about our house coding practices on our wiki. I think there’s a lot to most of his points, but it’s hard to find time fixing them; if we had a bit of slack, though, perhaps both he and I would spend a bit of time tackling the issues that bugged us the most, which might help our morale and increase general productivity going forward. Hard to say, though, and I don’t think that’s the sort of benefit that Google and 3M get.

The afternoon talk was a workshop by Ron Jeffries and Chet Hendrickson on “Crushing Fear under the Iron Heel of Action”. The first time they’d given the workshop; an interesting experiment. The core of the workshop involved breaking up into groups where we each talked about some sort of fear we had, and dug deeper into it and talked about specific actions we could take to address the fear. Then we talked about what each of the groups had produced, and talked about common tactics (and, to be honest, had a bit of a therapy session): fail early and often, test your fears, hold retrospectives to address your fears, some people skills issues, many other things that I’m forgetting.

Fears are certainly a bit of a theme for me during this conference; I hope that I’m starting to get better about acknowledging and confronting them in productive ways (though I feel a bit too lazy / other to talk about details of that right now), but it was heartening to see all of us come together, address fears, and come up with concrete productive actions to deal with them. It gives me hope that I’ll be able to do so in the future.

(Don’t get me wrong: there aren’t any crushing worries that I’m laboring under or anything.)

The first session I went to this morning was on systems thinking / causal loop diagrams. They had us go through an exercise throwing balls around, talked about states of the system, and showed diagrams that explained the different states (why performance increased, then leveled off, then went down).

Pretty good; I’d seen the ideas before in Quality Software Management, but never put them to use. And I suppose that talk will increase the chance that I’ll give them a try. The problem is finding the right time - like other forms of root cause analysis (e.g. five whys), I’m afraid that I’ll be too clouded by my biases, so I’ll end up just uncovering what I already “knew” was the problem instead of really figuring out what’s going on. So I should give them a try in a situation where I’m genuinely confused, I suppose.

Then I went to the open space to talk about lessons from waterfall. Nobody came other than Arlo Belshee (the convener) and myself, but I enjoyed spending an hour chatting with him. He talked a little about what lessons he thought we could learn from waterfall (risk management, configuration management, one or two other things I’ve forgotten), I talked a little bit about pain points in my current project that could probably be mitigated by these techniques; a pleasant way to spend an hour.

I spent all afternoon in a tutorial on coaching; really good, and I really wish I’d attended such a training a year or two ago. Actually, to be honest, I wish I’d managed to pull in an external coach a year or two ago, because I neither had sufficient agile skills nor coaching skills to bring off a successful transition. Or, for that matter, skills in retrospectives, which is still an issue and which I’m hoping to remedy on Thursday; and I made several mistakes related to not having the courage of my convictions (most noticeably my not pairing enough, which I think had strong concrete negative effects on the team), which perhaps yesterday’s leadership talk will help with in the future. So there does seem to be a coherent theme to my choice of sessions to attend - it would be nice if it were fighting the next war instead of fighting the last war, but there are worse themes than the latter.

The core of the tutorial involved going through four role-playing coach/other sessions (where “other” was sometimes a (project) manager type and sometimes a developer). We did this in groups of four (two of whom were roleplaying and two of whom were observing at any given time), plus somebody with coaching experience. We went through each scenario once, then talked about it, then went through it again. Very helpful hands-on experience, and I learned a lot each time, whether role-playing either side or just watching. (I apologize to the coach roleplayer for my excessive recalcitrance when roleplaying a PM.)

One nice thing was the way it reinforced some of the stuff I’d gotten out of manager training at Sun: let the other people speak, empathize, don’t try to solve problems directly, don’t even approach the idea of solving problems until they’ve had time to vent first. The more they can recognize problems and suggest solutions, the better. I felt a lot more comfortable role playing this time than I did during manager training; I guess I should spend more time putting these techniques into use.

The guest coach at our table was James Shore, who was very pleasant to talk to, had many useful comments, and did a nice job modeling acting as a coach on a meta level. If people are looking for coaches to bring into their organization for training, I suspect he’d be a very good choice.

I also drew my first mind map today. The presenters from the first session I attended yesterday were trying to get the notion of mind maps to spread virally - handing us out stickers, and encouraging us to teach mind maps to other people, who would then get a sticker on their badge, plus some stickers to give to other people as they in turn spread the teaching. Which mostly annoyed me - I don’t particularly care if some people can successfully spread a concept virally throughout a conference - but I actually did want to learn how to do a mind map. (The fact that the presenters didn’t actually teach us how to draw mind maps was actually the one aspect of the viral spread that I did like.) James had a sticker, so I asked him to show me how to draw a mind map, and he got me to draw one; yay. I’m still not sure how widely useful I’ll find them, but I’ll give them a try a few more tries.

I believe there’s supposed to be a get-together tonight for people who participate in the various mailing lists; it will be nice to put faces to names.

And now day 2 is over. Better than day 1: I enjoyed all four talks that I went to, and hopefully got something out of them.

One of the problems that I have is figuring out which talks to go to. I have enough agile experience that I’ve been avoiding the beginners’ tutorials. The main basic practice where I feel lacking is in customer (or Customer) interaction; I’m not sure that my problems in that regard would be best solved by going to a tutorial on the subject. On the other hand, I’m hardly a grizzled veteran - maybe I don’t know my own ignorance, so maybe there’s really important stuff that I would learn from tutorials (on that or other subjects) if ony I went to them.

Still, that’s one way to narrow down the options, which is important given the large number of sessions to choose from. (And then there’s the open space stuff which is getting organized ad hoc, and which past attendees say can be the most rewarding part of the conference.) But it would be nice if I had a more positive approach toward selection: is there something that I really feel that I’m missing, and need to learn about? I don’t have a great answer there, either.

So, in retrospect, I should have approached the planning in a bit more TDD-ish fashion, with some idea of acceptance tests before starting the conference. Oops. Most of the sessions look interesting; if several all look approximately equally most interesting, my first coin flip is how easily I could imagine using it at Sun - they’re sending me here, so they should benefit. But if something is much more interesting but less directly applicable, I’ll go to it instead - I know from experience that I’m much more productive when working on things I’m interested on, and that it’s hard for me to predict what actually will end up being useful in my future life.

If any of my coworkers are reading this while the conference is going on, feel free to go to the conference web site and suggest sessions that I should attend. Or any of my other loyal readers, for that matter.

Anyways, enough blathering. In general, the theme for sessions that I attended today was bringing about change. I don’t think I have too much concrete to talk about what I learned, but it was interesting hearing reports on the subject from several fronts. And I got some good book recommendations out of it. Not clear directly how this will apply at work - it’s not even clear to me in what circumstances at work it’s appropriate for me to be an advocate for change - but I hope it’s not completely irrelevant.

The talk by Christopher Avery on leadership was worth mentioning, if for no other reason than that it was an interesting counterpoint to an earlier blog post. Like Holt, Avery makes the point that responsibility is important and doesn’t mean wallowing in guilt and blame. And like many consultants, he has a list of stages; his is “Denial, Lay Blame, Justify, Shame, Obligation, Responsibility”. In any given situation you typically proceed through these steps, frequently getting stuck at one; you may also go to a special stage “Quit” at any step of the process.

The interesting thing here is the stages “Shame” and “Obligation”. Saying “yes, I screwed up, that’s my fault” would frequently be called taking responsibility; and, indeed, it’s much more responsible than the earlier stages of blaming other people or explaning away the results. But it’s ultimately lacking: it’s all well and good to accept blame for something, but if you just leave it at that, you haven’t done anything to improve the situation, so it’s still a way of avoiding responsibility. Similarly, doing something because you feel obligated to even though you really don’t want to do it is better than flaking out; but it still isn’t a way to constructively move forward, because there’s probably a problem somewhere that should be dealt with but isn’t.

Not entirely clear what I’ll do tomorrow. There’s a tutorial on systems thinking; I could learn something from that. I think I’ll go to an open space discussion lead by the promiscuous pairing guy on lessons we could learn from waterfall. That will cover the morning; the afternoon is less clear to me. Also, somebody is giving a tutorial on C++ unit testing in the morning; I don’t want to attend, but I should probably track down the speaker after the talk to pick his brain.

The first day of Agile 2006 is now more or less over. It was just a half-day, really: only afternoon talks, and I don’t think quite everybody is here.

I went to a couple of presentations. The first wasn’t too good: it was billed as talking about how agile had changed since the manifesto, but ended up having people talk/fill out cards about various aspects of their experience, with minimal analysis/insight, and overrunning its time box to boot. (I though agilists were supposed to be good about that?) The second was rather better: Scott Ambler talking about data he’d gathered about the penetration and effects of agile practices. Nice that somebody’s trying to gather data, and apparently doing a decent job (though it wouldn’t be too hard to find places to doubt the methodology); also nice that almost nobody thinks they’ve been hurt by adopting agile practices and most people think they’ve been helped.

There was an icebreaker. With some DDR pads; you’d think that, in a room full of geeks, some people would be drawn to video games, but that turns out to be the case. I don’t know how much of that is fear of dancing and how much of that is age. I also talked to Mary Poppendieck for half an hour or so, pumping her for information about lean. Most kind of her to spend the time; that’s the high part of my day.

The wifi in the areas where the conference is actually taking place is free; I’m using that now.

I also finally got around to making tar files of my unit test framework; the latest version should now always be available at http://unittest.red-bean.com/tar/unittest-latest.tar.gz. Yay.

I’m off to Agile 2006 tomorrow. Should be interesting; many thanks to the powers that be at work for sending me there.

I wasn’t sure what I thought about this article on removing warning signs when I first saw it, and I’m equally confused by this one. On a basic level: does this really work? I’ve never driven in Europe, I’ve never been to Italy at all, so I don’t have much context for many of the examples. If it does work there, would it work in an American city? (Doubtless better in some than in others.) Would it work in the more suburban area where I currently live? It’s hard for me to imagine techniques that would naturally cause cars to want to travel under 20mph here. And then there’s Green Streets…

The second mentioned article is the one I’ve been thinking about more, because of my current lean obsession. I’ve been on a bit of a slow driving kick for a couple of years, so I actually do frequently come to a complete stop at stop signs, but I would tend to agree that doing so doesn’t make my driving any safer - it just slows me (and potentially other people) down. (And wastes gas, too.) To be sure, my slow driving has flow benefits as well - if I see a red light ahead of me, I just coast, which has the benefit that I’m more likely not to have to come to a complete stop at the light, giving me a speed advantage. (And saving gas in two ways.) Go production leveling! Of course, you have to be a bit careful: if you cut the timing on the light too close, you can get killed by somebody running a red light. But in general asking the question “is holding down the gas pedal going to improve my total time, or is something else the bottleneck?” has had pleasing affects on my driving.

But what I’m really confused about is this: on the one hand, we have the idea that adding explicit safety (or quality) warnings is actually less safe than encouraging people to pay attention to natural environmental signals. Which I think I’ve seen in other lean sources, though I’m not completely sure that it’s canon; I’m also not completely sure I believe it, but it’s plausible enough. On the other hand, lean also heavily promotes certain kinds of quality signals, so you can tell when something has gone wrong as quickly and as immediately as possible. So: how do I tell the good sorts of quality warnings from the bad sorts?

I would like to say that I know it when I see it, but a bit of testing shows that that isn’t the case. Is pair programming a good sort of quality signal, encouraging a constant flow of dialogue about the process and hence heightening awareness? Or is it a bad, rigid, rule that’s a detriment to flow and encourages people not to pay attention to what’s going on because surely their partner will catch the problems? Or is it orthogonal to the issues raised by these traffic articles? I tend to think that pairing is more good than bad, but it’s not at all clear to me how to derive that from general principles. (And maybe this is a sign that we’re doing the right thing at work by not pairing all the time.) TDD raises similar questions to me - good, bad, excessively rigid, creating an informative environment, something else entirely? Again, hard for me to analyze, though here I’m rather more confident that it’s almost universally a good idea - you’ll pry my unit tests out of my cold, dead hands, and red, green, refactor is a wonderful way to work. (But perhaps those wonders, especially the design benefits, are orthogonal to these issues.)

Always more to learn.

• We feel fine.
• Ed Felten goes ski jumping.
• Lean healthcare.
• Trained to fear.
• Visual complexity.
• Files are not for sharing.