staying current

For the last few years I've been on a quest to find out what other Agile/Lean practitioners are doing, saying, and thinking about, so I can learn more myself--and to do so I've accumulated quite a daily reading list: I'm on 15+ mailing lists, 23 blog feeds, and follow 30 people on twitter, not to mention the books I read. I really try to minimize this reading list, but I also have this unquenchable thirst to find something I've missed--something that will help me work smarter, to improve, to do better. I've often said that as a professional and practitioner, it's my job to study outside of the workplace--to learn about how other people are solving similar problems in different contexts. I think that all this reading gives me a lot of ideas in the workplace of how to approach problems, so I keep reading more.

Yet reading isn't enough. I need feedback--I need to hear how others perceive my words, and to see how they respond. So I also write, here and on twitter, but primarily on mailing lists. I post whenever I have an opinion that hasn't already been stated by someone else on the list. This helps me learn when other people argue in favor of or against what I've written. Here are my favorite mailing lists:

International:
 http://groups.yahoo.com/group/extremeprogramming/
 http://groups.google.com/group/lean-startup-circle
 http://groups.google.com/group/agiletour

 http://groups.yahoo.com/group/agileprojectmanagement/

 http://groups.yahoo.com/group/leanagile/

 http://groups.yahoo.com/group/leandevelopment/

 http://groups.yahoo.com/group/AgileBusiness/

 http://groups.yahoo.com/group/Agile-ANN/

 http://groups.yahoo.com/group/agile-jobs/
Extreme Programming (LinkedIn)
Agile (LinkedIn)
Agile Alliance (LinkedIn)
Agile CMMI (LinkedIn)
Agile Philly (LinkedIn)
Agile Tour (LinkedIn)

Philadelphia:

 http://groups.yahoo.com/group/agilephilly/

 http://groups.google.com/group/leanstartupphilly

 http://groups.yahoo.com/group/phillyaltnet/

 http://groups.yahoo.com/group/phillyjug/

Other Regional:
 http://groups.yahoo.com/group/software_dev_in_free-county/
 http://groups.yahoo.com/group/Agile-Belgium/
 http://groups.yahoo.com/group/xp-france/
 http://groups.yahoo.com/group/xp-forum/

Writing isn't enough either. I need face-to-face, peer interactions. So I go to user group meetings and conferences whenever they're local, and a few that are remote, as often as possible. This always poses work/life balance problems for me--I'd love to go to even more events--but I also really enjoy time at home with my kids... Still, these face-to-face events are a great way for me to talk about work outside of work, to get other people's opinions on how I might apply my learnings more directly, and to practice my skills in a 'sandbox'.

User groups/conferences aren't enough either. I need a place to apply my craft on a daily basis. I need an environment where I can apply all these ideas I'm absorbing, then to watch to see how the seeds I planted will grow. I've been very particular over the years about what kind of environment I'll work in--and it's given me a good base to practice and learn even more.

What are you doing to stay current? Do you have ways to stay current that I've missed?

mavens and The Tipping Point

There's a great quote from Malcolm Gladwell's The Tipping Point that just has my mind reeling. I can only paraphrase it right now: in an age of information overload, we rely on word of mouth to deal with complexity. The word of mouth we rely on, this primitive communication, all comes from specialists in our network. These specialists, who Gladwell calls mavens, can provide the best kind of product referrals, distilled information, and advice because they're simply obsessed with data in one or more niches. He says that it's a certain kind of person--but I'm inclined to believe we're all vessels of trivia in some category or another. This becomes important when we think about how to promote learning / competency / agile skills / decision making / etc. If we could use a networking tool and nominate our friends as mavens on one category or another, we might benefit better from our networks... is there something that already does this?

From Weak Links to Better Answers

Some of the implicit questions driving me for the last couple years in the work I did for the Agile Skills Project were: how do we know who to trust, who has good advice, and who should we hire? The answer to these questions have a lot of value, as proven by the market demand for CSMs and other tech certificates, as well as for the hefty price recruiters get for matchmaking services. Yet when these matches depend on keywords in a resume, or on a recruiter's personal network, we hit one of two limits: keywords don't convey trust, and humans have a neurological limit of about 150 trusting relationships. So how do we broaden our searches for advice and/or recruits beyond 150 people? It's easy for clear-cut, objective answers--we can depend on the wisdom of crowds using things like Google's page rank algorithm, which represents the crowd's endorsement for certain advice. For more subjective questions, though, it is much more complicated.

Yesterday I read about weak links / weak ties in Enterprise 2.0 by Andrew McAfee--it reminds me of the fabric Peter Block identifies as social capital--and apparently the research about exploiting our personal networks was published relatively recently, in 2004 or 2005. McAfee suggests that the next way we'll be able to benefit from platforms like LinkedIn, Twitter, and FaceBook will be in referring our colleagues to our FAQ pages. This strikes me as really powerful for objective questions, but misguided for subjective questions. It's not the answers that my network of friends are useful for--it's the diversity of approaches they offer that is important. Since it's a subjective question, it is the analysis of factors, values or forces that will help guide me. I don't know of any scalable resource that connects people for subjective questions in this way. Do you?

There are technologies that connect people by the questions they ask--take the Stack Exchange engine for example. Yet they specifically close subjective discussions:

...questions that are not answerable — discussions, debates, opinions — should be closed as subjective. It seems simple enough: Fact good; opinion and discussion bad. But why?

Most forums and chat rooms have a scale problem. As in, they don’t. The more people that join the discussion, the more noise each of those connections bring. So the forums get progressively noisier and noisier, and suddenly one day … you stop learning.

This seems to leave a gap.  Subjective questions often produce conflicting advice on list serves. How do we sort through the answers? I don't see any of these social media platforms helping me decide who to trust. What if we built a community of questions and analyses--no answers permitted, just a catalog of the values, forces, etc. that go into making a decision. Anyone want to help me out? The first place I might begin is at Stack Exchange--but we'll need about 250 committed users to go live. Let's work out some of the details first--post your questions/comments here. One thing I will have to work out near the end is the name--should it be DevIntent, Philly Tech Points, Agile Welcoming Circle, or something else?

Would you such a site useful? Would it help you answer your questions? Would you participate in it?

Agile Tour Philadelphia 2010

