favorite lines from More Secrets of Consulting by Gerald Weinberg

Sometimes I wonder whether these kinds of posts annoy my readers or not--but since this blog is equally for the author as for readers, I opt to include it. I like to attribute ideas to their sources whenever possible, and every once in a while I want to look things up that I've forgotten. I often can do a keyword search on this blog, and turn up the title of the book and even a bit more context--it may be enough to jar my memory, or from this I can more readily locate the correct section in the book itself, since I've dog-eared and underlined the same things I mention here.

First off, I have to say that I find Weinberg's Secrets of Consulting books thought-provoking yet too informal. He's a story teller, and gives crazy names to all his secrets--this is probably one of his undocumented secrets, in fact, since names like the "law of raspberry jam" have left a visual image in my brain that quickly brings up his lesson. I like easy to read books, but I like them to be more direct. On the other hand, if it weren't for all these stories, it's possible I'd learn less from what he wrote.

This second book builds upon the memory tricks by recommending we build a "consultant's kit" that includes over a dozen physical objects that will help us remember what to do when we have a problem:

• the golden key: we have the power to unlock more doors for us than anyone else / "when you stop learning, it's time to move on" / "there are many ways to put people to sleep with words" so sometimes the best thing to do is stop talking, or listen beyond lullaby words / you've never tried X, or don't know anything about X "up until now"
• the courage stick: when we're afraid, find something we're even more afraid of to get us moving / "the key moment in a relationship occurs when one or both [people] feel there's something that can't be talked about" and then he pictures what happened to people that didn't talk about the taboo subject / "whatever the client is doing, advise something else" / Loftus' Law: "some people manage by the book, even though they don't know who wrote the book or even which book it is"
• the wishing wand: it's best to let people around us know exactly what we want, because then there's a chance they can give it to us; don't filter--leave that for negotiations later
• the detective hat / magnifying glass: we need to see the data ourselves, not just the conclusions our customers have made / don't be mesmerized by the first problem you find / the closer you get to the culprit, the less likely you are to get the answer / use their questions as information
• the yes/no medallion: it's important to be able to say no if it's not a good deal for you / sometimes we can say no by thanking people for their invitation, then saying it's not the right fit at this time
• the heart: "if someone requires you to die trying to help them, you don't want to help them" / if you get involved in projects that require your mercy to succeed, they're not likely to succeed anyway
• the mirror: why am I here? / how do I feel about that? / what do I want to happen? / feedback is a reminder, not a reproach (everyone is always trying to be helpful)
• the telescope: zooms in on how other people are doing / center yourself; empathize; pivot
• the fish-eye lens: look at the context / "the fish is always the last to see the water" / listen to the music, rather than the client's words
• the gyroscope: "if you want to stay single, look for the perfect mate" / you can't be perfectly rational, congruent, or consistent! / trust your body, then your brain / "a professional is someone who does a good job even when he doesn't feel like it"--but excellence only comes when we're really on / Qualified-but-Quiet Quandry: the more you ask for help, the less you'll get stuck--but it's hard to ask for help when people think you're the expert!
• the egg: we can always grow & try new things
• the carabiner: find ways to make safe experiments, where failure is OK, and even expected as a sign of creativity and growth
• the feather: keep it light! being too serious inhibits our creativity. play! don't make such a big deal of things, because in the grand scheme of things, the universe doesn't really change
• the hourglass: why do we never have the time to do it right, but enough time to do it over?
• the oxygen mask: competence can lead to burnout / this is about breathing and vitality--energy--a balanced and energetic life

fan of Jurgen Apelo

Since Jurgen Apelo invited agilists to contribute to his new Management 3.0 blog, I decided I'd support his project by writing something myself. I called the article Estimation Causes Waste, Slack Creates Value. I'm a big fan of Jurgen's blogging, and look forward to his upcoming book.

on the job market

Do you know anyone looking for a director-level software development manager? I'm on the market, aiming to find a position for September in Philadelphia or the region.

I'm looking to be a manager of software development, preferably at the director-level, responsible for a team of maybe 3-5 intermediate managers. What I'd like to do at my next position is build long-lived teams who get to know the business well and can pivot the product line towards ever-increasing opportunity and profit. I'd be happy to work for a business that has demonstrated profitability or for a lean startup. I know the difference between leadership and management, and have done both.

I used to be driven by software and technology hurdles, but over the years I've refocused on people issues--moving from managing small teams to coaching, and even trying out product ownership. For more information, browse my blog archives, my achievements, see my resume or recommendations. Please note that for my most recent position, I've been working in a French-speaking environment, and so I asked for reviews in French. If you want a translation, you can ask me or use Google translate.

Conference Talk on Focus and the Pomodoro Technique

A colleague and I (thanks, Olivier!) presented the following talk on the Pomodoro Technique. Attendees were intrigued by the content, but the exercises needed some work. Olivier presented it again later in the month and it went much better... our experiments with small focus groups didn't scale out well to 10-15 people per team. The second time around, he increased pressure and scope creep by doing the following.

