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.
That's an interesting question Deb, and I guess the answer would have to be "the brain". And it seems like a strange topic for someone who has been in the software industry for as long as I have. But I think everybody in software would be interested in the brain and what we believe about the brain and how we use our brains, and maybe how we could use our brains better. I got interested in the brain through writing the "Patterns for Fearless Change". When we started I was writing "Patterns for Introducing New Ideas", and I was thinking about patterns and Agile practices; the reviewer at one point said "These patterns are really based on a lot of science, a lot of experiments in behavioral research", which is an area I know absolutely nothing about. And I began to look at social psychology, cognitive psychology, evolutionary biology, and what I learned is that the patterns work not because of some magic or because experienced people know something that the rest of us don't know, but because we're hardwired, we've evolved to behave in certain ways, and that evolutionary trend has influenced the structure of our brains.
The idea for the presentation actually came much later. The interest in the brain kept getting wider and deeper, as I learned about influence strategies and how to convince other people of good ideas. It's something we in the Agile community struggle with. We come to a conference like Agile2006, we go to a couple of sessions, we get all excited about trying pair programming or test driven development, and then we go back home, and on Monday morning we face a team of people who struggle with deadlines and getting through the day and they really don't want to listen, they don't want to hear about new ideas; they are resistant. Then we struggle with how to get these exciting ideas into practice.
I thought it was a matter of logic. I'm a logical person, you're a logical person, the people on my team are all smart logical people, so if I want to introduce something like pair programming, or stand up meetings, or Scrum, XP, maybe the full blown or just a little practice or two, all I would have to do is outline the logical reasons for why this is a good thing, and then we will all decide logically, "Yes, that's a good idea, let's do it, or not". And it's not that simple, and the reason turns out to be that we don't really make decisions logically.
Most of the decision making goes on unconsciously. In the presentation I gave at the Better Software conference last month, I have a wonderful picture and it shows a giant iceberg. Cognitive scientists used to say "The conscious part of our brain, the logical part of our brain is the tip of the iceberg, and the rest is the unconscious". But now, evolutionary biologists say "No, I'm afraid not, the conscious mind is more like a little snowball sitting on top of the iceberg, it's very tiny. And the rest is unconscious". The unconscious mind is very powerful, knows an enormous amount and yet we don't use it properly, we don't take advantage of the power of the unconscious.
There's a wonderful book that I've just finished reading that points to some concrete steps that we can do; it's called "Strangers to Ourselves", the author is Tim Wilson, who is a cognitive psychologist; he says that in order to take advantage of the power of the unconscious you first do what logical mind would suggest anyway, which is data gathering. Suppose you want to make a decision either as a team or an individual, about adopting an Agile practice; or as an individual you want to decide whether you want to buy a particular house or not, or move to another city, or take up a new career or any other important decision; the first step is data gathering and the logical mind will agree with that, and say "Of course, how can I logically make a decision unless I understand what all the parameters are, all the things that I would have to consider".
So do a lot of data gathering, learn about the different cities, pull out your power point presentations on Scrum or XP, let's learn all we can about them. What problems would our team solve if we adopted this Agile practice? And then instead of logically thinking about it, go to sleep.
I was talking to Dan ... yesterday and I said: "I am struggling with something now, how do you know when you have enough information so that you can sleep on it" and he said "I think it's when you can have a good night's sleep". Suppose you are struggling with something, and you are worried about something and you don't sleep well, do the data gathering, and when you find you can sleep it's a signal the unconscious part of your brain says: "Ok I have enough now, it's my turn". And then go to sleep.
I was a mathematician before I became a computer scientist, and many times I was struggling with a particular mathematical proof and I wasn't getting anywhere. And I didn't realize it at the time but I was doing data gathering in functional analysis, and I was looking at other theorems and what other functional analysts had done, I was going through a data gathering stage and then I would be worried about it and said "I can't deal with this anymore, I'm going to sleep". And wake up and find that the solution was there. And that's a technique I think we all use and we don't realize that what happens is the unconscious has been data gathering and then when we sleep the unconscious mind can grind away on that, and when we wake up the unconscious will have sent the conscious mind all kinds of little signals: "Ok, here's what you need to do". And what we say when we find that solution is "Well I just went with my guts, or my heart", and really what we did was our conscious mind listened to our unconscious. At one point I would have thought "That sounds like black magic", or something that other scientific band would not pay any attention to. But now there is enough scientific evidence from the cognitive psychologists who do experiments on decision making and from the evolutionary biologists about what our brain is really like, that we can now say "This is actually a scientific procedure and something that we should take advantage of". We shouldn't struggle logically and try to introspect looking for solutions, "What's the best way to do this? Let me think about it". The conscious mind has a limited amount of information and limited processing power. It's serial as a processor, whereas the unconscious can multi task. The analogy with computers is the logical part of the brain is like the display, the unconscious is CPU, that's where all the power resides.
I believe so, and the talks that I gave here might have seemed to some people a little frivolous. I was talking about chimpanzees and bonobos. What I was trying to point out is evolutionary roots for a lot of things that our brains are hardwired to do. And when we considered the success of Agile development, I think we have to look at those evolutionary, biological roots and say: "Maybe the reasons why pair programming works so well, or the idea of keeping teams small, is that we are hardwired to perform best in that kind of environment".
And the example that I gave was for a pattern that I wrote some time ago called "No more than Ten". And the data for that came from a lot of retrospectives that we did at a medium sized company where we were transitioning from large legacy systems to small teams and we were using Scrum. And we had a failed project where management was afraid to follow the practices; what started as a very good 6 person team grew from 6 to 70 in two weeks, ran uncontrolled for 18 months and produced nothing. So at the end, management said "You know about patterns and certainly we don't want this kind of thing to happen again; maybe there are some patterns that we could look at?" We did several retrospectives, we looked at what has happened to this team, and one of the things that came out of it, out of the failed experience, and also looking at successful teams, was this behavior of staying small, that it was more than just that developers don't like to have suddenly this enormous increase from 6 to 70, but we are as a species more comfortable with very small teams - and in particular the numbers that came out from the team leads over and over again in the small successful teams was the number 10. Since I repeatedly saw this, I thought "I'm going to call this pattern ‘No more than 10'". And I put in the data from the retrospectives, and I looked at some published works.
At the time all I could find was that there was a little snippet in the "Mythical Man Month"- Fred Brooks, a very famous book about software development-; he talks about the structures of teams and he actually says 10 as an upper limit. Look at Donald Norman's book on "The Invisible Computer" where he talks about the development of successful interfaces and he actually wanders off into a discussion of team size and he also says 10. And at the time in this company there were no books on Scrum or XP or any other Agile practice; but there were a handful of people, who were very helpful to me, with whom I exchanged emails, and they said "Linda, here's what we've seen". Ken Schwaber was one, Jeff Sutherland was another, Norm Kerth was just starting on retrospectives, and those people also said 10. So at the time I felt that was a "magic" thing and I wasn't a believer. Now that I've communed with the evolutionary biologists they say: "This is a real number and it has to do with the hardwiring that comes from sitting around the cave and telling stories to the people that you are closest to." And the people that you are closest to would be your immediate family and maybe a part of an extended family, an aunt or an uncle, someone that you adopted, but that would be a very small group of people. Since we are in a sense still sitting around the camp fire, we're still in the caves, our brains have not evolved, that we are most comfortable with small groups of people, and that 10 is a real, hardwired limit.
It was a difficult and intense struggle to say "Those things that I've rejected out of hand as being black magic, I was forced to wake up and see that this is a real thing, as real as any of the other scientific or mathematical concepts that I had encountered in my long career as a mathematician and computer scientist". And maybe that's why I give the talks, 'cause I've given several lately, I'm trying to convince myself.
That we are a lot more interesting than I originally thought, that the way people think and interact, and the way to get the best product out the door has more to do with some of those fuzzy things I've been running from all my life, than with the technical things that I thought would save us.
I didn't even know there were bonobos until about a year ago, when I was listening to a National Public Radio (NPR) interview with Franz deVal who's a primatologist, and he has a new book called "Our Inner Ape". In it he says that a lot of us who study organizations and teams have always looked at the chimpanzee model, because at the time we believed that chimpanzees were our closest biological relatives; chimpanzees are hierarchical, alpha male dominated, aggressive. If we show those tendencies as humans in our organizations, this would be a natural thing, since we have evolved from probably a common ancestor. But since our closest relatives had this behavior we certainly show it in our behavior, that it was a natural thing and we would just have to suck it up. Now they realize there is another close relative, the one you mentioned, the bonobos. They are equally close: we are 94.5% genetically the same. We could also look to the bonobo culture, which is very different from the chimpanzees. They are female dominated; even though there is an alpha male, the alpha male turns out to be the son of the alpha female, it's only because of her sponsorship that he has this position. This is not an aggressive position where he beats up on his subordinates.
Yes, unfortunately. The story that Franz deVal tells is this: suppose you have 2 groups, one group of chimpanzees and one group of bonobos, and you throw a bunch of bananas into the middle of the group. What would happen in the chimpanzees group is that everyone will get very excited and there will be a huge battle, and the alpha male and his supporters will physically beat up on everybody else, and they will get the bananas. The alpha male might share it with his immediate supporters, because they can't stay in their position alone, they're very political. The supporters would get some bananas and also maybe the favorite consort of the alpha male will get a few, but that's it. Everyone else has to settle down for the leftovers. Suppose we throw a bunch of bananas into the middle of the bonobos. They also get excited about bananas, and they begin jumping up and down, but their immediate reaction would be to have sex. And everyone would have sex with everyone. Males with males, males with females, females with males, young with old. And there will be a lot of sex and then everyone would share the bananas.
I thought about this interesting culture and I realized there was an interesting paper that Arlo Belshee wrote last year, was called "Promiscuous Pairing", and how their team had a matrix to show that if everyone paired with everyone else, their productivity went up, the number of bugs they had to face at some points went down. http://agiletoolkit.libsyn.com/index.php?post_id=15636
Actually chimpanzees are also promiscuous, but the difference is that chimpanzees don't enjoy pairing, it's for procreation only. The power struggles in the chimpanzee cultures are about bananas, the food, and about sex. Usually only the alpha male or his supporters are the ones who are mating with the available females. The struggles that go on there are power struggle. Whereas the bonobos don't have those power issues and they resolve them with sex, which is just a ritual. I'm not advocating that we have promiscuous sex in Agile teams, although that could be an interesting topic.
You could probably convince me. Someone asked me: "Linda you're incredibly old, and we are having trouble keeping women in computer science. What is it that has made you stay in the field?" And my response - Mary Poppendieck agreed with me on this- was that we are surrounded by increasingly younger males. The secret is out now.
My point is that bonobos have found a ritual for resolving conflicts and for working together and sharing limited resources. What we found in the Agile community are a lot of rituals or practices that connect with our inner bonobo. They are not really part of the chimpanzee culture at all. We are looking at small teams that communicate, that work well together, certainly the bonobo culture represents an attempt for a community, to all to communicate with each other; it's not just the alpha male who gets to mate, but everyone mates with everyone. And some people might be upset with the idea of females mating with females, but it's not a homosexual thing because everybody mates with everyone. There isn't any sort of restriction there, they are all definitely promiscuous.
It's exactly that. It's a ritual and a way of overcoming other differences. There are all kinds of stories about two bonobos meeting on a branch and they get to an impasse, and one can't get pass the other, and they begin to get a little aggression: "Get out of my way!", "No, you get out of my way! I was here first". One of them will initiate a sexual maneuver, touching the other one in the right places and the other one says: "Oh, that's nice", and then they have sex and over the cigarette at the end they say: "Oh did you want to get pass? No problem! Have a nice day". I don't know how you say that in bonobo, but all those issues are resolved.
In pair programming a lot of things that we were talking about today about how to involve women - and this was another paper that I referenced in the talk - was that a lot of women seem to have more success in software development; they are not only encouraged to go into the filed, but they are encouraged to stay. When pair programming is part of the ritual of software development, it's the way we do software development.
I also referenced another paper that was never published, written by 2 women who said: "We are ready to drop out". And there are a lot of women who feel that way, they get discouraged, and then they were put on an Agile team and because of the set of rituals, but they couldn't point to anything specific, except the pairing, and because of the way the pairing was done on the team, they stayed. The paper was not accepted because the reviewers felt that there wasn't enough of an explanation of why they stayed. This is an experience, all you can say is "we decided to stay, we think it has something to do with pairing", but it's not an acceptable reason.
I'm going to come back to the brain and I will say that what I've learned from the limited studies I've been doing over the past several years is that a lot of that is unconscious, is hidden from us and we don't really know why we do things, we don't know why things work. I don't think we understand the success of Agile development and that's one thing that gets in the way of convincing others. They think it is a strange collection of people who don't like documentation. And it is much more than that. I think it's hooked into a lot of the ways we're hardwired.
Absolutely, it's ....... our inner bonobo.
Now, everything I do is colored by what I know about bonobos and what I know about the brain. I'm a little less reluctant to jump in and logically think things out and more opened to thinking about things like if we involve as many people as possible in this decision and we do our data gathering and then we all go home and sleep on it, not necessarily in promiscuous pairs, we're more likely to come to a better conclusion. And if we use all the resources that we have we can help produce better products and there is an element that runs through this that doesn't appear in the chimpanzee culture, but it's so obvious, if you remember the pictures of the bonobos having sex, and as you remember they were smiling. One of the comments from Arlo's paper about that team was this: "where we had the promiscuous pairing we had so much fun. It was a highlight of my career". And when you talk to people who do Agile development, if you take the time to think about it, they all say that. "We enjoy it." "It's a fun thing." And I think that's an important element, a bonobo piece, because the chimpanzees don't have sex for fun. They do it because the alpha male says "this is a pink woman, I own her" and he's not consciously saying "this is only for having more chimps" but that's it; as for the bonobos, they have sex all the time.
You liked that one? And I thought "oh well, this is kind of a frivolous pattern". It is powerful because way back when we were sitting around the cave the people that we shared food with were the people that we trusted, the people that we honored and respected, the ones that we listened to, that's where the stories were shared, that's why we were sharing food. So we're hardwired to do that. Food is a very strong and powerful influencer. Having a cup of coffee with someone while you're talking is very important. [And Scotch?] Anything counts: that chocolate chip cookie, or that diet coke, or that latte or whatever it is that most of the patterns have underneath them, taps into the unconscious mind or inner bonobo.
Nice analogy - I relate this to Theory of Constraints
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.
Re: Nice analogy - I relate this to Theory of Constraints
> ...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.
Re: Nice analogy - I relate this to Theory of Constraints
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:
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?
great interview Deb
I'd like to see more studies of social behavior as applies to Agile development and teamwork.
Re: great interview Deb
Re: great interview Deb
My other favorite was your interview with Ron Jeffries on Running Tested Features. I give out that link to my students.
Please do not adjust your set...