This year, Sebastian Hermida, Bonnie Aumann, David Bulkin, Ravindar Gujral and I tried out a new conference format--and it worked out splendidly (photo album). Essentially, we wanted this to be a conference for local practitioners, by local practitioners. We sought to encourage networking and group discussions, so we divided up our 4-hour conference into a keynote by Jon Kern followed by 4 x 45 minute-long sessions and a little time for breaks. Each of the organizers invited a friend to do a talk, and we got a great lineup including:

• Bonnie Aumann (The Flow Game)
• Aman King and Prashant Srivastava (Agile Buzzwords in Action)
• Sebastian Hermida (9 simple rules for code design)
• Prem Chandrasekaran (Automated Functional Testing: Getting it Right)
• Burkhard Duemler (An Incremental Move to Continuous Integration)
• Ravindar Gujral (You Get What You Measure)
• Audrey Troutt (How Agile is like Yoga: this $h!t is really hard but it feels good)
• Daryl Richter (Don't Replace That Old Application, Re-upholster It!)
• Andre Dhondt (Working with Difficult Customers)
• Brian Donahue (Software Craftmanship: Building a Solid Foundation)
• Darian Rashid (Personality Types)

At the beginning of each session, all 70 or so attendees met in the middle of one large conference room, and speakers each had a chance to do a 60-second lightning talk to catch the interest of attendees, and to announce where they'd be doing their talk. Within ten minutes everyone had shuffled over to their chosen sessions, which lasted 25 minutes before a 10-minute break and then another round of lightning talks. This format gave people a lot of time to meet one another and explore topics of their own interest--which kept energy high and made it really fun. As an organizer I felt responsible for making things flow--so I couldn't fully participate in any of the sessions, but I did act like a butterfly and go listen in on at least a couple minutes of every talk I could.

the Philly Agile community

In the 9 weeks since I've been back to Philly, I've been able to attend about 8 events (hosted by Agile Philly, Philly SPIN, and Lean Startup Philly, and I missed one I wanted to go to--Philly ALT.NET). It's such a vibrant community!  For the past couple years I've been trying to blog about every event I attend--but I'm having a hard time keeping up this time. So this entry will try to capture some of the highlights.

Lean Startup Philly is reading a book together: Steven Blank's The Four Steps to the Epiphany. We meet at lunchtime weekly to talk about the book and then how to apply its principles to the startups each of us are involved in.

Philly SPIN had a packed house for Jim Schiel's Sept 22 talk on "Quality and Productivity Metrics in Agile Development". Since I'm a big skeptic of any kind of productivity measurements, I was really curious to see what this meeting would be about. I asked a lot of questions to see how Lean/Kanban principles were being applied in the context of his clients--and basically, I get the opinion that the Scrum community seems very straight-laced. It's interesting to me because the XP community has stayed very open to changes, doesn't seem to claim intellectual property over its ideas, and often incorporates new things. Jim began his talk with a couple of really great questions--if we don't have big, up-front design documents and estimates in projects, then how can we tell if we come in ahead of schedule? How can we tell how productive we're being? I'd love to have an answer to this--though I don't know if there really is one. Software development can't be about efficiency, it's got to be about effectiveness. So then Jim continued on to talk about how high quality is a necessity for being productive, as well as being able to incorporate change into the plan, how we need to avoid overworking the team, and that we need to be cautious about what we measure. He proposes using the following measurements, not as a way to gauge productivity, not as a way to compare teams, but as indicators that there may be a problem, or even that things may be improving:

• change in velocity
• change in defects
• number of completed stories

Agile Philly has had two Code Kata nights. At the August 24th event we tried some Architectural Kata, by working from the dry erase board. Though we didn't actually use our computers this time, it was a great chance to work on collaborative design, and I learned a new technique from Sebastian Hermida, who will be presenting it next week at Bar Camp Philly. On his teams, they wanted to get everyone involved in all the architectural decisions, so at daily sprints they'd try to sell their implementation strategy--and team mates could buy or not. If not, that triggered further discussions. Later, after coding a story card complete, the pair will again try to sell the card--to make sure everyone is on board. It sounds like a fun and innovative way to encourage team ownership of the design of all the code.
At the next Coding Kata event on Nov 4, Audrey Troutt led us in 10-minute pair rotations for the bowling game using Jeff Bay's 9 rules for "Object Calisthenics". It was really intense, really fun, and felt great to think about how we write code. We paused half way through and talked about what was happening, then spoke again at the end about what we might want to do differently.

Agile Philly also hosted an Agile Tour stop this year. I'll write about that separately.

just got banned from a list serve

Here's my first post since I re-located from France. My new job has been so time consuming I haven't yet found the time to write--but I just got really worked up about a list serve I've been on for years, and so I decided to skip my run and make a stand. I'd really like to keep this from getting personal against the moderators, so I'm not going to say who did this--but here's how I see the sequence of events leading to me getting banned:

• the list, as I understood it, was created primarily as a forum for users to discuss ideas and experience reports, as well as get periodic updates to the products
• about weekly, the list owners sent announcements
• a relatively new member of the list asked if the quantity of 'product update' messages could be reduced   

This resulted in a really defensive note saying that the product updates were not spam, followed shortly by a lot of disagreement from various members of the list. Rather than acknowledging the disagreement, the moderators came out with the following statements:

Premise - This mailing list is the Official <X> group.

The <X> Team moderates and organizes this group.

We had a serious look at whether we should continue the group’s activity.

...The fact remains that this is the Official group of <X> and the <X> Team must be free to put forth any message it wishes; whether it be relating to events, courses or products. It may also decide to not send this sort of message at all.

But considering that this list is run and organized by the <X> Team the final decision lays with the <X> Team and not the members on the list.

If the participants in the group do not appreciate the messages that are being issued or the policies chosen for sending the messages, they have two choices;

(1) show their disapproval by sending an email to the group’s moderator or

(2) leave the group.

These are the group’s rules.

Any behaviour contrary to the rules means that the person will be automatically removed from the group.  <X> are the moderators of this list and we will ensure the rules set out by this group are obeyed.

If you partecipate in this group you know you will receive messages about news, events, courses, products related to the <X>. (As is clearly stated in this group’s welcome message)

Should you for any reason consider our rules and policies to be spam, just leave this group. We are obviously incompatible.

Do you think this group should be different? Create one yourselves.

Should you wish to create your own non-official <X> group, you will nevertheless still have our help.

...We consider this issue closed, any off-topic message must from this point on be sent to one of the moderators following the group’s rules.

Keep in mind that the spam doesn't bother me enough to leave the group... so I stayed. Yet the hierarchical, dogmatic attitude above does bother me. So I wrote to the moderators, off-list, saying that I think the quantity of spam notes (20 this month) is hurting the list.

Then I started wondering what would happen if they tore the list down, so I sent the following, which seems to have gotten me banned:

<X>To avoid more spam we are considering closing this group... 

Hi all, if they do close this list serve, please move your discussion over to http://groups.google.com/group/<X>

If you sign up now, it will make a strong statement that _this_ list serve is owned by us, not by a company.

Now I'm waiting for them to respond by linking to the user group from their web site. I'm not holding my breath, though.

Make all your Obstacles into Opportunity

The other day we lost power at work--and realized it was not just our building, but an entire zone of the city. So we took advantage of the time and played a team-building game I had prepared in advance, with no pre-conception of when, or if, we'd be able to use it (thanks to Aurelien for pointing me Tom Wujec's Marshmallow Challenge):

