More Sprint Wisdom – Getting Your Sprint On

Whit Morriss, who recently led the fantastic Plone commuinty “BBQ Sprint” in North Carolina, published a few great bullet points of sprinting wisdom titled “Get Your Sprint On.”

  • Don’t [work|code|drink] alone
    Sprints are social event above all and you plural are the main resource.
  • Socks, then shoes:
    Start at a starting point, move in a direction.
    1. Start with a plan
      POA.  Maybe you POA is a part of a five year plan for world
      domination.  Maybe you just want to learn how to write better
      doctests.  All that matter is that you have a plan so you have a plan
      you can change.

    2. Focus
      the main things is keeping the main thing the main thing.
    3. Flow like water
      The A
      stands for adaptation as well as action… a project’s POA is
      determined by it’s participant’s needs and desires.   As new
      information becomes available, plans change.

    4. Do First Things First
      don’t expect to code features if your project don’t have tests, packaging, docs, buildscripts etc. 
    5. Do what you need to do
      If things aren’t working, adjust your POA to focus on making them work
  • Test first and [ask questions | talk trash] later
    has questions and opinions.  Make yours better by doing everything you
    can to test them before you disseminate. Sometimes the best question is
    “how do I test this?” rather than “How do I do this?” or “why doesn’t
    this work?”.

    As for opinions, sharing information is the
    greatest part of opensource.  The better the your information, the
    better you can contribute, the better F/OSS is.  Good tests are golden,
    talk is cheap.

Fishing vs. cutting bait

I often find myself confronted by the choice between doing what I know how to do, and helping other people learn to do those things.

A few years ago, I finally figured out that in the long run I am better off spending time teaching other people to do things I know how to do and learning how to do things I don’t know how to do yet.

As in so many things, the trick is in the practice.

“Pintification” – a new speed geeking technique

Chris Johnson describes a new innovation in speed geeking/lightning talk technique, pioneered at the Plone community’s recent BBQ Sprint:

Pintification : The act of conveying your idea before the judge finishes his drink

An interactive variant on lightning talks

