InfoQ

Interview

Linda Rising on Collaboration, Bonobos and The Brain

Interview with Linda Rising by on May 19, 2007 01:48 AM

Community
Agile
Topics
Teamwork ,
Collaboration ,
Stories & Case Studies
Tags
Fun ,
Complementary Practices ,
Agile2006 ,
Interpersonal Communication
Summary
In this InfoQ interview, author and coach Linda Rising reflected on scientific research suggesting that we may be hardwired to work in small, collaborative teams. She also explained what led up to her popular Agile2006 talk "Are Agilists the Bonobos of the Software World?" which focused on their "make love not war" social rituals. The apes' rituals, that is.

Bio
Linda Rising is an independent software consultant with a background in Mathematics and a Ph.D. in object-based design metrics. A proponent of patterns and their application in the workplace, Linda and Mary Lynn Manns are the authors of Fearless Change: Patterns for Introducing New Ideas, and editor of Design Patterns in Communications Software, The Pattern Almanac 2000, and The Patterns Handbook.
Linda, what's on your mind these days?
Bonobos and evolution...How did you get thinking about that?
We don't make decisions logically? How DO we make decisions?
So how can we take advantage of the unconscious?
Do you find that Agile software development approach allows for using [the unconscious mind] more?
[..."our brains are hardwired for small groups"] Was that an epiphany for you?
What conclusions are you drawing?
You packed your room with your talk, and it was about our nearest relatives, the apes - chimpanzees and bonobos.
[...the alpha bonobo does not "beat up on his subordinates"] Is that what happens with chimpanzees?
You've managed to find the missing link between promiscuous bonobos and pair programming!
You want to be on that team?
This ritual - it's a kind of social conversation?
[Agile is] using more of our brains perhaps, in addition to what we are already using?
How does this relate to your writing on software? chimpanzees and bonobos?
[The "Do Food" pattern,] that's my favorite one.
show all  show all

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
Nice analogy - I relate this to Theory of Constraints by Juan Bernabo Posted May 19, 2007 3:55 PM
Re: Nice analogy - I relate this to Theory of Constraints by Deborah Hartmann Posted May 20, 2007 5:26 AM
Re: Nice analogy - I relate this to Theory of Constraints by Juan Bernabo Posted May 21, 2007 11:11 AM
Too bad the bonobos are dying out . . . by Bruce Fancher Posted May 22, 2007 1:55 PM
great interview Deb by Michael James Posted May 22, 2007 6:22 PM
Re: great interview Deb by Deborah Hartmann Posted May 23, 2007 8:12 AM
Re: great interview Deb by Michael James Posted May 23, 2007 4:24 PM
Please do not adjust your set... by Deborah Hartmann Posted May 25, 2007 10:33 AM
Re: Please do not adjust your set... by Deborah Hartmann Posted May 27, 2007 12:37 PM
  1. In my opinion the bonobo or chimpanse analogy I take it just as analogy, I have seen both behaviors on humans so I cannot think this differents behaviors came from diferent genetic ascendants, don´t like to push metaphors too far, but they are usefull. Maybe I don´t know all the details, so. Anyway I think this is good to have a metaphor that we can use to reason, to free us from other models, and for me that´s enough, this ideias resonates with my own experience. I think we are not prepared yet is to fully understand the constraints we have in effetive communication, thinking, conceptualizing, we tend to see human comunication, human behavior and thinking skills as unconstained activities but they are not. Problably, don´t really read about it, but my experience supports that our brain have a lot of constraints, we don´t really understand yet. Also analysis wich is our conciense prefered tool, is not a good tool for understanding complex systems, so we need to start creating ways to tap into the unrealized potential of our subconcient and intuition that are more adequate for this tasks. I see intution, as a powerfull processor for deep cause and effect parrallel boolean evaluations, every time we ask a question to ourselves we have an answer a gut response for yes or no without detailed analitical explanation of facts, when we start analysing we mess things up. If this is a constraint maybe is better not to try to explain things in a lot of detail but to use a ritual of food sharing would be more effective, to improve our believing skills in other people ideias even not understanding them fully. This constraints are like physical constraints, we are equiped with intuition about rules in a physical world, it´s just plain stupid to make a machine do two things simultaneusly, but we try to do it all the time with people, we really can´t see this kind of constrain in people. Or be in two places at the same time, in our physical world we understand this is impossible, but we try to do it on our conceptual worlds. So constraints are not bad thing, they are very real and part of our reality, but we tend not to recognize that they "exists", and effectly subordinate everything to this constraints, like face to face communication, and then elevate this constraints, like skill and team building in a team thru peer programming. It´s good to know that the software industry problably will be one of the introducers of principles, values and practices more effectible aligned with kwnoledge workers constraints massivally, this is a welcome and needed revolution in our work world. Juan.

  2. Juan, thank you for your thoughts. You wrote: > ...my experience supports that our brain have a lot of > constraints, we don´t really understand yet. > ... > This constraints are like physical constraints, we are > equiped with intuition about rules in a physical world, > it´s just plain stupid to make a machine do two things > simultaneusly, but we try to do it all the time with > people, we really can´t see this kind of constrain in > people. Or be in two places at the same time, in our > physical world we understand this is impossible, but we > try to do it on our conceptual worlds. I laughed when I saw this, because I am currently in the middle of facilitating a 3-day RecentChangesCamp event in Montreal (called RoCoCoCamp), with people who are very used to collaborating "in two places" (both where they are internationally, and on wikis which are virtual workplaces). Something I've heard a couple of times during the event how our meeting face-to-face here is generating some amazing breakthroughs for them - even for people who have collaborated before online, and for subjects discussed many times before! We're using the OpenSpace method to run the conference... which explicitly encourages people to listen to their "gut feeling" and follow their intuition to find fruitful synergies and like-minded discussions. This is very strange for some, at first. And yet, it works every time. When we make space for the unconscious to contribute to what we are doing, some amazing things happen, seemingly by magic! Oh, and "do food" is an important part of this conference - by design! :-) I don't understand what you are getting at here, in relating this to TOC: > So constraints are not bad thing, they are very real and part of our reality, but we tend not to recognize that they "exists", and effectly subordinate everything to this constraints, like face to face communication, and then elevate this constraints, like skill and team building in a team thru peer programming. Can you say more about this "subordinating" we do? Is it a positive or negative thing, in your opinion? Are you talking about sub-optimization, or something else? I am interested to hear more. thanks deb

  3. Deb, The problem cames when we don´t "subordinate" things to existing constraints. Theory of constraints talks about system improvement and subordinating is one of the 5 focusing steps to cause improvements in a complex system. Take a look at it: http://en.wikipedia.org/wiki/Theory_of_constraints A constraint is like a broken car in a road, even the capacity of the whole road is big, one single broken car is limiting the trougthput of all the "system", we cannot improve the system trying to go faster, it would makes us slower, so we need to subordinate to this constraint, so we slowdown first. So intuitively we already learned this 5 steps in the physical world, need to learn how to apply to the knowledge world. Note the use of the word "cause improvement", we can´t just improve systems directly, when we try more problems are created, but we can cause improvements, sometimes changing something not directly related, like for instance software development life cycle. My experience with organizations, teams and people, including my self is that when I try to push for a change I normally get the same amount of resistance that I´m pushing, or it doesn´t show resistance, it moves but after a while it returns to the same behavior or state it was before. So TOC says that these are undesired effects of some low level cause, and TOC normally relates this very source of a lot of udesired effects to a paradigm, or how we meassure the system, that is aligned to the paradigm in use, for instance if we meassure sucess as not deviation from planned. If really there are constraints in our brains, things we are hardwired, and we really have concrete limits, better listen to them and "subordinate" everything to this constraints, not try to work against them or ignore them as they are "real". So the way we work, communicate, plan, learn, execute or whatever has to be designed around this constraints, they must be "subordinated" to them, and not try to ignore them. If you ignore them you will get a lot of undesirable effects and you will be lost into a lot of fire figthing, things you created in first moment for not "subordinating" things to the constraints we have. For instance there are some evidence that our learning habilities are dramatically dropped when facts are separated in time and cause and effect are deal by different people, so our brains cannot capture cause and effect and we cannot relate one to another, so we simply don´t learn, even we reapeat again and again the same uneffective thing, at vomitum. That´s the only explannation possible for some organization that try waterfall once, fail and continue trying and failing, things are really far away in time so our brains cannot relate cause to effect and effectibly learn. The ones who experiment the undesirable effects are not the same as the ones that caused it, and things are separated in time, so no learning can happen. So having the people that defines what to do and the ones that produces together and the definition the realization close in time too will take care of this constraint and solve a lot of undesirable effects too. What do you think? Juan

  4. Back to top

    Too bad the bonobos are dying out . . .

    May 22, 2007 1:55 PM by Bruce Fancher

    Too bad the bonobos are dying out . . .

  5. Back to top

    great interview Deb

    May 22, 2007 6:22 PM by Michael James

    I've linked to it from here: http://danube.com/blog/michaeljames/aping_the_bonobos I'd like to see more studies of social behavior as applies to Agile development and teamwork. --mj

  6. Back to top

    Re: great interview Deb

    May 23, 2007 8:12 AM by Deborah Hartmann

    Thanks, Michael. I just taped one with Joseph Pelrine, but it will be a while before it's edited and written up :-)

  7. Back to top

    Re: great interview Deb

    May 23, 2007 4:24 PM by Michael James

    My first review of the Linda Rising interview was too risqué or something, and had to be rewritten. I guess the topic does make people uncomfortable, which could be a clue that it's important. My other favorite was your interview with Ron Jeffries on Running Tested Features. I give out that link to my students. --mj

  8. Back to top

    Please do not adjust your set...

    May 25, 2007 10:33 AM by Deborah Hartmann

    We're having technical difficulties with the layout of this page, for some mysterious reason. Please enjoy the video and bear with us on the layout issue while we investigate. Thanks. Deb

  9. Back to top

    Re: Please do not adjust your set...

    May 27, 2007 12:37 PM by Deborah Hartmann

    Problem fixed. Now, isn't that better? :-)

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.