We first did the challenge according to the rules. The tower that Christophe and Julien built empirically, bit-by-bit, won. The over-engineered version didn't reach completion.

Christophe and Julien, Victors!

Couldn't quite finish...

We did a de-brief, but I don't want to write a spoiler. Try the game yourself... the person who reads all the instructions at www.marshmallowchallenge.com will lose out on the experiential learning, but will still have fun.

Then we played a bit more, without time constraints. We all wanted to know a bit more about what was possible with string, spaghetti, and marshmallows. This time the most structurally sound design won:

Franck and Christophe with wobbly sphaghetti

Sylvain and Olivier, Grand Designers

Addiction, Totems, and Giving

Addiction
This is my technical blog, so I'll try to avoid getting too theological--but when I'm talking about what's closest to my heart, my true passion, it really does border on incoherence, spirituality, and insanity. That's probably as it should be, because it's our creative minds that see what's beyond our current perception of the universe. Without this borderline insanity, how would we be able to change the is to the could be? So please bear with me, and leave comments to help me see where my ramblings aren't clear.

Recently I made the difficult decision to return (with my family) to my home in Philadelphia, after a 2-year adventure working in France. So, I've got big changes ahead--an international move and a new job. It's making me nostalgic, question my values, and reflect on what I've done. An essay by Paul Graham recently triggered even more reflection on my values: he talked about Addiction. It really made me wonder whether I'm addicted to anything. The most likely candidate for me is the internet--but as I read from Wikipedia:

The American Society of Addiction Medicine has this definition for Addiction: Addiction is a primary, chronic disease of brain reward, motivation, memory and related circuitry. Dysfunction in these circuits leads to characteristic biological, psychological, social and spiritual manifestations. This is reflected in the individual pursuing reward and/or relief by substance use and other behaviors. Addiction is characterized by impairment in behavioral control, craving, inability to consistently abstain, and diminished recognition of significant problems with one’s behaviors and interpersonal relationships. Like other chronic diseases, addiction involves cycles of relapse and remission. Without treatment or engagement in recovery activities, addiction is progressive and can result in disability or premature death.

Furthermore, addicts often are in denial--saying they choose, and like, the activity, to the extent that even when something catastrophic happens they still insist they want it--but in reality they have no control. I find this definition problematic, because if clinicians can't diagnose addiction until something bad happens, it doesn't do us a lot of good in preventing these accidents.

Totems

So if addiction is the point at which a person can no longer heal oneself, and as Graham argues, we live in an environment that is getting more and more addictive, we need warning signs that work better than what we had in the past. He says that traditional, cultural, and social means for controlling addictive behavior are insufficient. For me, this is where Totems come in.

A Totem, in pre-historic times, was an animal with a spiritual connection to an individual. When that person was in trouble, the totem often showed up to help. Many cultures have used totems or icons of human form in various ways, leaving traces behind in the form of statues, idols, and carvings in temples, churches, roadways, and homes. Imagine traveling by foot for hours, coming around a corner and seeing a huge statue or relic like this, pictured right.  It is inspiring, centering, and powerful. Even today many people use descendants of totems in the form of physical charms, to keep them centered.  Take, for example, Jerry Weinberg's consultant's kit--a box full of simple tools to remind him what to do when he has a problem.

As you may have noticed, though, the prevailing use of totems has evolved from the mystical to the symbolic.  Consider how in ancient times people considered that the animals would come to us, then there were statues that happened to be along our route, and now there are charms we bring with us or place lovingly at an alter in our homes or places of worship.  All are powerful, but there's something especially magical about the kind that show up before we know we need them, instead of when we turn to them. That kind of magic, I believe, is real, and can still be integrated into our lives today. It may be easier to explain this as the subconscious telling us to notice when something isn't right. Or if you're inclined to have fun with the mystical explanation--let me tell you I actually have a totem.  I didn't pick it--but sometimes when things are out of balance in my life, I start seeing spiders. It's scary to admit it--I think it's a bit crazy even--but I'll be getting ready for work one morning, and there will be a spider in the shower.  Then there will be one at the badge swipe at the front door of my office. Then one will drop down from the ceiling over my desk. Of course it could be chance--but when this happens all in one day--I get a bit freaked out. Don't get me wrong--I love the beauty of spider webs, the way they trap nuisance bugs, the metaphor of web-weaving and the internet--but I am also irrationally scared of spider bites. Or maybe I could say I have a healthy respect for spiders. This makes them a great totem for me. Maybe there's nothing supernatural going on here--maybe a neurologist could explain these sightings as a desperate attempt of my subconscious mind to be creative when I'm overly focussed on a project--and maybe that is why I notice spiders more when my life is out of balance.

Regardless of any logical, mystical, or even insane explanation of totems--when I see spiders, it's a wake-up call. Maybe I forget most sightings, because nothing in particular is going wrong. Yet when I'm starting to head into potentially addictive territory, and a spider crosses my path, it helps me get back in balance. So in response to Graham's search for early warning signs of addiction, I think we need to capitalize on totems. At my office in Philly, I put a big 5-foot round Halloween spider web in the window; in my garage I keep a web-shaped wind chime.  Whenever I see a web or a spider, I step around it in respect for the work it's done--and I also ask myself if I'm in balance. So I have to admit that I like a combined approach--a belief in the kinds of totems that come to me, and the integration of physical charms into my daily environment.

Giving
Another kind of totem that works for me is mantra:

