 to thinking, conversation, questions, things of that sort, so I will not be overly involved in actually giving the presentation. Self-organizing teams are something that are talked about a lot in agile. They are supposed to be one of the agile virtues, the ability of having a self-organizing team. Something magical is supposed to happen about that. The concept is relatively simple. You get a whole bunch of people in the room. You give them some autonomy. They organize themselves, don't require management and close direction and things of this sort, and they just magically, somehow or other, coalesce into this high-performance, high-functioning organization or entity that is able to produce software. A lot of misconceptions about that whole notion, and it's not very well-grounded in any kind of understanding discipline, science, anything of that sort. So we're going to start off today trying to explore a look at those foundations to begin with. So we see things that we call self-organization, and which we have used as metaphors for what we want to have happen in our organizations, in our software development teams. We can see it in chemistry. We can see that if you add two solutions together, they will spontaneously crystallize into a very defined, very rigorous structure. That's a kind of self-organization of the atoms and the molecules. We see it a lot in biology, and biology is the ultimate source of how we have been thinking about self-organization. The cell, from the basis of a cell up to the basis of an organism, these are all examples of self-organization. We see it in complex adaptive systems, which is another part of what is talked about in Agile, that we can have self-organization because we are a complex adaptive system, and we see complex adaptive systems from all the way up to societies and cultures as these kinds of self-organized phenomenon, an emergent phenomenon. They aren't something that you can direct, something that you can control. It just magically happens when you put all of the right ingredients together. Same kind of thing. Agent-based systems are really kind of a corollary or a subsidiary of the overall notion of complex adaptive systems, but this would be birds, things of that sort. The common thread from all of these things is that we say self-organization is a way of getting some kind of order out of chaos, that you put a bunch of things together and they just magically coalesce into something that is meaningful and useful. As I mentioned, we're talking about self-organization in kind of the agent-based biological social insect kind of concept. So when we think self-organization, these are the kinds of things that we are most likely to think about and therefore are most likely to be the sources of the metaphor that we hope to apply inside of Agile. We have things like termite mounds that are very complex structures. They have a very complex architecture as seen in that lower left photograph, the real termite mound with the prowling predator in the picture above it, fish schooling, traffic jams are a way of, they are a kind of self-organization. You go out on the streets of India, you have really what is an agent-based self-organized system. Their agent-based systems work by you give autonomous entities very simple rules that they obey and they, by each individual obeying that same set of rules, they give this manifestation of order or organization at least. The only rule in Indian traffic is don't run into the person in front of you. This kind of order was talked about in biology a long time ago. One of the people who has popularized it and brought it into the realm of the software world was Umberto Machirana working with Francisco Varela and they wrote a book called The Tree of Knowledge. They later worked extensively with Terry Winograd at Stanford and developed or tried to use and apply these theories to design in software, the design of software and tried to figure out how design of something could come from these kinds of self-organizing principles. Autopoiesis is the really cool name given to this idea or principle of self-organization. It's very simple to describe. You have entities, the little circles are individual entities that may or may not be substantial so it could be a protein in a cell for instance. But these semi-animate entities start to establish relationships with each other and these relationships are really basically stimulus and response that I emit this kind of stimulus and somebody else receives it and responds to me. If that stimulus response cycle gets reinforced then we are said to be structurally coupled and we can, that would be the horizontal arrows between the two circles. That's an example of structural coupling. There is also a second aspect of that structural coupling and that is to the total environment, the total context in which you exist. So there's this idea or notion that the context and the organism that self-organizes in that context are inextricably linked and are in fact one and the same thing at a very fundamental kind of level. You should also note that the horizontal structural coupling, from the point of view of either one of the circles, the other circle is just part of the context. It's not like two little things inside of a common context dealing with each other. You can take this simple context and you can move it up to the point that you have what Varela and Maturana call third-order structural coupling where you can have structural coupling between these entities in the context but you can also have it within entities within the entity. So the idea or the growth of a nervous system would be an example of this kind of structural coupling and we self-organize so that we can get really complex organisms like yourselves that have a nervous system have all kinds of structural coupling with other aspects and elements of yourself. Then these complex entities still can participate in the same kind of structural coupling with their context and with other entities which are part of that context. But autopoietic systems organize only to establish and maintain themselves. A cell has no clue what it's doing or what it's contributing to the rest of the body and doesn't care. Your liver doesn't really much care about the rest of your body, it just is and it organizes and maintains itself and that is not sufficient so we can look to some other ideas that might give us a better hint or a better clue about the kind of self-organization that we are actually seeking or that we think that we are seeing in our agile teams. So these are seven principles about large scale well small two large scale systems. They are supposed to if these seven principles are present in a system it has the capability of organizing itself to itself and they apply from cells all the way up to civilizations or cultures a very large scale macro phenomenon. You need population variation. You have to have a variety of things in your environment. You need to have some kind of persistence that when a new combination or a new structural coupling comes into place it has to be able to survive more than a nanosecond. You can't have structural couplings between atomic elements above a certain number because they don't live long enough. Don't persist long enough. So you have to have some way of maintaining yourself at least for a while to participate in the later phase which is the competition phase. You need to have reinforcement that structural coupling is a statistical phenomenon. So if the mutation occurs in a biological organization that mutation has to have some stability it has to be able to last for a while but it also has to have company has to have companions it has to have that mutation replicated in other parts of the organism so that you get this kind of reinforcement so that you can really see what the consequence or effect of that change is going to be. Then you have the competition. This is the evolutionary mechanism that we compete for market share so to speak inside of the biological environment which we exist in the week die out. We need cooperation so this notion of some kind of symbiosis and also the very importantly this notion of co-evolution. So I have said several times that the structurally coupled entities and their context have to mirror each other. They are in back mirrors of each other. You have to have a co-evolution. Human beings are the absolute best ultimate example of that. That we adapted to a natural environment in which we existed. Then we busily proceeded to change that natural environment and then we would co-evolve with it. So as we changed our environment to eradicated diseases things of this sort we became bigger and longer lived and all kinds of other things. But then you can get to a tipping point where you end up destroying the very context which makes you sustainable. So this idea or notion of co-evolution is very important. Then you need combinatorial richness. You need to be able to mix this diverse population together in different ways. You have to have a fairly high mutation rate so to speak. Ability to recombine and restructure yourselves in different ways. And then you have to cycle through this over time so that it is very much an evolutionary kind of a process. So these seven principles they do describe very well self-organizing systems at almost any level of scale. Unfortunately, yes, can't. So the question was is how do we see competition within self-organizing teams? And the short answer now is can't but I'll come back to that in just a second. So even with these seven principles and when we're looking at things as large scale as a culture or a quote self-organizing team in an agile process or an agile environment, they still are focused on the self, on the organism itself. There is no sense of purpose that we have not organized for anything beyond maintaining ourselves, establishing and maintaining ourselves. So self-organization gets you that far even if it is at a very large scale. So a culture exists to preserve itself. It doesn't exist to make you a happy human being yet exists to preserve itself. What we really want is not self-organizing systems so to speak or we want a variation on self-organizing systems which are called allopoetic systems instead of autopoetic systems. An example of an allopoetic system is something that is organized to produce something else. Factory is the exemplar. People put together factories, they assemble all of that heavy equipment. When we are building software, we're busily taking all these little modules and putting together in order to produce something else other than just the modules themselves. So an allopoetic system has a purpose. It does things of interest and of value and they're easy to get. Really good thing. You can take any random combination of the people in this room, put them together. They will self-organize and they will produce software. Unfortunately, they will produce, they will organize themselves and produce software of the that reflects themselves in accordance with their context. So they're going to self-organize any time. Don't care if you're officially doing Agile or not. You put a team together and tell them to self-organize and do productive work. They're going to self-organize and do the exact same kind of productive work that they always have because you haven't changed the whole context. And in point of fact, it really doesn't matter whether you change the whole context or not. You can see this in the macro in Agile very easily. The concepts, the principles, the practices that were introduced 13 years ago have been diluted and co-opted and are a pale shadow or imitation of themselves and this is an example of that kind of self-organization in work. A user story looks really weird and strange and makes us very uncomfortable. So we co-evolve. We adapt the user story until it's something that is nothing more than something we already are familiar with and now a requirement. So we busily adapt and co-evolve and in the macro level, it's very obvious to see in the Agile community. So it would only be possible to have a self-organizing allopoetic system if you were in fact changing everything. Some of the things that Agile does affect these horizontal structural couplings. Some of the Agile practices actually do try to establish different kinds of relationships between the entities that are in that environment. But it does nothing about changing the overall context of the environment. And the very first time you saw a book called Agile Project Management is an example of a failure to change to do what you were expected to do in terms of self-organization. You're just re-imposing the old structure onto things. But changing everything will still not give you what you want. You can have a really complex self-organizing structure, an allopoetic structure, like a beehive. A beehive from one perspective is not just about producing more bees and more beehives. So it's a little bit beyond producing itself. It produces honey. You open a beehive and you see honey. And so you immediately jump to the conclusion that, ah, bees exist to produce honey. They're a little honey factory. And totally ignore the fact that bees produce honey for their own consumption. The fact that you like honey, bee couldn't care less. And it plays absolutely no role whatsoever in whether or not that system takes on the form or the structure that it does. So I have been wrestling with this presentation because of where this conclusion leads us. That self-organizing systems for purpose, for creating better software, et cetera, are flat out impossible. Can't get there. You cannot have a self-organizing system that will do what you are expecting when you blithely use the term self-organizing team. It's an oxymoron. But maybe that's not what you really want. Maybe what you really want is a team that has an enhanced ability to produce high-quality working software efficiently. And by efficiently, I mean the proper cost ratio kind of notion. That's what we really want and we say, ah, self-organization is going to give us that. Well, it's not. You can't get that from self-organization. The best that you can hope to is to rebalance, reestablish, reinforce different kinds of relationships, particularly the power and responsibility relationships that exist among a group of people. The power relationship, the autocratic, all-powerful manager, the poor, defenseless little team. Agile helps you restructure or rebalance that power relationship or it's supposed to. The customer and the development team who are bitter enemies and have been for decades. They didn't start off that way, by the way, but they have been bitter enemies for decades. Neither side trusting the other, the user story and the product backlog are supposed to be a rebalancing of that power relationship. And you have to then, you know, take those kinds of ideas seriously. In fact, you want to rebalance that relationship. If you deny access to the customer, deny developers access to the customer, you are not rebalancing the relationship. If you have a product owner or some other kind of intermediary in between, you're just reinforcing the old relationship that used to exist. It's still in us versus them kind of a notion that you have to change that relationship in some real ways. Self-responsibility, accountability and transparency are the other things that make it possible to be a high productive team is that you have to take a lot more responsibility. You have to accept a lot more accountability. And the other side does as well. You have to rebalance and restructure that relationship. And then transparency is one of the biggest ones of all. So we have heard, I've heard a couple of presentations here today talking about Craig Larmann's keynote that this absence of transparency. So the little exercise of people reporting up the chain of command and obfuscating things along the way, that's not very transparent. So transparency is absolutely essential if you want the outcome that you want. Doesn't come from self-organization, it comes from courage. One of the four XP principles that have pretty much diffuse throughout all of Agile. So if you want what you think you want from a self-organized team, you're only going to find it and get it by exploring this idea of courage and how you enhance courage. So Confucius, popularly known as Confucius, talked about names. You're going to have disorder under heaven until everything gets their proper name. So what I am suggesting to you is follow Confucius' advice and drop self-organization from your vocabulary. Bodhidharma said, you know, this pursuit of this particular thing, like understanding self-organization, tends not to edification. It's not going to get you anywhere. It's a pointless term to have in your vocabulary. What you should do instead is look at what are the roots of courage? How do we increase and maximize the courage of the people and the team? A number of different kinds of things and they're all existing Agile practices or Agile principles in some form or another. Transparency, make things visible. The notion of big, visible charts was not just for counting progress or measuring progress or giving quantitative information about how the team is doing or what they are doing at any point in time. It's existing to make the tacit implicit. One of the really critically pieces of tacit information, really critical pieces of tacit information that exists in the team is individual contribution to the team effort. I teach. I had been a professor for a long time, now transitioning out of that, but I assign team projects. And guess what? You give a bunch of students a team project and one or two people in the team do all the work and the rest just kind of sit there and watch what's going on. Will anyone come and tell the teacher, no. Does everybody in the team know that information? Could they tell you probably to a decimal point? Who's contributing what percent of the effort to that team thing? Of course they know. One of the things that the anthropologists have studied and have been aware of are forms of reciprocity. And there's this form called balanced reciprocity. It's where everybody contributes in a balanced fashion or that the exchange is fair. Both sides arrange for an exchange that is equally fair. So you get a group of friends that go out to dinner or drinks every Friday night. And different people pay at different times or you split the paycheck at different times. Over a long period of time, six months a year, you could sit down and you could interview each member of that team and they could probably tell you with accuracy less than a dollar who was at a balance in that team. So yes, so and so. They pay their share kind of, but they're about $3.77 in arrears in terms of what everybody else has contributed. We know this stuff. Big visible charts make it overt and explicit in a way that it can't be denied, can't be hidden and where it can have action taken upon it. The Baldrige quality method, this is one of the critical principles of that is this kind of transparency. So if you want to see what, if you want to improve performance, make the performance public. You're not violating any confidentialities. Everybody knows it anyway. You're just making it overt where it can't be ignored. When you do your estimates, do honest estimates, we have a number of different practices that are supposed to get you to some kind of consensus estimate about how difficult or how hard a particular user story is going to be to implement. And the games are designed to force consensus, not accuracy. The only way that you can get accuracy is by paying attention to the person who has the most experience with that specific kind of activity or result that you're seeking that's implicit in that story. So you need to be able to give honest estimates and you can't do fudge factors. This is all in standard agile practices. You're not supposed to use fudge factors. You're supposed to be real numbers so that you can compute ultimately a real team velocity. Same thing when you're doing a budget for your team. It has to be honest and as accurate as you can make it, not in any way fudged or made explicit. The idea of mood walls and retrospectives. These kinds of things need to be taken into conjunction. You need, again, as part of making the implicit, tacit, explicit and overt, you need to have everybody aware that, yes, nobody's happy. That's a kind of a courage and these are tools or techniques for doing it. When you're doing your retrospectives, you can't tell you how many times, there's lots of kudos to go around. There's very seldom much in the way of self criticism when it comes to things that we should do differently or do less of. Not much thought given to experiments. I'm saying this with great trepidation because we have the retrospective guru in the room and she can probably contradict everything I just said but this is my experience. Collective responsibility. The idea or notion that the team is a team. There is no I in team is a good thing up to a point. The team cannot afford if it's going to be as good as it can be. It really cannot afford to have free writers in the team and it can't have people in the team who are resisting the collective efforts of the rest of the team. So it requires courage to confront a fellow team member and say you're just not cut out for Agile, would you please transfer to another team? But that kind of thing is necessary and again it needs to be public and overt. You need to be able to point at the wall and say look, doesn't matter who you pair with, that pair's performance is lower than every other pair in the room, it's got to be your problem. Please do something about it, change yourself, improve yourself or leave. So collective responsibility has its limits and constraints. For the first-end iterations, the stand-up meeting and its formulaic, what did you do? What are you doing? What issues or problems do you have? Really badly abused. I was at one company, we did, I was coaching, trying to train them in Agile and I was coaching four different teams and they were all having stand-up meetings. First of all, they didn't have them in front of the storyboard, they had them around a phone because one of the team members was in Colorado and the rest of the team was in Indianapolis. So they have their little meetings and they go through their ritual three things but the gist of it was well yesterday I met with so-and-so, today I'm going to meet with so-and-so and I have no issues. That was the whole thing, the whole stand-up and every single person reported the same thing. The fact that they were having these meetings constantly meant that there probably were some issues and if you are just starting out as an Agile team and nobody on the team is reporting any issues, somebody is being really dishonest. So for the first-end iterations, I would mandate that even if it makes the meeting go 15 minutes to 5 minutes, if you can't come up with an issue, you can't leave the meeting because they're there, you're just not being honest about them. And then the last thing up there is just say no and you can't delegate this responsibility strictly and solely to the coach. I know that coaches exist to be an interface between you and the big bad ugly world of management and they're the ones that are ultimately supposed to say no to the managers or yes to the managers, I give me this resource because the team needs it but it's not just the coach's responsibility, you all have to have the ability to say no at different times. This should be generalized also to just say no to doing the wrong thing or that we should not as a team be doing this. So I took you in a direction that came to a conclusion that you can't get there with the vocabulary or what you're talking about that probably, well I hope it was really provocative that you're now sitting there really annoyed full of feedback so I'm open for questions, comments, discussion, anything except you can't throw things at me. So yes, yes, yes, you. My answer is yes, perhaps many ideas, one of the same ideas is you. So my question is, have you actually spoken about this group of people in the line? So the comment was that he disagrees which is really cool that in his conversations with coaches and in his experience he has seen self-organization so he will admit that it is difficult but achievable and in fact most coaches would claim that it's achievable and then the implicit or the explicit question in that from that comment was have I done my research and the answer is yes but the research has taken on a little bit of a slightly different kind of a form is that I actually went and looked at these teams that were reported to be self-organized teams and from an outsider's perspective, so I'm not a team member, I'm an outsider's perspective so I am trying to figure out, you know, or trying to see what it is that they're doing. They're reporting, yes we had this kind of self-organized success but what people tell you and what you can see you're not necessarily the same thing. An example, cultural example totally outside of this domain, the, now I just blanked on the name of the culture, anyhow it's a Brazilian primitive culture, the Anomami are considered to be the most, were considered at one time to be the most violent people on the planet, they were constantly at war with each other, constantly fighting a bunch of little small groups out in the Brazilian rainforest and you ask them why are you so violent and they say oh it's because there's a shortage of women that we have to fight constantly in order to acquire women so that we can continue our existence, that if there were more women to go around we would not be so violent. So the anthropologist sits and observes and says oh gee that's you know that this is semi-plausible explanation but why do you practice female infanticide, why do you kill your little girls, why do you allow the men in your tribe that are too old to have children to have multiple wives including the most beautiful second young women in the tribe. So when I look at these self-organizing teams I see something much different, something much more, these are teams that have in fact figured out a way to have the kind of courage to do what they want to do, they have taken responsibility for doing what they want to do. They report that acceptance of responsibility and accountability as being self-organized but it really has nothing to do with self-organization. So I mean the principle, the concept, the idea is it's irrelevant and so I'm not, I'm not saying that you can't get gelled high performance teams you obviously can, but it doesn't come from self-organization, come from something else and if you really want to understand how to replicate that phenomena or how to ensure more teams achieve that kind of state stop talking about self-organization and start talking about things like courage because that's where I believe you will find your answer. Yes. So again I wouldn't say that self-organization is more aligned with different cultures but it is very clear that different cultures have different, different value systems which lead to very different forms of personal interactivity. A very, very simple example, pair programming, a practice, it is supposed to be one of these things that contribute to self-organization, it really doesn't, contributes to communication. Cultural differences in pair programming. There's a very famous published picture of an American male-female pair programming. The male is sitting vertical upright in front of the keyboard and the woman is leaning way over like this. Cultural differences of personal space. She is not comfortable sitting shoulder to shoulder with the guy. You look at two American males pair programming. There will be at least 12 inches between their shoulders. When I was doing a training here in India I saw my very first example of triprogramming. So two males that are sitting shoulder to shoulder swapping the keyboard back and forth. The third one with his arms around both of them controlling the mouse. So that's a cultural difference in the way that the team interacts with each other. And yes, that very definitely exists. Yes, in the... What is that? Do you actually mean or did I interpret right that it's not self-organization is impossible but it cannot be the instrument that it will lead you to your goal or is there impossibility of a goal first and then self-organization next? Or rather it's would courage just resort to self-organization as we call it. You can't aim for self-organization. Yeah, say it again in the microphone so that I don't have to try and recapitulate. So the first is that what I gathered from the thesis is that self-organization is not a possibility as a cause and you attempt it and that itself it can't be the goal and hence you can't attempt it or is it that courage is the cause that or the instrument that will lead you to this end. And as a result of this actual real question is that as you said in a complex adaptive system and the system itself is kind of determined by the context. And would the context from which we gathered a lot of this understanding be different or is it evolving in itself for example in evolutionary biology most of the earlier complex adaptive systems the concept of intelligence was not was has been gradually evolving and in a more intelligent context is this more possible? So I heard two kinds of questions in there. One is about the possibility of having a of a self-organization occurring that produced produce something of value something something of interest and the other one was about the mismatch between the context and the agile teams. The second one is simpler is that agility is very seldom practice at the enterprise level. It's isolated within the IT at best or within a team within IT more commonly and so therefore the team has no effect over the context in which it operates has very little choice or control about how it's going to evolve into some kind of a structure. The other one the the first question is that if in an allopoetic system you can think of that as if I if I put a random number of machine tools into a factory how likely is it that they would spontaneously organize themselves into something capable of producing a car? Not very likely. It is very possible for a system or you know for a set of entities that share common values that are going to have established be able to establish the right kinds of stimulus response structural coupling with each other and with their environment that they would become like a honey beehive only software instead of honey is their product. They will still be self-organized produce honey for their own consumption the fact that the enterprise then finds value in that honey was a total coincidence. You could probably get to the point of having a higher level macro evolution kind of thing that we have a whole bunch of random self-organizing teams that produce really good software really good honey and then introduce competition at that level among these teams such that the teams that are able to produce the sweetest honey are the only ones that get to replicate themselves and all the other teams join the unemployment lines you might get there that way but I doubt that management is going to allow it yes woman in the back wait for the microphone please it's coming. The self-organizing teams are self-organizing organisms I suppose are changing they're adapting and mutating okay then courage seems to be one of the things that changes the structure of the relationship with the environment it's something you put into the change but things like you can't affect your company's hierarchy perhaps you can and self-organization is a way of injecting adding courage into the team and into the whole organization so into the management structure to expect that if I've got a problem and the company's policies are affecting it not allowing me to produce or do something at the right rate that I can have that conversation with you and if you are unable to change that policy you can at least understand the impact on me so we can come to an agreement of another way to approach it so everything is then mutated by adding courage and you have then a different kind of organization that has become a different thing would that work as an alternative to self-organization doesn't work or you can't have it so if you have a team that is that does have courage that can say no that can structure their interactions with their environment and their context in an appropriate fashion you will probably also be part of a team that has a lot of information and data at its disposal so that it's better able to make the right choices the right decisions so that when they say no they say no to the right thing when they say yes they say yes to the right thing if you wish to call a team that has courage and has knowledge a self-organized team I can't prevent you from doing so but I would say that you are violating the understanding so self-organization is a metaphor that was borrowed from other disciplines and applied to our own discipline and in doing so we either have to corrupt the meaning or abandon the metaphor and all I was suggesting today is abandon the metaphor and focus on the things that are really important like how do we have better information how do we have increased courage and if you want to call a self-organization it's not going to hurt anything but it it can mislead your future research when you go and look at well how do we get more of this then you're going back to the metaphor you're saying well how does a biological system get more self-organization or more self-organized and you see those principles that I enumerated and none of them are going to help you but if you say well I'm not looking for self-organization I'm looking for information knowledge and courage which is you know the other the other four values you know the communication and feedback you're going to find your answers to the high performance well gelled well organized well structured team there you're not going to find it by exploring the concept of self-organization you talked about bringing about structural changes to have a meaningful change what are your thoughts on Kanban which talks about an evolutionary approach to change without changing the structure okay please say it again I didn't quite you talked about meaningful change can only happen if we bring about structural changes what are your thoughts on Kanban which talks about evolutionary change without changing the underlying structure so I'm I'm hearing and I'm not sure that I'm hearing correctly the relationship between individual change or discrete changes and structural changes and you know the the complementarity of those is that close to what what you were saying I'm talking about an evolutionary I mean how would you compare and contrast an evolutionary approach as suggested by Kanban to Kaikaku approach like Scrum which brings about a lot of structural changes okay I will have to confess to being puzzled and invite you to talk to me about it afterwards because I'm not sure I can give you an articulate answer right now thank you but but let's don't don't leave the room without talking to me okay yes depending on your culture depending on well your background or your beliefs or your values so um and I think it's also in the eye of the beholder so I'm sort of wondering if transparency exists okay first part of the answer is that yes it absolutely exists because the kinds of things that you were taught to do in the agile community makes you a part of that culture and so you are supposed to be coming to a collective understanding that this card in this place on the wall or this bar on this place on the wall means the same thing so at that level yes transparency exists so if you want to learn something you want to have an input from another another vision and how could you have an input from another vision if you're already in the same line of thought so so enculturation is the question that so they the set of us in this room that put up these big visible charts to us they are absolute transparent to the novice that comes into that context and it wasn't part of building them they are not transparent they are opaque and they're going to take time to learn them and figure them out I do not agree you can read them in another way you can have another interpretation you can have a very good background from another field and they can mean something else which could be a very good value for the existing this is the second part of my answer is that at an absolute epistemological level no there is no such thing as transparency because everything has to be interpreted but for practical reasons it's transparent for absolute epistemological reasons no there is no such thing as transparency which is why I very frequently will make the distinction between representational things and evocative things so those things up on the wall are transparent only because they evoke the same memory in each of us that participated in their construction they do not contain some kind of a truth because if they if they were each of us would have to interpret them and it would be different so you have to make sure that that is really happening yes it's triggering a memory yes and so that's again that's another one of those avenues that I would explore that if I wanted a team that had these characteristics that I am attributing to self-organization as a term I would go and look at how do we how do we establish a common culture how do we establish the same stories and memories and culture you know that kind of cultural background so that we have reason to believe that those things on the wall are transparent because they evoke the same same kind of constant comments time I saw a tease physical from the back of the room so thank you very much