The rules for pintification are simple.

  1. the new speaker buys the last speaker a drink
  2. The speaker must finish his talk before the drinker finishes his drink.
  3. Drinker may drink at any speed he or she feels is appropriate given the quality of the speaker.
  4. Crowd may encourage the drinker to drink faster
  5. Crowd may refill the drinkers glass in order to force the speaker to talk longer.
  6. If the speaker declares his or herself done, drinker must finish drink.
  7. When drinker finishes, the speaker takes his place with a new drink of his or her choice and a new speaker starts.

    I love it!

    DevSummit Report Out

    A big love bomb to Gunner, Heather, Tim and the hundred-odd other fellow nonprofit software developers who made last week’s Nonprofit Software Dev Summit a fantastic experience in slightly nontraditional conferencing.

    Among the highlights for me were:

    • The unexpected appearance of dear nonprofit tech colleagues such as Amanda Hickman, Laura Quinn, Teresa Crawford — in addition to the great ‘usual suspects’ like David Taylor, Rob Miller, Allen Poole, Leda Dederich and more.  All are amazing people that I don’t get to see nearly often enough, and it’s more than worth the time and effort of travel to get quality face-time with them.
    • A great demonstration from Simon Rowland of DirectLeap of his inexpensive, easy-to-use web-based robo-calling tool.  I can see some pretty powerful uses of this kind of technology, and it’s amazing to think that it is about to become accessible to small organizations. 
    • The first ever nonprofit techie geek trivia contest.  Steve Andersen, David Taylor, Simon and I put up a good fight, made a great attempt at packing our questions into the final round, but were ultimately defeated by a powerhouse team anchored by Eugene Kim and Evan Henshaw-Plath.  (Potentially trivia geeks be warned: there seems to be no bit of Silicon Valley tech trivia that Eugene does not know.)
    • Did I mention the food?  Seattle is a pretty good eating town, but San Francisco is in another league.  (Or maybe I just don’t get out enough at home!)  In four days, I didn’t have a single less-than-excellent thing to eat.  A big thanks to Joel Burton and Rebecca Weaver-Gill for being such gracious hosts. 

    Some nice event photos on Flickr.  Not sure that much made it onto the wiki or into blogspace yet, but I suspect many are still recovering from brain (and fun) overload.

    Technorati Tags:

    Learning From Toyota

    I don’t usually find a huge amount worthy of remembering in the business section. But in a long New York Times magazine story about Toyota’s corporate culture and business success, the following paragraph jumped out at me:

    Toyota is as much a philosophy as a business, a patchwork of
    traditions, apothegms and precepts that don’t translate easily into the
    American vernacular. Some have proved incisive (“Build quality into
    processes”) and some opaque (“Open the window. It’s a big world out

    Ok, there’s more.  Here’s  fantastic summary of audience-centric outreach:

    Toyota focused the marketing of the Tundra on what Smith calls five “buckets”: 1) fishers and outdoorsmen; 2) home-improvement types; 3) Nascar fans; 4) motorcycle enthusiasts; and 5) country-music lovers.

    Anyone wondering why Toyota has become a major booster of Nascar or a sponsor of bass-fishing tournaments can see the logic. It’s also why Toyota is sponsoring Brooks and Dunn, the country-music duo. And dealers are taking new Tundra trucks to Nascar events, country-music concerts, fishing tournaments and the like. “Parking lots tend to be a long ways away from where the events are,” Smith explains, referring to motocross competitions, “so we have our dealers setting up shuttles.” The plan is to pull up in a Tundra, offer visitors a ride but have them drive to the event on a slightly indirect course (laid out by a Toyota dealer). “At the end,” Smith says, “we say, ‘Thank you, you’re guests of Toyota, here’s a bottle of water, take a lanyard.’ ”

    Figure out who your target audiences are, then go where they are, do what they do, and find a way to be of service to them.

    This is great stuff — really worth a read.

    Donor Management Process Mapping

    One of the best things about working at ONE/Northwest is the fact that I get to sit across the room from brilliant people like Steve Andersen. Over the past few months, Steve has been doing some amazing work helping our small- to mid-sized environmental organization partners build effective relationship management systems.

    One of the deep pieces of wisdom Steve brings to the table is the insight that successful database projects aren’t actually about technology — they’re about helping groups understand their business processes. And Steve has developed some amazing techniques for helping groups make process maps of their relationship management processes.

    They look something like this:

    Why is this helpful? Well, until a group really understands what they’re trying to do, it’s impossible to give them the right tools to support it.

    Steve has finally started to write up some of the results of this work.
    The first two maps he shares show how a group we work with work with donors to get them to the point of being ready to ask for money, then how they go about actually executing that ask.

    As former ONE/Northwester Dean Ericksen commented on the Salesforce Nonprofit email list, “In a world of nerd-wonkery, this is high-art.”

    Great stuff. I can’t wait for Steve to unroll the next couple of installments.

    NTEN Open API Summary

    NTEN recently published a solid little paper by Michelle Murrain and Katrin Verclas that sums up the state of open APIs in the nonprofit CRM sector.  It’s an important read if you believe in the importance of integrating tools.

    There’s a lot of good stuff in this short paper, and I particularly appreciate that they make a clear distinction between “same machine” or “internal” APIs, which are only accessible to programs written in the same language running on the same machine, and web services or “externally accessible” APIs that can be used by any program, written in any language, running anywhere. 

    SocialEdge Relaunches on Plone

    Jason Clark and Victor d’Allant just relaunched, now proudly powered by Plone. They’ve got an active community of social entrepreneurs blogging, wiki-ing and discussing away.

    It’s really nice to see Plone getting used in high-profile nonprofit collaborative/community sites.

    Migrating an active community site to a new platform is no small undertaking, as Jason attests. It looks like they’ve had a pretty successful launch, though, and more refinement is on the way.

    SocialEdge looks to be using the following add-on Products:

    Update: that was an embarrassing typo in the headline. all better now.

    Building Bridges

    Ryan Ozimek’s piece “Islands and Bridges, the building has begun” is a great hallelujah to the power and importance of integration via open APIs.  It’s clear that PICnet and ONE/Northwest are drinking form the same cup, when Ryan writes:

    The power of open source, combined with best of breed proprietary
    systems with open APIs give organizations the power they need combined
    with a price point they’re more likely to afford.

    Which leads us back to the islands and bridges. The winning
    solutions at the end of this year won’t be those that try to pack as
    much under the hood as possible, but rather those that are most
    flexible and connect most effectively with other systems.

    In short, the non-profit sector’s needs demand more choice, and that’s just what open source and open APIs can do.


    We’re attempting very similar bridge-building work between and Plone, and we’re looking forward to (finally) releasing our SalesforceConnector for Plone in the next few weeks.  (Got to get through some server migration work first!)

    I can’t wait to discuss all of this great integration work at Aspiration’s Nonprofit Software Development Summit in a few weeks. 

    Jon Udell Says “Integration Is Hard”

    … and he’s just talking about connecting Outlook 2007 and Google Calendar!

    Bottom-line: support for standards is necessary but not sufficient. Even when products comply with standards like iCal, people struggle mightily to use those products interoperably. It’s the conceptual barriers that get in their way. It’s really hard to figure out how a concept expressed in one system maps to the same (or a similar) concept in another system. To make that easier, technology providers will have to agree on more than just protocols and file formats. We’ll also have to work together to minimize conceptual clutter and normalize core concepts.

    Good to keep this in mind as we move forward with integrating wildly different social change tools.

    Proclaim: Integrate!

    My colleagues and I from ONE/Northwest recently signed onto the Integration Proclamation, a first step towards encouraging funders, software developers and those of us who work with them to invest resources in making tools that play together better.

    If you agree that social change activists need tools that assume they’re part of a larger picture, not a world unto themselves, then take 30 seconds and sign

    It’s a first step, not a solution.  But solutions start with attention.

    Evaluating Open-Source Software Communities

    Seth Gottlieb writes one of those blog posts I wish I’d written, on evaluating an open-source software community.

    The community will influence your experience of the software and shape the application’s future. If you are used to commercial software selection, the concept of “community” is probably alien to you. You may be used to reading analyst reports about market share and corporate financials. “Community” feels squishy and qualitative by comparison. Even though the information that can be used to evaluate a community is visible, it takes some work to gather and interpret it.

    Seth’s key community indicators are:

    • General activity level (especially bug reporting activity)
    • Vision and priority setting (for product enhancements & updates)
    • Leadership – especially the demonstrated ability to develop, promote and renew leadership
    • Execution – clear rules and standards that define how to produce quality code, and mechanisms for making sure the procedures are followed.
    • Participation – especially openness to new participants and non-technical forms of participation
    • Economic Ecosystem – does the project have a strong base of economic activity that is supporting it? Are people making money?

    Great post, Seth. Thanks.

    How To Build a User Community

    Kathy Sierra’s got another fabulous post, titled “How To Build A User Community, Part I” which draws on her experience with Java user communities.

    She believes (quite correctly, IMHO) that the key to a successful user community is teaching and encouraging intermediate-level users to start answering questions.

    Her “big six” tips for growing a user community are:

    1. Encourage newer users–especially those who’ve been active askers–to start trying to answer questions
    2. Give tips on how to answer questions
    3. Tell them it’s OK to guess a little, as long as they ADMIT they’re guessing
    4. Adopt a near-zero-tolerance “Be Nice” policy when people answer questions
    5. Teach and encourage the more advanced users (including moderators) how to correct a wrong answer while maintaining the original answerer’s dignity.
    6. Re-examine your reward/levels strategy for your community

    Great stuff. When I think about the Plone community, I think we do a pretty good job on most of these things most of the time. We have a good number of folks who are comfortable guessing at the answers, and some really outstanding experts who can gently correct and build upon their sometimes-partially-right answers. We are very good at teaching people how to ask questions, but I think we could do more to explicitly teach folks how to answer questions better. And we do, unfortunately, have one or two sometimes-a-little-gruff “experts” who don’t always suffer poorly-framed questions as gracefully as we might like.

    One thing we don’t yet have are very clear reward strategies for community participation. This is something I’d like to think about more in the next few months. Recognition, appreciation and love really make a big difference, and they’re what keep people around in the long term.

    Ethan Zuckerman Review’s Cass Sunstein’s “Infotopia”

    Ethan Zuckerman (who probably doesn’t remember me following along two years behind him at Williams) has a nice review of Cass Sunstein’s new book “Infotopia.”  I’m adding it to my reading list.

    Sunstein is still concerned with the formation of ideological cocoons. In his new book, Infotopia, he’s become a cyber-enthusiast to an extent that would have been hard to imagine a few years ago. Specifically, he’s excited about the ways new online tools make it possible for groups of people to assemble information and accumulate knowledge. He’s become a devotee of Friedrich Hayek, the Austrian economist who saw markets, first and foremost, as a way to aggregate information held by a large group of people. There’s ample evidence that Hayek was right in an examination of the failure of planned economies – smart men sitting in a room do a far worse job of setting the price of copper ore or bread than the collected actions of thousands of consumers, iterated over time.

    Deliberation vs. distributed information aggregation.  Fascinating.  Sunstein’s a strong supporter of the latter.  I’ll close by stealing Ethan’s closing paragraphs.

    Whether or not I agree with all of Sunstein’s conclusions, his quest
    for systems that aggregate knowledge across networks is an exciting way
    to look at the contemporary Internet. A large number of the most
    interesting projects taking place on the Internet use strategies to
    aggregate information from multiple users to create new knowledge –
    this is the magic behind Google’s PageRank algorithm, Digg’s headlines
    and Amazon’s collaborative filtering recommendations. Analyzing these
    systems in terms of their effectiveness in getting people to reveal
    hidden knowledge is, in my opinion, an excellent framework for
    evaluation. (I’m very interested, for instance, in thinking through how
    the folksonomy and taxonomy systems David Weinberger is exploring in
    his forthcoming “Everything Is Miscellaneous” use different mechanisms to assemble information from different actors to organize information.)

    It’s also useful to confront Sunstein’s fear of information cocoons
    again, five years later. Sunstein’s examples of cocooning are
    interpersonal ones in this book, governments and firms that manage
    themselves in ways to avoid confronting uncomfortable truths, as
    opposed to individuals burying themselves in sympathetic media. But
    media cocooning is a problem for individuals as well, consumers of
    online and offline media. I suspect it’s possible to use some of the
    Hayekian thinking about collecting diverse information to create media
    aggregators capable of breaking cocoons and exposing people to views
    and perspectives they might otherwise have missed.

    NewsCloud Released as Open Source

    Jeff Reifman has released the NewsCloud platform under an open-source license. Great stuff. As he points out:

    While there are a number of social network journalism platforms that allow a wide variety of original content, none of the latest… generation so far are licensed to the open source community to inspect, re-purpose and improve.

    The technical details:

    The NewsCloud platform is written in PHP and MySQL. Visit the NewsCloud site at SourceForge to download the code. Visit our Developer Wiki to get more information. There are a number of ways for developers to get involved with us. We’ve also set up a Google Groups discussion forum for developers. If you just want to integrate your site with NewsCloud, our pre-existing REST-based PHP class of Web Services API is still available.

    In a world with an increasing number of information sources tied together online, it will be increasingly important for people to work together to take more responsibility for providing high-value editorial services.  It’s not the “one-size-fits-almost-all” editorial model of broadcast and newsprint anymore.
    NewsCloud presents a fascinating opportunity for folks to experiment with a powerful, rich state-of-the-art platform for aggregating and discussing news stories ala Digg or Slashdot.

    Sprint Wisdom

    Every once in a while, if you’re lucky, you get to be part of an event that *seems* simple, but isn’t. An event that appears effortless, but is in fact based on a subtle combination of deep insight and hard-won experience. An event that quietly encodes a massive amount of tacit wisdom bubbling just beneath the surface.

    That was how I felt when I attended my first Plone “sprint” last month.

    A sprint (I don’t like calling them “code sprints” because a good sprint has a *lot* more going on that just the writing of computer code) is one of those deceptively simple-seeming events whose story deserves to be told more widely.

    The sprint was invented by Tres Seaver from the Zope community back in 2002 as a way to drive forward the development of Zope 3. (It may well be based on the longer-form “hackathon” model pioneered by the OpenBSD community.) Since the Plone community is closely tied to the Zope world, the concept of sprinting quickly diffused over to us. The first Plone sprint was held in Berne, Switzerland in February 2003. Since then, there have been about 25 Plone sprints.

    Here’s the gist. I think a lot of the details get lost in translation, because like so many experiences, the description of the is really no substitute for the experience itself. Let me know in the comments what I’m getting wrong.

    A bunch of programmers, often of widely varying skill & experience levels, come together, possibly along with folks who can write documentation, speak to feature requirements, address usability issues, etc. They’re all volunteers, donating their time to the community.

    The sprint starts with a short all-hands meeting coordinated by a sprint coach, who lays out the goals and helps folks break the problem into chunks and to organize themselves into workteams. There’s usually a couple of hours while folks get setup with the software and tools they need to be productive, and perhaps a presentation or two to bring people up to speed on specific bits of technology.

    The teams go off and work, each with an experienced leader, break down into even smaller groups of 2-3 people, and start working away. At the end of the day (or at some interval) there is usually another all-hands meeting where folks report out on what they’ve accomplished. Cheers all around. A sprint can last anywhere from a day to a week, and can be dedicated to one very specific topic, or run in a more “open-space” fashion where many loosely related things are addressed in parallel. A sprint can be as small as 3-4 people, and as large as 60-70.
    Sounds pretty simple, right? Well, yes. And no.

    Ok, let’s break it down. A sprint is all-volunteer. It’s not a consulting gig. Some sprint organizers, especially folks organizing sprints to tackle very specific, complicated problems, will sponsor the travel costs of key attendees. But nobody’s getting paid for their time. Sprints are flat, non-hierarchical events (like open-source itself!) and that’s important.

    Sprints are strongly rooted in the concepts of “extreme programming” (or “XP). That’s why we work in pairs (or occasionally, groups of 3-4). Extreme programming teaches us that having two sets of eyes but only one pair of hands on the keyboard results in better quality work. It’s not an approach that works for everyone, and it’s certainly not a panacea for software development, but for the talented, highly social generalists that tend to be attracted to open-source web application frameworks, it’s a great fit. More importantly, working in small teams, especially teams that mix experienced folks with newbies, results in a huge amount of hands-on teaching and learning.

    As you might expect, sprints are highly social events. Along with conferences, they’re among the few face-to-face events where the globally-distributed Plone community comes together. And technology, as we know, is no substitute for beer. As bread is broken, the social ties that are the lifeblood of any productive community are formed. Sprints are part of the glue that binds us together.

    The corollary is that sprints are one of the most powerful tools the Plone community has to bring new folks into the tribe. All you have to do is show up. Because of the open format for most sprints, you’ll get a chance to be part of a team, work with more experienced folks, share what you know, and achieve tangible results. You’ll have a great time, and leave feeling capable, confident and passionate. And even more that refreshing the social connections among existing community members, creating a smooth way to bring new folks in the door is what has allowed the Plone community to remain cohesive even as it’s grown exponentially over the past five years.

    The Plone community has had sprints all over the world, and in some pretty fantastic locations. A castle in Austria (twice). A ski cabin in the Alps. A decommissioned military base on a Norwegian island. New York City. Vancouver. Vienna. Houston. My hometown of Seattle. 🙂

    What impressed me the most about seeing a sprint in action was the way so many small elements came together to produce an experience that was in many ways larger than the sum of its parts. The model has a lot of room for innovation, but certain core things you just have to get right in order to produce that magic blend of productive work and intense, immersive, peer-to-peer learning.