• Give 'til it hurts.
• Anything with value is hard to do.
• Too much of anything is a bad thing.

OK, so why am I writing about Addiction, Totems, and Giving on my technical blog? It's because this blog is part of my internet life--a part of my life where I wonder if I'm addicted. I think all the nights and weekends I spend reading/writing/e-mailing could cause a catastrophe some day. I try to stay in balance by running regularly, spending time with my family, volunteering for the Agile Community (e.g. Agile Tour, Agile Philly, and other projects), and coaching/managing software development teams--but it's hard to stay in balance. Something always suffers. Yet if I look back at the mantras above, it's OK that it's not perfectly balanced--because too much balance is a bad thing.

This blog is part of the way I try to give until it hurts. I try to find something that's on my mind each week to write about--it challenges me to keep reflecting on the work I'm doing, it forces me to have some discipline.

There's something more important about giving though. It's personal, really. One who gives, gets. When I write here, people comment, or e-mail me, or mention it at a conference. People give back to me. They help me see my shortcomings, they center me. They help balance my perspective.

Hmmm. Addiction comes from overuse of one activity or substance. Wake-up calls, in the form of totems or gifts, re-center us, put us in balance.

So go to your local user group meetings. Participate in the online community. Give 'til it hurts. It will help you more than you put into it.

Target Customer Characterization

Recently I've been interviewing all the sales, pre-sales, and professional services staff in my company to build a profile of our customers and prospects, in order to better focus our development, marketing, and sales efforts. This is the template I made (inspired by Geoffrey Moore's book). I use it to guide my interview process, and try to fill it in under 15 minutes. Lots of times I only use the initial table to get context about the work environment, but can't fill it in; I rarely get to the "after" scenarios, but I'm posting this to get feedback--what would you change in the template?

So far the whole process has been quite illuminating. It takes a while to digest all the information I get, though, so I can't do more than a few clients a day.

Target Customer Characterization

Client Name: Industry: Interviewed:

	Geography	Department	Job Title
User
Technical Buyer
Economic Buyer

Before purchase, a day in the life of (find consequences for economic buyer):

Scene or point of frustration:

Desired outcome:

Attempted approach / Alternative Products / Competition :

Interfering factors:

Economic consequences:

After purchase, a day in the life of:

New approach:

Effectiveness of approach:

Economic benefit:

pull stand-up sessions

Though I haven't (yet) succeeded at this, I'd really like stand-up sessions to go more efficiently by replacing the standard stand-up and report tradition to a stand-up and ask questions. We'd organize the discussions around the active story cards, addressing each card one by one. Someone who is not working on the selected card will ask--"what's left to move this to the done pile?" followed by any clarifying questions necessary. Answers will be short and to the point. If questioning goes on too long, we'd just take it offline and move to the next card.

What's my motivation? I'm always torn between listening to what people around the circle are saying and trying to summarize my status... and as a result I get less out of the other people's summaries. I learn more by asking questions, by pulling information--and I wonder if other people would too.

Favorite lines from Crossing the Chasm by Geoffrey Moore

There's a reason this book has been a best-seller--it's full of great insight, it's well-written, accessible, and Moore's arguments are backed up by clear logic. It was initially published in 1991 but I read the revised version, published in 2002. Here are some of the ideas I found most inspiring.

Chrossing the Chasm is all about "marketing and selling disruptive products to mainstream customers". This line, direct from the cover, means so much more to me after reading the book--for example, the fact that growing a business based on a technology product is not soley dependent on the value proposition and execution--but is equally dependent upon the sales channels and relationships we build in a target market. I learned why our salespeople do so much networking, and why my personal network is so valuable.

So let's begin with Moore's first principles; a high-tech market is:

"a set of actual or potential customers, for a given set of products or services, who have a common set of needs or wants, and who reference each other when making a buying decision". So there it is--what we already knew before--that word-of-mouth marketing is the most effective form of marketing. What is new to me, though, is the premise that word-of-mouth marketing is effectively the ONLY way to reach the mainstream market. We may reach our first clients (innovators and early adopters) directly, but to fuel sustained growth, to cross the chasm, we need to become the referent solution in a market segment - that is, word-of-mouth should mention our product any time the problem comes up. How do we ensure this? Attack a very focused market segment--and become the market leader. Yet crossing the chasm is dangerous for a company, too, because mainstream customers will not pay the margins that early adopters will--and so we cannot offer them the same level of service or customizations. The innovative developers and visionary sales staff of a pre-chasm organization are not the same kinds of people that are required for managing a post-chasm business--the post-chasm folk are experts at fitting the existing product into a customer's environment without tailoring--and the post-chasm developers are making the product easier and easier to support / use. This brings up a good point about how to reward founders (pioneers) and settlers. Pioneers should be paid highly for initial conquest/development work, and then they're likely to move on to new challenges; settlers should be given equity and share in the long-term growth of the company. Often compensation models are quite the opposite.