5-minute challenge: brainstorm as many tips as possible across all categories below. Make sure you get about the same number of words in each category. One person holds a dry-erase marker and notes ideas; no duplication allowed within lists.

• fire prevention
• road/driving safety
• professional hazards

5-minute debrief: count how many ideas were generated for each category. Ask how things went, and what was noteworthy.

5-minute challenge: same as challenge above, except we work one category at a time until there are about 20 ideas, then move to the next category.

• flu-prevention
• household child safety
• names of TV shows

5-minute debrief: was one strategy more effective than the other?

10-minutes: Introduction to the pomodoro technique.

15-minutes: how we tailor the technique to a team environment and meetings, Q&A

the cost of team-building

Part of what makes team-building so hard is its cost. There are personal costs, political costs, and organizational costs--plus the cost of time. Yet people who've been on a performing team often want to get back on one, and managers are often hoping to create them. I think that listing some of the costs may help us understand the resistance to team-building / gelling:

cost	benefit
loss of independence	we accomplish more than we'd do alone
increased visibility of mistakes	our team is there to help us when we fall
increased visibility of weaknesses	" " "
with more trust in teammates comes more vulnerability that they'll let you down	more connection and support
full presence requires more energy	we relish more in our success
decreased recognition from management for individual contributions	much more constructive feedback and learning opportunities from peers
organizations lose some control when a group has gelled--a self-organizing team does what it chooses, rather than always doing what the organization has requested	unprecedented levels of productivity and value

polyglot list serves

On the Agile Tour organizer's list this year we adopted a list serve culture I haven't seen elsewhere--members are invited to type in their native tongue, and liaisons (like me) translate the text to English. Everyone has decent reading comprehension of English, but may find it hard to write in it. This makes participation in the list easier for almost everyone... Have you participated in a list like this? What kinds of language- or process-related problems have you encountered?

fan-out release planning

What is Fan-out Release Planning?

Fan-out release planning integrates set-based design, weekly intermediate deliverables (and validated learning), sustainable pace, top-down budgeting, risk management, and deliberate prioritization to deliver a valuable product in sync with business, marketing, and sales plans. We do this from a Product Owner's perspective by selecting epics for the release, establishing a budget for each topic based on the business value, reality-checking the expectations with the development team (and trimming scope as necessary), and then scheduling the work strictly in order of priority, stopping development when we've run out of time.

The differences between fan-out planning and traditional XP planning are:

• an emphasis on exploration, especially during the beginning of an iteration/release
• top-down scheduling
• an explicit allowance for functional debt until the end of the release. (Functional debt, for example, is present in a new file editor that allows us to create and save documents, but not yet load them. We could address creating and saving first because the team identified these functions as the most risky, and identified a fail-safe plan of using a plain-text editor to display the files if we don't get a chance to work on loading/rendering issues. This gives us more time to focus on the core value provided by our editor, for example, auto-completion.)
• an emphasis on slack time, both creative and buffer slack

We use fan-out planning at an iteration level for cards that we can't readily estimate (because the solution or need is vague). Instead of doing pre-work on a card in an iteration before a story has been slated, we'll schedule it without an estimate, and let the team say what is feasible during the week. What does this do to a week's commitment? It makes it more fluid--people do the work that they can. The goal is to find the essence--the core value of a card--and do something that will yield feedback (validated learning). Normally an un-estimated card only produces a spike or more cards with estimates, but if the developers who took it find the work easy and relatively small (less than a day), they'll often move it to Done-Done. In any case, we have something to show for the work, that can be validated with a client, and we've left the production code in a healthy state (often by using options that hide new features).

Why Change the Planning Game?

Traditional XP release planning leaves little room for slack, and as a result, I think it doesn't get as creative. We also see cycle-time waste when we're doing analysis for story cards that aren't going to be picked for an iteration or more. So instead of nailing things down enough for estimation, we just 'take it offline' and talk when the card has been picked. This can be risky, because bottom-up scheduling and estimation protect a team's sustainable pace. We counter-balance this risk with adequate slack.

Another benefit of fan-out planning, counter-intuitive as it may be, is the increased predictability it gives us. It may be a bit premature to say it, but we've been doing fan-out planning for about 15 iterations, including one major release, and we find we are more capable of responding to changes in the market place, more capable of finishing strategic plans, and more predictable. By always focusing on the absolute minimal feature set, we gave ourselves enough slack to become predictable.

When we're beginning a new release, we need to provide some visibility to our marketing, sales, and support teams about what's coming with the next version of the product (we make internal releases each one-week iteration, and sometimes deploy those intermediate deliverables to a new client, but most existing clients only upgrade our product every 3-12 months). There's a lot of risk involved in promising a fixed scope with a fixed delivery date--so instead we commit to a delivery date and a vague set of release goals/epics/themes. By using fan-out planning, we attack several candidate solutions, show them to our stakeholders, and wait until later in the release plan to commit to a particular solution.

Does this sound familiar?

Fan-out release planning is, as far as I know, unique to my team (but inspired by XP, Scrum, and Lean ideas)--and I'd be happy to hear about other teams that are doing something similar, or about any resources/books that describe it, or of any concerns you might have about the process!