FrontPage : OpenSpaceSessions : Analogy Fest Boundary Objects
Topic: Analogy Fest: Boundary Objects
Date: 26 June 2003
Convener: Brian Marick
Email address: marick(at)testing(dot)com
+ one other
This session started from Brian Marick's "Boundary Objects" paper, part of Analogy Fest, bringing in analogies from other domains and discussing them in terms of relevance to software development.
Definition (I don't have the paper in front of me -- transcriber)
A boundary object is something common to two or more communities of practice which helps them collectively stay aligned as a community of interest for the purpose of collective action.
Discussion Summary
* to be factored up from discussion transcript; attendees please move up any specific important points
* Examples within software development:
* Examples of boundary objects from the paper:
* Examples from outside software development:
Discussion Transcript (delegate to a discussion page?)
Jeff P: A boundary object can be a token which two parties can refer to. An object, which has both individual meaning to the parties, and a common meaning. For example, an XP "User Story". The entities which emerge in Eric Evans's domain specific language (see http://www.domainlanguage.org) can be considered as boundary objects.
Rebecca: Yes. A boundary object has common momenta; it's not a translation from everyone's point-of-view. There can be multiple communities involved. Essential use cases (Larry Constantine, http://www.foruse.com) seem to be a good example of a boundary object. They represent the essential conversation between a user and a system. Each side can take the abstract steps in an essential use case and fill in the blanks or elaborate their meaning. The XP "user story" of 1-2 sentences requires more trust in common understanding than an essential use case. Requirements done "by example" give me the tough cases that I'd like to work with.
Jeff P: Different degrees of precision?
Rebecca: Detail, rather. I don't think you'd refer to precision when you have multiple ways that they could be elaborated.
Brian: They don't have to be true, they're a tool, or a point of provocation.
Michael: Like "content pivots" in cybernetics. Two streams with a common point but different meaning find the common point a provocation to converge or decide to diverge. You need to establish trust to allow agreement, and a user story supports...
Chris: Boundary objects can be a touchstone within a community of practice, as well as between communities. Developers have some adeptness in discussion invented abstraction layers as system boundaries. Why do they find it harder when meeting with another group? The common patterns of interfaces and protocols don't seem to transfer very well.
Brian: Developers can see the relationships, but the customer can't see how it lines up.
Chris: With developer groups, common goals help them understand common boundary objects.
Brian: In the University of California museum collection example from the paper, there were four communities of interest. Each one of them had a different perspective on why the collection was important to them and met their goals.
Rebecca: There's a person I work with who's good at coming up with explanatory metaphors neutral to the implementation but intuitively satisfying. He might describe an operation as "something stamping something". He's the only person in the development group who's good at it; it's not abstraction, distilling a simplified meaning, it's more inventing a common touchpoint. Not from a "canned" form, but an apt, accessible metaphor.
Chris: That simultaneously expressed everyone's goals.
Kevin: A way of making everyone...
(the notes have a sketch of a flag as a boundary object with common importance but varying meaning which people can rally around)
Brian: I've noticed in reading these papers in science studies, like the one from which I quote the museum example, they're incredibly fond of metaphors which convey nothing to me.
Jeff P: Perhaps like developers' metaphors not being transferable.
Rebecca: The downside with this person's explanatory metaphors was that the metaphor was so apt and attractive, you think you've solved the problem, and you can go on for a couple of months that way.
Brian: There's a French sociologist who works on "Actor Network Theory", he's interested in how science works, but he's a complete relativist. He looked at the networks of professional acquaintances that scientists have, and he has a fairly Machiavellian view of how scientits marshal support for their theories by way of their acquaintances and alliances.
Rebecca: A.N. Whitehead discussed that issue as well.
Brian: Joan Fujimura is also interested in these networks, but from perhaps a more optimistic point of view. She has a paper discussing how the virus theory of cancer went from a minority to a dominant theory. She talks about packages, not just boundary objects, but a set of useful practices which passed along with the theory, a set of biological tests. People could use them for their own purposes, but with the tests came an implicit assumption about the viral theory of cancer.
Chris: My wife received a piece of sales advice in business school, that it's an effective way to exert influence and gain advantage whenever you can spin a story that a particular proposition is "win-win".
Brian: The background to this example, in terms of relevance to boundary objects, was that Richard Nixon had declared a war on cancer. The National Science Foundation agreed to undertake the task. Time had gone by, money had been spent, and the NSF needed to justify what had happened to Congress. So NSF had an interest in showing results which could be partly satisfied by advancing the virus theory of cancer.
Michael: There's some other aspect to boundary objects, not necessarily a political aspect, but one that allows alignment (vs. the museum collection, a common token that does not actually align interests).
Rebecca: That's an interesting question. We like to align goals, right? If we could make software that fits like a glove so that the customer doesn't have to change the way they work, have we done the right thing? Software's supposed to promote change.
Chris: Does a boundary object facilitate communication, or is it more that it effects action or provides impetus and momentum?
Rebecca: Or alignment?
Chris: And facilitating communication more often leads to more discussion and explanation rather than action.
Brian: Perhaps boundary objects are more about action than communication?
Chris: Most of the examples in the paper are really about action.
Brian: An example from my wife's domain, she manages a university large animal veterinary department. Now there are two communities within large animal veterinarians, the "individual animal vets" and the "herd health vets". These two groups have very different goals and barely speak to one another. But she has to find ways to make things happen in the department that both communities agree on.
Brian: Conventionally minded testers are good at finding mistakes. Programmers want to see progress. Fault-finding testers would tend to grate on the programmers. It would be nice to find a boundary object to align the interests of the programmers and testers. It would be nice to think that the acceptance tests might be a place to find common ground.
Jeff M: The tester can think, "Ah, I've really kept that programmer in line," and the programmer can think, "Ah, I really know what they're after me to do."
Chris: The tester's the skeptic, looking for problems. The developer's optimistic, looking for progress.
Jeff P: Tests are necessary to acknowledge progress. I get into the requirements thing, and often the customer's requests are mangled by the analyst into technical requirements without having a boundary object that the customer can refer to, such as an acceptance test that the customer helped write.
Rebecca: I have a background as a "software evaluation engineer" from the start of my career. Developers and testers have different tactical goals, but the same strategic goal overall, to ship a quality product. If people did not trust me to write a good test, they would despise me. I know what you're talking about with annoying evaluation people. I had to learn a lot about the developer community when I was a tester. We really had to understand what each other were doing in order to be most effective together.
Brian: "testers" and "developers" have two different communities of practice; "testers" derive some of their identity from being skeptical, developers from being hopeful, believing problems should be solved.
Chris: The fact that developers could become "test-infected" was a surprise. But the focus is tests which prove the code works, the bias is toward going forward vs. looking at how to break it or looking at it from all the different angles. The developers will get around to that later, why overdo that point of view at the start?
Brian: Testers have trouble with the idea of test-first acceptance testing. They want to look at the various configurations before they feel they can compose adequate tests.
Chris: The spectrum of possibilities.
Brian: The iterative approach of starting with an identical configuration and test, then incrementally adding acceptance tests can lead the tester to ask, "how do we know when we'll have the whole picture?"
Rebecca: Michael Jackson's "Problem Frames" help me ask questions during design, if you understand the nature of the syatem. Michael Jackson would like you to frame the problem beforehand. I'd like on an agile project to sketch out frames at first and to reconsider as development progresses. (Example of frames: connection, transformation, ...). I'll use his technique but not figure that I can get it all right beforehand.
Chris: Outside-in, frame and confine the complete problem.
Rebecca: Jackson advises thinking of one thing at a time, each frame in isolation. When you get down to where bugs are, it's often from neglecting a frame, from considering only one.
Chris: Exploratory testing double-checks the first draft of the "comprehensive" test suite, the "back door". By comparison, the developer looks for feedback from tests, with the customer as "sanity check" or "back door".
Michael: Unit tests in test-first development, they help me comprehend what I'm doing. Then when you get to equilibrium, things are stable enough to be skeptical. Sit with a tester when writing more tests.
Brian: That sounds like William Wake's distinction between "generative tests" and "elaborative tests".
Michael: Boundary objects help you stay converged long enough to get things done.
Chris: Boundary objects as an impetus for action. I'm thinking of the earlier session about advocating agile methods as a non-technical person. Is there a useful boundary object for motivation in that case?
Jeff M: This reminds me of political coalition building, where you propose an initiative that has benefits to the various interest groups whose support you need. The university museum collection made me think of that right away.
Brian: In particle physics, the experimentalists vs. the theorists. The theorists need to "catch" an experimentalist to test their theories, and the experimentalists need a testable theory to work on. There's a notion of "trading zones" in which interests are aligned by inventing pidgin trade languages, a simplified, specialized vocabulary.
Rebecca: That's the goal of an essential use case.
Brian: And building a vocabulary of common words.
Chris: So would the core principles of the Agile Alliance be a boundary object for its members? The manifesto is a call to action based on these shared assertions.
Jeff P: This would have been a different conference, perhaps "XP Development", and there would have been different people here that we would have missed seeing. So the manifesto is a thing people can pretend to agree on which brings them together.
Michael: People having different interpretations of the core principles, and different practices.
Rebecca: And different emphasis on the various principles.
Chris: Jeff M's mention of the U.S. Constitution as a boundary object was a good idea. It's important to lots of people, deified almost, but there are strikingly different points of view about what it means or should mean.
Rebecca: Or do people even read it?
(side discussion of Canada by comparison)
Jeff P: And the United States as a boundary object, something that all Canadians can agree that "we're not!".
Rebecca: I'm thinking of the Rational Unified Process as something that the various agile processes generally agree that "we're not!". But after seeing Craig Larman's presentation on "Agile Unified Process", it seems there's really nothing to argue about, RUP is just a framework.
Brian: Yes, before the Agile Manifesto, you could ask "what's agile" and hear "whatever it is, it isn't RUP!".
Jeff P: There's this notion of common agreement, mutual goals...
Brian: People must be not in conflict, it mustn't be a zero-sum game among the participants.
Jeff P: There are lots of disagreements in the Agile community.
Chris: Those words in the manifesto, we can all agree with and move forward without quibbling on minor points.
Rebecca: These seem like successful boundary object examples. But what about... [something about testing?]
Jeff P: I've had testers show up at my desk and detonate. Is success of a boundary object discussion or action?
Jeff M: Let's look at the example of the card models created in User-Centered Design (Constantine). You get this group of people together, with users, customer stakeholders, designers, developers, testers, and documenters. You go through a process with all these people and end up with these arrayed groups of named cards referring to roles in the system. You go through again and end up with groups of cards representing tasks. It seems that these card models are both a focus for discussion, taking you through this process, and a token which enables action, that you both can agree represent the system you're building.
Jeff P: By contrast, UML is not a good boundary object because it is not understandable by both sides. When I'm working with UCD, we go through a weird collaborative process, and we get enough convergence to think we agree on what we're doing.
Michael: Like many relationships.
Jeff P: There's some ambiguity, things described in "suitable detail."
Rebecca: I'd like to know if, I'd like to see Usage-Centered Desine ("lite"), applied to testing.
Brian: "Agile Fusion" was sort of an attempt at this. We had a bunch of XP-ish programmers and context-driven testers work from 9 to 3 each day building a product on June 11-18 of this year. We started with a straight XP approach with test-first ATs, and added more tests with time. From 3-5 pm, we had a "debrief" and Q and A, open space interest groups on different topics.
Chris: That seems like a very developer-centric approach.
Jeff P: Everyone wants to be "first" in the software development process.
Brian: There were various reasons I arranged it that way. I was hoping for the testers to have some of the XP stuff injected into them by seeing it start out that way.
Rebecca: Yes, to be able to say, "I can work with this."
Brian: We had a good workshop at XP/Agile Universe with Ward Cunningham and Martin Fowler, but we wanted to build something.
Jeff M: What was the product?
Brian: Dave Thomas's "rublog", in Ruby. He's integrated a good proportion of our work.
Jeff P: I've had wonderful successes with the UCD methods buliding shared understanding. We had a client where we'd write a document on the system we were going to build for them, and they'd send it back, saying that we didn't understand. We went through the UCD process, a collaborative scoping exercise, what's the product and what's the scope. At the end, we have a prioritized and estimated list of things, with about a 2 1/2 page list of brief descriptions. It was very meaningful to the customer and us, and we were able to proceed with development. But when I looked back at the analysis documents we'd sent them and compared them with our list, the documents seemed to have gotten it pretty well right, even catching a couple of features that hadn't shown up in the UCD session. The analysis documents didn't work as a boundary object because they weren't shared. The exercise also helped me better understand the analysis documents, now that I had a better sense of the customer's context.
Brian: Were the documents ambiguous?
Jeff P: No, overly precise if anything. They demanded too much of the reader.
Rebecca: So the list was a touchstone, a memento of the design session.
Jeff P: Not meaningful to the parties that didn't participate in creating it.
(a "tail-end" discussion on testers and schools of testing)
Jeff M: What are the schools of testers you were referring to? Where do context-driven testers and exploratory testing fit into it?
Brian: Well, I'd say there are four schools. There are the analytical testers, who regard a program as a set of mathematical arcs that they have to cover with their tests to prove it correct. There are "factory" testers. There are the "quality police", who focus on catching errors and quality problems, and affixing blame. Then there are the "context-driven" testers, who see projects as conversations about the right product, that the actual software may evolve from what we learn during testing. Context-driven testers do exploratory testing, and to a lesser extent, the "quality police".
Jeff P: I ask my testers, "prove it works, then prove it doesn't work." Testers can make themselves really busy concentrating on a host of smaller errors, but if the system cannot make it through the "happy case" for a feature or story, then that's the only place they should be focusing.
(session deconvened, re-convened in the bar)
[.FrontPage] [.RecentChanges]
Topic: Analogy Fest: Boundary Objects
Date: 26 June 2003
Convener: Brian Marick
Email address: marick(at)testing(dot)com
| Attendees: | |
| Michael Hamman | m-hamman(at)uiuc(dot)edu |
| Jeffrey Miller | jsmiller(at)acm(dot)org |
| Jeff Patton | jpatton(at)tomax(dot)com |
| Kevin Picott | kpicott(at)aw(dot)sgi(dot)com |
| Chris Sepulveda | cs(at)atdesigntime(dot)com |
| Rebecca Wirfs-Brock | rebecca(at)wirfs-brock(dot)com |
| Cecilia Haskins | Bergen, Norway |
This session started from Brian Marick's "Boundary Objects" paper, part of Analogy Fest, bringing in analogies from other domains and discussing them in terms of relevance to software development.
Definition (I don't have the paper in front of me -- transcriber)
A boundary object is something common to two or more communities of practice which helps them collectively stay aligned as a community of interest for the purpose of collective action.
Discussion Summary
* to be factored up from discussion transcript; attendees please move up any specific important points
* Examples within software development:
- Acceptance tests
- Models derived from the User-Centered Design process
* Examples of boundary objects from the paper:
- A university museum's zoological specimen collection (to curator, a compilation of scientific observations for theory testing; to amateur collectors, a comprehensive preservation of disappearing natural history; to administrators, a mark of prestige).
- A non-profit organization for medicine grants;
- The medicine itself, (to the drug company, a drug for treating sick people; to governments, a tool for improving public health).
* Examples from outside software development:
- The "core values" manifesto of the Agile Alliance (different groups emphasize different values, have different practices).
- The U.S. Constitution, as a statement of values, practices, and rules which is important to many people and helps them work together, but is interpreted in different ways.
Discussion Transcript (delegate to a discussion page?)
Jeff P: A boundary object can be a token which two parties can refer to. An object, which has both individual meaning to the parties, and a common meaning. For example, an XP "User Story". The entities which emerge in Eric Evans's domain specific language (see http://www.domainlanguage.org) can be considered as boundary objects.
Rebecca: Yes. A boundary object has common momenta; it's not a translation from everyone's point-of-view. There can be multiple communities involved. Essential use cases (Larry Constantine, http://www.foruse.com) seem to be a good example of a boundary object. They represent the essential conversation between a user and a system. Each side can take the abstract steps in an essential use case and fill in the blanks or elaborate their meaning. The XP "user story" of 1-2 sentences requires more trust in common understanding than an essential use case. Requirements done "by example" give me the tough cases that I'd like to work with.
Jeff P: Different degrees of precision?
Rebecca: Detail, rather. I don't think you'd refer to precision when you have multiple ways that they could be elaborated.
Brian: They don't have to be true, they're a tool, or a point of provocation.
Michael: Like "content pivots" in cybernetics. Two streams with a common point but different meaning find the common point a provocation to converge or decide to diverge. You need to establish trust to allow agreement, and a user story supports...
Chris: Boundary objects can be a touchstone within a community of practice, as well as between communities. Developers have some adeptness in discussion invented abstraction layers as system boundaries. Why do they find it harder when meeting with another group? The common patterns of interfaces and protocols don't seem to transfer very well.
Brian: Developers can see the relationships, but the customer can't see how it lines up.
Chris: With developer groups, common goals help them understand common boundary objects.
Brian: In the University of California museum collection example from the paper, there were four communities of interest. Each one of them had a different perspective on why the collection was important to them and met their goals.
Rebecca: There's a person I work with who's good at coming up with explanatory metaphors neutral to the implementation but intuitively satisfying. He might describe an operation as "something stamping something". He's the only person in the development group who's good at it; it's not abstraction, distilling a simplified meaning, it's more inventing a common touchpoint. Not from a "canned" form, but an apt, accessible metaphor.
Chris: That simultaneously expressed everyone's goals.
Kevin: A way of making everyone...
(the notes have a sketch of a flag as a boundary object with common importance but varying meaning which people can rally around)
Brian: I've noticed in reading these papers in science studies, like the one from which I quote the museum example, they're incredibly fond of metaphors which convey nothing to me.
Jeff P: Perhaps like developers' metaphors not being transferable.
Rebecca: The downside with this person's explanatory metaphors was that the metaphor was so apt and attractive, you think you've solved the problem, and you can go on for a couple of months that way.
Brian: There's a French sociologist who works on "Actor Network Theory", he's interested in how science works, but he's a complete relativist. He looked at the networks of professional acquaintances that scientists have, and he has a fairly Machiavellian view of how scientits marshal support for their theories by way of their acquaintances and alliances.
Rebecca: A.N. Whitehead discussed that issue as well.
Brian: Joan Fujimura is also interested in these networks, but from perhaps a more optimistic point of view. She has a paper discussing how the virus theory of cancer went from a minority to a dominant theory. She talks about packages, not just boundary objects, but a set of useful practices which passed along with the theory, a set of biological tests. People could use them for their own purposes, but with the tests came an implicit assumption about the viral theory of cancer.
Chris: My wife received a piece of sales advice in business school, that it's an effective way to exert influence and gain advantage whenever you can spin a story that a particular proposition is "win-win".
Brian: The background to this example, in terms of relevance to boundary objects, was that Richard Nixon had declared a war on cancer. The National Science Foundation agreed to undertake the task. Time had gone by, money had been spent, and the NSF needed to justify what had happened to Congress. So NSF had an interest in showing results which could be partly satisfied by advancing the virus theory of cancer.
Michael: There's some other aspect to boundary objects, not necessarily a political aspect, but one that allows alignment (vs. the museum collection, a common token that does not actually align interests).
Rebecca: That's an interesting question. We like to align goals, right? If we could make software that fits like a glove so that the customer doesn't have to change the way they work, have we done the right thing? Software's supposed to promote change.
Chris: Does a boundary object facilitate communication, or is it more that it effects action or provides impetus and momentum?
Rebecca: Or alignment?
Chris: And facilitating communication more often leads to more discussion and explanation rather than action.
Brian: Perhaps boundary objects are more about action than communication?
Chris: Most of the examples in the paper are really about action.
Brian: An example from my wife's domain, she manages a university large animal veterinary department. Now there are two communities within large animal veterinarians, the "individual animal vets" and the "herd health vets". These two groups have very different goals and barely speak to one another. But she has to find ways to make things happen in the department that both communities agree on.
Brian: Conventionally minded testers are good at finding mistakes. Programmers want to see progress. Fault-finding testers would tend to grate on the programmers. It would be nice to find a boundary object to align the interests of the programmers and testers. It would be nice to think that the acceptance tests might be a place to find common ground.
Jeff M: The tester can think, "Ah, I've really kept that programmer in line," and the programmer can think, "Ah, I really know what they're after me to do."
Chris: The tester's the skeptic, looking for problems. The developer's optimistic, looking for progress.
Jeff P: Tests are necessary to acknowledge progress. I get into the requirements thing, and often the customer's requests are mangled by the analyst into technical requirements without having a boundary object that the customer can refer to, such as an acceptance test that the customer helped write.
Rebecca: I have a background as a "software evaluation engineer" from the start of my career. Developers and testers have different tactical goals, but the same strategic goal overall, to ship a quality product. If people did not trust me to write a good test, they would despise me. I know what you're talking about with annoying evaluation people. I had to learn a lot about the developer community when I was a tester. We really had to understand what each other were doing in order to be most effective together.
Brian: "testers" and "developers" have two different communities of practice; "testers" derive some of their identity from being skeptical, developers from being hopeful, believing problems should be solved.
Chris: The fact that developers could become "test-infected" was a surprise. But the focus is tests which prove the code works, the bias is toward going forward vs. looking at how to break it or looking at it from all the different angles. The developers will get around to that later, why overdo that point of view at the start?
Brian: Testers have trouble with the idea of test-first acceptance testing. They want to look at the various configurations before they feel they can compose adequate tests.
Chris: The spectrum of possibilities.
Brian: The iterative approach of starting with an identical configuration and test, then incrementally adding acceptance tests can lead the tester to ask, "how do we know when we'll have the whole picture?"
Rebecca: Michael Jackson's "Problem Frames" help me ask questions during design, if you understand the nature of the syatem. Michael Jackson would like you to frame the problem beforehand. I'd like on an agile project to sketch out frames at first and to reconsider as development progresses. (Example of frames: connection, transformation, ...). I'll use his technique but not figure that I can get it all right beforehand.
Chris: Outside-in, frame and confine the complete problem.
Rebecca: Jackson advises thinking of one thing at a time, each frame in isolation. When you get down to where bugs are, it's often from neglecting a frame, from considering only one.
Chris: Exploratory testing double-checks the first draft of the "comprehensive" test suite, the "back door". By comparison, the developer looks for feedback from tests, with the customer as "sanity check" or "back door".
Michael: Unit tests in test-first development, they help me comprehend what I'm doing. Then when you get to equilibrium, things are stable enough to be skeptical. Sit with a tester when writing more tests.
Brian: That sounds like William Wake's distinction between "generative tests" and "elaborative tests".
Michael: Boundary objects help you stay converged long enough to get things done.
Chris: Boundary objects as an impetus for action. I'm thinking of the earlier session about advocating agile methods as a non-technical person. Is there a useful boundary object for motivation in that case?
Jeff M: This reminds me of political coalition building, where you propose an initiative that has benefits to the various interest groups whose support you need. The university museum collection made me think of that right away.
Brian: In particle physics, the experimentalists vs. the theorists. The theorists need to "catch" an experimentalist to test their theories, and the experimentalists need a testable theory to work on. There's a notion of "trading zones" in which interests are aligned by inventing pidgin trade languages, a simplified, specialized vocabulary.
Rebecca: That's the goal of an essential use case.
Brian: And building a vocabulary of common words.
Chris: So would the core principles of the Agile Alliance be a boundary object for its members? The manifesto is a call to action based on these shared assertions.
Jeff P: This would have been a different conference, perhaps "XP Development", and there would have been different people here that we would have missed seeing. So the manifesto is a thing people can pretend to agree on which brings them together.
Michael: People having different interpretations of the core principles, and different practices.
Rebecca: And different emphasis on the various principles.
Chris: Jeff M's mention of the U.S. Constitution as a boundary object was a good idea. It's important to lots of people, deified almost, but there are strikingly different points of view about what it means or should mean.
Rebecca: Or do people even read it?
(side discussion of Canada by comparison)
Jeff P: And the United States as a boundary object, something that all Canadians can agree that "we're not!".
Rebecca: I'm thinking of the Rational Unified Process as something that the various agile processes generally agree that "we're not!". But after seeing Craig Larman's presentation on "Agile Unified Process", it seems there's really nothing to argue about, RUP is just a framework.
Brian: Yes, before the Agile Manifesto, you could ask "what's agile" and hear "whatever it is, it isn't RUP!".
Jeff P: There's this notion of common agreement, mutual goals...
Brian: People must be not in conflict, it mustn't be a zero-sum game among the participants.
Jeff P: There are lots of disagreements in the Agile community.
Chris: Those words in the manifesto, we can all agree with and move forward without quibbling on minor points.
Rebecca: These seem like successful boundary object examples. But what about... [something about testing?]
Jeff P: I've had testers show up at my desk and detonate. Is success of a boundary object discussion or action?
Jeff M: Let's look at the example of the card models created in User-Centered Design (Constantine). You get this group of people together, with users, customer stakeholders, designers, developers, testers, and documenters. You go through a process with all these people and end up with these arrayed groups of named cards referring to roles in the system. You go through again and end up with groups of cards representing tasks. It seems that these card models are both a focus for discussion, taking you through this process, and a token which enables action, that you both can agree represent the system you're building.
Jeff P: By contrast, UML is not a good boundary object because it is not understandable by both sides. When I'm working with UCD, we go through a weird collaborative process, and we get enough convergence to think we agree on what we're doing.
Michael: Like many relationships.
Jeff P: There's some ambiguity, things described in "suitable detail."
Rebecca: I'd like to know if, I'd like to see Usage-Centered Desine ("lite"), applied to testing.
Brian: "Agile Fusion" was sort of an attempt at this. We had a bunch of XP-ish programmers and context-driven testers work from 9 to 3 each day building a product on June 11-18 of this year. We started with a straight XP approach with test-first ATs, and added more tests with time. From 3-5 pm, we had a "debrief" and Q and A, open space interest groups on different topics.
Chris: That seems like a very developer-centric approach.
Jeff P: Everyone wants to be "first" in the software development process.
Brian: There were various reasons I arranged it that way. I was hoping for the testers to have some of the XP stuff injected into them by seeing it start out that way.
Rebecca: Yes, to be able to say, "I can work with this."
Brian: We had a good workshop at XP/Agile Universe with Ward Cunningham and Martin Fowler, but we wanted to build something.
Jeff M: What was the product?
Brian: Dave Thomas's "rublog", in Ruby. He's integrated a good proportion of our work.
Jeff P: I've had wonderful successes with the UCD methods buliding shared understanding. We had a client where we'd write a document on the system we were going to build for them, and they'd send it back, saying that we didn't understand. We went through the UCD process, a collaborative scoping exercise, what's the product and what's the scope. At the end, we have a prioritized and estimated list of things, with about a 2 1/2 page list of brief descriptions. It was very meaningful to the customer and us, and we were able to proceed with development. But when I looked back at the analysis documents we'd sent them and compared them with our list, the documents seemed to have gotten it pretty well right, even catching a couple of features that hadn't shown up in the UCD session. The analysis documents didn't work as a boundary object because they weren't shared. The exercise also helped me better understand the analysis documents, now that I had a better sense of the customer's context.
Brian: Were the documents ambiguous?
Jeff P: No, overly precise if anything. They demanded too much of the reader.
Rebecca: So the list was a touchstone, a memento of the design session.
Jeff P: Not meaningful to the parties that didn't participate in creating it.
(a "tail-end" discussion on testers and schools of testing)
Jeff M: What are the schools of testers you were referring to? Where do context-driven testers and exploratory testing fit into it?
Brian: Well, I'd say there are four schools. There are the analytical testers, who regard a program as a set of mathematical arcs that they have to cover with their tests to prove it correct. There are "factory" testers. There are the "quality police", who focus on catching errors and quality problems, and affixing blame. Then there are the "context-driven" testers, who see projects as conversations about the right product, that the actual software may evolve from what we learn during testing. Context-driven testers do exploratory testing, and to a lesser extent, the "quality police".
Jeff P: I ask my testers, "prove it works, then prove it doesn't work." Testers can make themselves really busy concentrating on a host of smaller errors, but if the system cannot make it through the "happy case" for a feature or story, then that's the only place they should be focusing.
(session deconvened, re-convened in the bar)
[.FrontPage] [.RecentChanges]