Moore breaks down market adoption into the following phases: innovators (technophiles), early adopters (visionaries), early majority (pragmatists), late majority (conservatives), and laggards (skeptics). Many companies get stuck after finding their first innovators, or get stuck after their early adopters... but there's a chasm between each phase. He says many companies fail to leverage the conservative market--but because it's so large, it can be a great source of profit for technology that is no longer under active development. Conservatives want COTS (commercial off the shelf software)--everything in a box. This brings up another important concept--the whole product. In crossing the chasm, the innovators must discover the full suite of services, features, and support required for successful implementation of the product, and add that to the product during the early adopter and early majority phases (since late majority users won't pay for support). Also of note--Moore considers himself a late majority adopter. To help pull them along, without hurting sales for the early majority, we need to provide easy upgrade paths and continued support of old products--thereby showing a commitment to the stability expected by conservatives.

"The consequences of being sales-driven during the chasm period are, to put it simply, fatal". The chasm period isn't about sales--it is about conquest. To cross the chasm, we need word of mouth references--we need buzz--we need everyone to be thinking about us in a particular market segment. The smaller it is, the easier it is to conquer. So sales outside of that segment are distractions that hinder our market penetration. It's fine to do another segment later--and successful conquest of several segments in a row will generate its own buzz--but stay focused! Mainstream market customers like easy buying decisions--and if you're the referent solution, they're happy, and willing to pay a small premium (30 percent) for the best of breed solution. Be the big fish in a small pond, over and over and over.

How do we pick the right market segment? Find one that you already have contacts in (you have their confidence), and go for the prospect with the most pain--something you can really help them with. If you have no strong contacts, grow some, and fix someone's pain with your product. Take note that crossing the chasm with an identifiable product is much easier than a product platform--e.g., smartcard-enabled credit card payments, since platforms need to be deployed ubiquitously before they're of much value. For more help in identifying segments or in categorizing clients, Moore uses a customer profiling technique he calls "scenarios". This profile is detailed starting on page 95 of the book, but captures elements like the point of frustration, the user, technical buyer, and economic buyer, the customer's goal, the current approach, the problems, and the economic consequences. Often you won't have enough knowledge to fill everything in--but "informed intuition" is OK too. The objective of mapping out user scenarios is to be able to target one, build it, and sell it. The targeting process will include a round-table discussion (with field reps) to rate each scenario against the following: "target customer, compelling reason to buy, whole product, partners and allies, distribution, pricing, competition, positioning, next target customer". With a compelling reason to buy, we can drive sales in shorter than 3-month cycles, and saturate the market in a year. With a market alternative, or product alternative, the customer can look at the existing budget for the product, and knows what it's worth--otherwise we have to wait for them to maybe budget for us next year. If you can't identify a market alternative, you may need a product analog--a methaphor that explains in a pithy phrase what this product is. Oh, and if you "have trouble finding a single, clear, market alternative" to attack and replace, then you won't be able to cross the chasm--people won't have a budget for you.

Product positioning is the pinnacle of marketing--but it's also tricky. People hold an image of a product in their minds--and don't like anyone else to manipulate that. So instead of trying to define it, find ways to make the product easier to buy. "Think about it. Most people resist selling but enjoy buying". Positioning is the attempt to get people to decide "best buy for this type of situation". Make sure your pitch passes the elevator test--because it has to be spread by word of mouth, and without this sort of focus, the development team will be fraught with too much complexity, marketing messages will be wildly different from one another, and potential partners/allies/investors will shy away since they do not know what you stand for.

Geoffrey Moore also talks about sales channels. We may use direct sales, systems integrators, retail sales, value-added resellers, or the internet. Of these, he prefers direct sales for an early stage startup because we need to provide a lot of hand holding to get customers off the ground, with a gradual transition to a less resource-intensive sales approach as we approach a mainstream market. Although integrators and resellers may reach a larger audience than we can alone, they who are in contact with the paying customer get the main profit.

The hockey stick sales growth of crossing the chasm is largely a myth. Moore says most sales patterns are like staircases. We discover and conquer a market, step up, and are stagnant again for a while while we invest in another market. He says some "vulture capitalists" take advantage of these stagnant periods to strip founders of their equity in the company.

These are just some of my favorite lines from the book--if you're part of a startup, I highly recommend reading the whole thing yourself!

XP 2010 physically agile makes us lean

This is my last post on XP 2010. I decided to host a "pre-conference session" every day--by going on a morning run--and a few people signed up for it on the LinkedIn group. It got harder and harder to get out the door at 6am every day, but I had a great time so it was worth it--and Xiaofeng Wang came along every day. We runners took a different path each time, and did about 45 minutes on the road at a conversational pace. It was great to do session re-caps and get a chance to get some exercise, too--I find it helps me focus for the rest of the day. Here's a couple shots from our last run:

XP 2010 Session Report -- Speak Like a Native by Yours Truly co-starring Deborah Hartmann Preuss

This workshop gave people the chance to work, in teams, on a real-life design problem with a customer who doesn't "talk tech". Thanks to Deborah Hartmann Preuss for helping me run this installment--we each played the role of an annoying customer. We ran two iterations of paper-based design through acceptance testing, followed by a de-brief to share what works and what doesn't.

In this second installment of Speak Like a Native, we had a much smaller audience than I've worked with in the past... but everyone seemed to get something out of it and we decided the low turnout was actually a marketing problem. We decided it would be better to call this session "dealing with annoying customers", and to discard the Speak Like a Native analogy--it doesn't really add much to the session. We generated some great ideas for improving other session mechanics--a big visible timer, timebox warnings, and an overview of all envisioned system requirements before working on the first release. We also confirmed my previous findings--that building a toolbelt is not an important part of this workshop--but talking about tools as part of the first debrief is useful. Here are the slides we used: Speak like a Native.

XP 2010 Open Spaces -- Agile Welcoming Circle

Throughout the conference I was talking to anyone who would give me an ear about a new idea I'd like to pursue: the Agile Welcoming Circle. To get further input on this idea, I held an open space session and invited everyone to come talk. If you have ideas/concerns/comments, please comment on this blog or join the Agile Welcoming Circle discussion group. Pictured right, thanks to Hubert Baumeister, I am describing the Open Spaces session.

60-Second Pitch

The Agile Welcoming Circle is a way to help get people plugged into the Agile community. It provides a landing page, which describes the common basic principles of Agile, and allows people to pay dues ($100/yr?) to join a facilitated discussion group. Their dues give them direct access to a list facilitator, who will get to know newcomers by identifying their interests and then connecting them to an appropriate community--be it a conference, user group, list serve, etc. Once the newcomer shows up at one of these events, as can be vouched for by another community member, they get a Certificate of Completion--meaning they've demonstrated some kind of a commitment to the community. This Certificate is something we'd be happy to see members put on their resumes, because all it really means is that they agree to support the community in some way. So, for example, a newcomer who wanted to learn about TDD would get hooked up with a code camp, and later may return to ask about pair programming.

The first facilitator would be me, but soon it would be run by a committee--and would be supported through Welcoming Circle dues (I think a portion of the proceeds would go to facilitators, and the rest, say 70%, gets dumped back into the program budget, to sponsor more local conferences, speaker travel expenses, etc.). The facilitators would also work on a program to increase retention after the Certificate of Completion, for example, by tracking/logging activity on a new social media channel on the main site (thereby creating an MVP list), or other means. I see this as a way to reach an audience that the Agile Skills Project, with all its overwhelming depth, couldn't reach--the newcomers.

Open Space Ideas

The biggest two concerns I've been hearing about this program are about retention after the initial subscription, and about yet another paper-based certification. Yet this time I think it's different--there will be no easy way for a cottage industry to build up around this, as its revenue is very constrained. By keeping registration costs low, it makes the whole program more democratic-it is a community-based system built to support community learning. Imagine, as Sumeet Moghe proposed (a leader in the Thoughtworks Learning Community), a great river of free information available on the Agile Welcoming Circle's member page--no simple RSS feed--but a Web 2.0 / Enterprise 2.0 flow of information that gets commented on / rated by readers, and then high-rated content comes to the home page. It would become a matter of prestige to get highlighted on the home page--and people who participate in comments or who publish would have to be paying members. The information is free--publishing is not (but rating is free). Editors/facilitators would also be able to promote content to the home page. We could also recognize helpful members through an MVP program.

Background

This discussion initially was focused around my frustration with the slow growth for the Agile Skills Project. I told people like Marc Bless and Cory Foy that I was going to drop out of the project, and they weren't happy with that. So I started talking about what I have energy for--helping the newcomers to our community. The idea is simple enough to try out, but it diverges from the charter of the Agile Skills Project, so I needed something new. I also want to devote more time to this project than I gave to the ASP, and to do that, I need a revenue model. I don't think anyone should make enough money out of this Welcoming Circle to make it a full-time job, but I do think it would be nice if it could pay for one day per month, or even one day per week, for several facilitators, depending on demand.

XP 2010 Session Report -- Catalyzing Lean - Building a Limited WIP Society by David Anderson

Mudi: non-value added

Muri: uneven

Mura: overburdened

David Anderson delivered an excellent keynote on why WIP (work in progress) limits are important. While he knows of some software teams who are applying lean by removing waste, he looks forward to hearing more reports about lean used to improve the value produced by these teams. He initially started with lean because he saw it as a way to more methodically measure the impact of software process improvement efforts (he's the SPIN founder). He also emphasizes that there's no reason we'd need to throw out iterations--they are not inconsistent with lean--XP in fact is a very lean process--but he wants to decouple the cadence of software delivery and iterations. He wants to see work scheduled by the opportunity cost of delay, to see value optimized by offering classes of service on requests, to see risk managed with capacity, and more. He sees plenty of opportunities for better applying lean to software.

XP 2010 Session Report -- Culture and Organisation by Diana Larsen

(note--I'm not sure if I got the title of this track right)

Diana Larsen reported that over 75% of organizational change efforts fail--and by fail she means it hurts so much that it brings down the whole company or causes significant loss in profitability. She talks about culture and its power--it is the glue that holds us together, that distinguishes us from others, and gives us a context for working together. She points out that culture can change, and that if we want to change it, we need to leverage its propensity to change naturally--we need to work with its strengths.

Change happens when a culture is dissatisfied, can envision a better future, can see the first steps to change, and all these together are greater than the resistance. She also spoke about the life cycle of culture (pictured right)--from clan, to hierarchy, to market, to ad-hocracy. Clans are internally focused, they support flexibility and discretion; hierarchies are still internally focused and are concerned about efficiency and structure; markets are externally focused and value results/winning; ad-hocracies are externally focused, interested in tents, not palaces--innovation, flexibility and discretion. Cultures tend to cycle through these categories over and over. While all models are wrong, this model can be useful in finding out how to help the culture change--it's appropriate to use charisma to sell an idea in a clan; it's important to get executive support in a hierarchy, and so forth.

XP 2010 Session Report -- Software Craftsmanship by Cory Foy

Although I have signed the "craftsmanship manifesto" I have misgivings about it. Though I agree that we need to do quality work, I don't think that's necessarily what's holding our teams back from delivering more value to the business, and therefore cannot be the sole focus of our software process improvement initiatives--I think that the real points of pain in the industry are long feedback cycles and inadequate communication. So I went to the Craftsmanship session with a bit of a bias. The delivery of Cory's talk was excellent--he was energetic, well-spoken, enthusiastic, and used his slides very well. He started with storytelling--in fact, a story about a business executive who sat next to him on the plane, complaining about internal software staff who just wouldn't deliver the business value he needed. Instead, this executive was frustrated by all the roadblocks the software teams were mounting (including questioning/challenging projects, technical veto of proposed solutions, and technical debt). He went on to ask whose fault it was that we have so much technical debt... and of course it's us. He said that this movement was kicked off by Robert C Martin's tirade at some conference that we need "quality over crap!". It's the design of our software that we need to focus on. I liked Cory's statement that we need to know what problems to focus on/solve, because there's no shortage of problems--but there is a shortage of time and energy, so prioritization is key. My notes also have a re-write of the agile manifesto stating "delivering value over working software over comprehensive documentation", but I don't know if Cory brought that up--I know it's something Kent Beck mentioned at the recent Lean Startup conference... Unfortunately, the rest of what I see on my notes are criticims of the talk--a complaint that the "craftsmanship" is gender biased, and a complaint that the quality of our code is not why the business is frustrated with us. It was hard for me to wait until the Q&A section of the talk, because I just kept thinking of more and more reasons why a focus on Craftsmanship seems wrong to me. So my question to Cory was something like: if you could go back to that business executive and show him how you'd cleaned up all the code for the software teams he'd been complaining about, do you think he'd be happy? I think not--I think he wants responsiveness and the ability to deliver the right things. I think there needs to be a balance between agility and craft--and in fact, we can have both--but I think it's too seductive to focus on the things we have direct control over. The biggest problems, the biggest benefits, are related to cycle time--and fixing those problems involves the whole company.

Photo credit Hubert Baumeister.

XP 2010 Session Report -- How Do I Measure Up?

In "How Do I Measure Up?", I started by reconfiguring the room into a circle--because I wanted to make it clear I was a facilitator, not a lecturer. Inspired by Peter Block, I really focused on the layout of the room, the lighting, and making the room inviting.

When the audience arrived (4 people), we identified everyone was already familiar with both the project and the self/peer assessment form I'd prepared. Instead of following the plan I had for the day, we talked about the mission/goals of the project and why we get so much interest for the Agile Skills Project but so little retention. It was useful to have a high bandwidth discussion, because in summarizing the primary goals from my perspective, participants could give me quick feedback that this had not been clear from the web site. I admitted it was too complex--but that I had been trying to pivot the project, first from an inventory, to a quest ecosystem, then to a self-assessment tool--all to no dramatic change in user retention. I concluded that the Agile Skills Project has nothing the customers value much, be it at beginning, intermediate, or advanced levels. There are other complicating factors--it was trying to be all things to all people, it was not really doing anything wrong, but not anything terribly right, either. I left the meeting pretty heartbroken, since I've nurtured the project for the last 9 months. Though I'm ready to let go of the project, the one remaining desire--to help the persona "Anna"--still remains. I feel like I was Anna 11 years ago--someone who really wanted to improve agile skills, but couldn't find a mentor or learning path. I worked on my MCSD credentials, read Steve McConnel, and went to grad school at night, and lost 4 years stumbling blindly on my own path of what could have been a much more effective adoption of agile. I've been doing XP to some extent since 1999, but it all clicked in 2005 when I started going to Agile Philly. So I really identify with Anna, and want to provide a low-cost means of welcoming her into the community. Stay tuned--and if you have ideas, let me know. I spent my free time Tuesday and Wednesday talking to people like Cory Foy, Joshua Kerievsky, Phil Brock, Diana Larsen, Sal Freudenberg, Mike Sutton, Marc Bless, Jeff Patton, Yves Hanoulle, Deborah Hartmann Preuss, and anyone else that would give me an ear and advice to build this vision. Find out more at http://groups.google.com/group/agile-welcoming-circle-committee.

XP 2010 Session Report -- User Story Mapping by Jeff Patton

This session was interesting to me for two reasons--I thought Jeff's presentation style was effective, interesting, and sufficiently dynamic to keep the audience engaged. He'd often ask us questions and draw up the responses on a flip chart. He clearly knew the material well and actually had his own answers--yet he was guiding us well enough that the group discovered much of what he had already added on subsequent slides in his presentation.

The content of the presentation was a good fit for me too. Jeff's system of User Story Mapping solves a lot of problems I've seen in the field--problems that I've solved in similar ways. First, he pointed out how user stories are different things to different people--for a business owner it may be a part of a business process, for a user it may represent the repetitive steps of a manual task, for a developer it may pose architectural hurdles. Each of these people would choose different key words to describe the story, as well as different levels of abstraction. So instead of seeking uniform descriptions, Jeff will ask clients to identify all the detail they can in a one day workshop. After capturing a large number of stories, he asks people to sort the stories in approximate workflow order, then to identify themes (epics). He argues that the epics are distinct dimensions of the product and can't meaningfully be prioritized against each other, but within an epic, stories need to be grouped into releases. Read more about this system at http://www.agileproductdesign.com/blog/the_new_backlog.html.

It is thought provoking to consider the pros an cons of his method for displaying all stories and epics on the same story wall for the life of a product (or at least the next three releases). When I worked on a mature product that was releasing much more frequently, this kind of forethought was definitely not necessary. Now that I'm working on new product development, though, it's very helpful to see how new functionality fits in with the big picture. My current team uses an adhesive surface for our story wall, and shows much less information. We add stories that don't fit in any theme and stories that are in the current iteration. We add everything else to an envelope, give it a clear title, and stick that on the wall too. We can move the entire envelopes around the story wall to show which ones are active, and we can remove the envelopes from the wall to throw all the cards on a table when we need to talk about the epic in detail. I think that these discussions would always happen on the story wall in Patton's teams... but it's also possible that we pay for the convenience of carrying one envelope by having less visibility and fewer discussions about inactive epics.

XP 2010 Trondheim

Normally conferences knock me off my routine

so much I don't blog about them, but this time I'm determined to write about what inspired me before much time slips by. XP Trondheim was amazing for me--it was hard yet energizing, and the best thing I got out of it was a chance to talk, directly, with a lot of people who I've met online in discussion forums, or people whose blogs/books I follow. For example, pictured right you can see me chatting with Diana Larsen (co-author of Agile Retrospectives and chair of the Agile Alliance board), on our way to the conference banquet Tuesday evening (photo credit Hubert Baumeister). This rest of this blog will include general comments about the conference as well as links to my session-specific comments.

As I've mentioned here before, I'd never been to a large conference run by the Agile Alliance, all due to cost--though as the years have gone and I've read the post-conference blogs I've been feeling more and more left out of some great discussions. I've succeeded at bringing some of those discussions to my own back yard, by supporting, organizing and speaking at small (free/low-cost) conferences and meetings, but I was really curious to see what else was to be had at the big events. So this year, when I realized I'd get free entrance if I were a speaker, I submitted proposals and got accepted at Agile France and XP 2010 Trondheim. In addition, as soon as I announced my plans to go, my employer graciously picked up travel expenses (thanks, Smartesting)!

While I've proudly stated that user group meetings (like Agile Philly) and Agile Tour can run conferences at 1/10th the price of the big conferences, I should have admitted it was not a fair comparison. Part of the reason I wanted to go to XP 2010 was to see, for myself, what the difference was, and I have concluded both kinds of conferences are necessary. I think that for many practitioners, attending a big international conference like this costs around one month's salary, and if their employer won't cover this expense, it's not affordable. This pay-to-play dynamic is something I want to fight against. On the other hand, this conference attracted so many attendees and speakers from all over the world that we were able to find people who were experts on any particular agile topic. I was able to ask Esther Derby (when I was at Agile France) what she thought about games and simulations in a stable team environment--and was happy to hear that, like me, she doesn't often play games in teams--they're more for conferences. I was able to ask "clarifying questions" of speakers like Cory Foy on the Craftsmanship session (though he later said I was grilling him) and David Anderson (during his talk on lean--I got stage fright as I asked a question in front of the whole conference body so I don't remember what he said--but I think I asked about how to control for side effects of measuring something like wip limits) and Mary Poppendieck on her views of slack (she hasn't seen it work when it's a fixed percent of the week or it's on a dedicated day) and product ownership (POs should only be conveners, and teams should prioritize their work and take responsibility for success of their product). Still, these interactions were not all--I was also able to connect with practitioners who I already know through the online community. It was always flattering when someone came up and said hi because they recognized my name (happened maybe 10 times), and it was really fun to associate names and faces as I did likewise for people I recognized. We were often able to drill deeper into conversations we'd had before, or talk about new things, like bringing an Agile Tour stop to a city near them ;)

The first day was all about workshops, including the one I did on the Agile Skills Project: "How do I measure up?". I arrived at the conference around 10am, tried to check in to the hotel, but no rooms were available yet. So I picked up my registration packet and went to my first official session, User Story Mapping by Jeff Patton.

There was a 30 minute pause after every session--food and discussion--perfect. Though I always had a hard time breaking the ice (and I felt terribly lonely for much of these networking sessions), I wanted to meet new people and so I just kept saying hi to strangers. By the end of the conference every time I stepped into a room I knew a few people. I'm sure that if I had stuck with a smaller group of people the whole time it would have been easier, and maybe I'd have had stronger connections with those folk--but I think that I can follow up later on every connection I made, so I just kept reaching out to new people.

Main conference sessions were organized in an innovative fashion--they had a primary speaker followed by several 10 minute talks about research and experience reports. Unfortunately, these speakers didn't coordinate their talks in advance, and there was a frustrating amount of overlap. I'd like to see them be more organized and to see sessions that are run in more of a pull fashion--I feel like there wasn't enough discussion. Regardless of the lower bandwidth presentation styles, I really got a lot out of Scott Page's keynote an Diana Larsen's talk on Culture and Organization.

The second day of the conference ended with several hours of open sessions - starting around 6pm. I suggested a couple topics near to my heart--but ended up only running one: the Agile Welcoming Circle. There were two other open spaces sessions I really enjoyed--one was on serious games (I liked the game where we stand in a circle, eyes closed, and count to 20 without speaking over one another, and also the game where we all stand in a line and step forward simultaneously). The other session was called Overcoming Fear at the Workplace. Though I don't necessarily agree that fear is something that should be overcome--I know it is a very important topic--and is well summarized by Ralph Miarka here:http://www.miarka.com/2010/07/09/open-space-session-on-overcoming-fear-at-the-workplace-at-xp2010/

On the last day of the conference, Deborah Hartmann Preuss and I ran a workshop called Speak Like a Native. I was happy with the outcome and hope to run the workshop again soon.

Agile France 2010

Bruno Sbille opened Agile france with a keynote on learning channels, with a title that could be translated as "Neuro-linguistic Programming and Agile: eyes, ears, and touch." He explained that while we can all learn in multiple ways, people have one or two channels they prefer. The channels are visual, auditory, and kinetic. While he did practice what he preached, by inviting us to wave, clap, look at, make a noise, or otherwise connect with other people in the room, I was a bit frustrated that it wasn't more interactive.

In the second part of his speech, he presented a model on drama in the workplace, in which he identified the major roles that people play when there is a bout of drama: victim, villain, and hero. He then explained it's our job to recognize this role-playing, and to diffuse it. For example, a victim can refuse help from the hero; a hero can hold back from solving problems.

Oana Juncu led a session with a colleague (not sure of the name) called "How to assess the success of an Agile Project". I was interested in it because I am curious about quantitative metrics that can be used with minimal side effects; instead we discussed intangible factors and qualitative measures. Still, the session was effective and high-bandwidth; we identified success factors as a group that included things like responsiveness to learning, flow of value, reduced turnover, flexible yet stable code, etc.

For the day's first pause, I was busy setting up the room for our talk, so I didn't get to network.

Next Olivier and I presented "Speak Like a Native". We had about 20 people, including Esther Derby who had come, I suppose, in hopes for an English-speaking topic, but that it was not. We set the stage by giving a business context, then explained one user need at a time to each of the 3 teams--their task was to draw a user interface. As soon as they had something that looked potentially useable, Olivier or I would go do a "walk-through" by asking what happens when we click on buttons or select certain fields. It was designed to make people frustrated, and that it did. Then we did a retrospective to see why it was frustrating, what we might have done to make it go better, and we re-ran the activity. As always, we finished with a feedback piece--this time using a Blond ROTI.

At lunch, as I usually do, I introduced myself to someone I don't know and ate with them. We talked a little about where they're from and what they do, but didn't exchange contact info. After lunch I bumped into a few Agile Tour organizers, including Colin Garriga-Salaün and Gabrien le Van, then I wanted to go to Esther Derby's session but it was too full, so I headed out for the airport. It was good to have a little extra time to get there--the subway wasn't too full and I didn't have to rush.

XP 2010 Keynote by Scott Page

Scott Page delivered an impressive talk entitled "Leveraging Diversity in Parallel: Perspective, Heuristics, and Oracles". The mechanics for his talk were excellent--he started with a personal story about his youth, drawing us in to the first point of his talk: how new perspectives can make hard problems easy. He then expanded upon it by showing how multiple heuristics can be more valuable predictors. He noted that this flavor of the wisdom of crowds only works when we have a sufficiently difficult problem and all contributors have a minimal competency to evaluate the problem--but at the same time they must have sufficiently different backgrounds and training that when they're working on a problem they see it from different perspectives. He also spoke about oracles--something used to evaluate whether we've got the right answer or not--and said that wisdom of crowds is most important when there are no oracles. When we have oracles, we learn faster by incorporating their feedback early and often. Thus, multiple perspectives on a team are part of the magic that makes a team greater than the sum of its parts. On a larger scale, the wisdom of crowds increases the intelligence of groups too, when everyone is at least competent enough to make an educated guess and they offer different perspectives on the problem. He noted that some companies are now using a swath of employees/algorithms to more accurately predict markets or elections or even Netflix recommendations. He also explained that experts are often horrible predictors of the future because they work predominantly with a small set of models. These models bias their processing of data, and make them poor "oracles". Scott provided mathematical models for all of his arguments, but I don't buy them. As he said himself, reducing people to one statistic (such as an IQ score) is overly limiting. I think the same can be said of equations as a measure of diversity in a team... it is overly limiting to see what effect that equation will have on the accuracy of predictions on the team. Maybe that wasn't his point--he simply wanted to use math to back up his arguments. In any case, I have to admit that he used a diversity of perspectives to tell his story, and I can appreciate that. It was a very captivating talk, and one that would be worth watching online.

conference season

It's the season to learn, get energized, and inspired by other conference attendees... Over the next 3 weeks I'll be giving talks in Paris, Trondheim, and Munich (luckily they're all in the same time zone):

May 31: Agile France, Speak Like a Native

June 1-4: XP 2010, Speak Like a Native and How do I Measure Up?

June 17: TAV 30, Testing before development is done: Agile thanks to MBT

Besides doing talks, I'm also helping ramp up this year's version of the Agile Tour. We recently sent a call to nominate cities for the 2010 edition, and we're having twice-weekly conference calls for the board. We have over 40 candidate cities so far! It's a conference that has enjoyed exponential growth--starting in 2008 in France only, we've marketed it across international borders (and yours truly did the English-speaking marketing), resulting in 6 new countries last year (3 of which came through the English-speaking channels), and even more this year.

Stay tuned for blogs about the cutting-edge developments announced at next week's conferences...

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