The Generative Dance of Knowledge Integration
•
1 like•299 views
**Click "Notes" below for a transcript of the talk as it was given** The difficulties of developing and integrating shared mental models across the disparate disciplines of supposedly interdisciplinary teams is a key barrier to the realization of novel research directions and innovative outcomes. This presentation appeared at Science of Team Science 2013, and was itself the product of a trans-disciplinary collaboration. It considers this problem within two analogous contexts: that of interdisciplinary research (IDR) teams in scientific disciplines and of interdisciplinary product development (IPD) teams in the consumer-driven software market. We compare IDR teams and IDP teams using the widely applied Scrum agile management framework in terms of composition and challenges to interdisciplinary work, structure and problem domain and knowledge integration processes as they seek direction and delivery of results.
Recommended
More Related Content
Viewers also liked
Viewers also liked (16)
Similar to The Generative Dance of Knowledge Integration
Similar to The Generative Dance of Knowledge Integration (20)
More from Derek W. Wade
More from Derek W. Wade (12)
Recently uploaded
Recently uploaded (20)
The Generative Dance of Knowledge Integration
- 1. The Generative Dance: Knowledge Integration in Interdisciplinary Research and Product Development Teams Derek W. Wade @derekwwade dwade@kumido.com www.kumido.com (C) 2009-2011 Deana Pennington PhD @penningd ddpennington@utep.edu #GenerativeDance
- 3. www.kumido.com (C) 2009-2011 A Model of Knowledge Synthesis Across Domains at SciTS12 IDR Interdisciplinary Research
- 4. www.kumido.com (C) 2009-2011 • Differentiated roles, specialized knowledge • Task interdependence • Dynamic workflows adapting to context • Interplay of tacit and explicit knowledge IPD (‘Derek’) & IDR (‘Deana’) (Cook and Brown 1999; Klein et al.2010; Kostoff 2002)
- 5. www.kumido.com (C) 2009-2011 ‘Innovation’ = ‘research approach’ (IDR) or ‘useful, unforeseen solution’ (IPD) Interdisciplinary innovation
- 6. www.kumido.com (C) 2009-2011 NSF Study (Rhoten 2004) “...loosely connected individuals searching for intersections, as opposed to cohesive groups tackling well-defined problems.” Seuss-Army Knife Synthesis is hard
- 7. www.kumido.com (C) 2009-2011 Difficulty of innovation/synthesis ... Difficulty of generating & integrating team shared mental model Forming Storming Norming Performing (Tuckman 1965) Our focus
- 8. www.kumido.com (C) 2009-2011 Can these help each other?
- 9. www.kumido.com (C) 2009-2011 “Cross-disciplinary capital” • = number, quality of conceptual connections • Performance = 𝒇 (capital) • Agile frameworks: steps/interventions Pennington model: when/why to use IDR theory ＋ IPD practice ➝＋
- 10. www.kumido.com (C) 2009-2011 Initial connection capital Discipline1 Discipline2 A B
- 11. www.kumido.com (C) 2009-2011 Initial capital applied
- 12. www.kumido.com (C) 2009-2011 Learning: generating capital Discipline1 Discipline2 D C
- 13. www.kumido.com (C) 2009-2011 Learning applied Regular synch meetings: Inspect & adjust Work Work Work Work D C
- 14. www.kumido.com (C) 2009-2011 When connections > threshold, paths forward become apparent Nexus points
- 15. www.kumido.com (C) 2009-2011 Nexus points applied Minimum Viable Product
- 16. www.kumido.com (C) 2009-2011 Team artifacts
- 17. www.kumido.com (C) 2009-2011 “Two things are known about requirements. 1. They will change. 2. They will be misunderstood.” ~ Michael Jackson, keynote to 1994 Int’l Conference on Requirements Engineering Team artifacts applied (Shekaran et. al. 1994)
- 18. www.kumido.com (C) 2009-2011 •Shows promise: “They are using the framework correctly, but we need to up their team capital.” •Needs validation Conclusions
- 19. www.kumido.com (C) 2009-2011 • Continue to refine synthesis of theoretical model ＋ Agile frameworks • Seeking ways to instrument teams • “Citizen science:” get teams to self-instrument Next
- 20. www.kumido.com (C) 2009-2011 Images Apollo/Saturn IBM.com Puzzle Pieces parentnetworkny.org Seuss-Army Knife IWasteSoMuchTime.com Works Cook, S. D. N., & Brown, J. S. (1999). Bridging epistemologies: The generative dance between organizational knowledge and organizational knowing. Organization Science, 10(4), 381–400 Hohmann, L. (2007). Innovation games: Creating breakthrough products through collaborative play. Upper Saddle River, NJ: Addison-Wesley. Retrieved from Amazon. Klein, J. T. (2010). A taxonomy of interdisciplinarity. In R. Frodeman, J. T. Klein, & C. Mitcham (Eds.), The Oxford Handbook of Interdisciplinarity (pp. 15–30). Oxford University Press. Kostoff, R. N. (2002). Overcoming specialization. Bioscience, 52(10), 937–941. Rhoten, D. (2004). Interdisciplinary research: Trend or transition. Items and Issues, 5(1-2), 6-11.) Schwaber, K. (2004). Agile project management with Scrum. Microsoft Press. Shekaran, C., Garlan, D., Jackson, M., Mead, N. R., Potts, C., & Reubenstein, H. B. (1994, April). The role of software architecture in requirements engineering. In Requirements Engineering, 1994., Proceedings of the First International Conference on (pp. 239-245). IEEE Stacey, R. D. (2007). Strategic management and organisational dynamics: The challenge of complexity to ways of thinking about organisations. Prentice Hall. Tuckman, B. (1965). Developmental sequence in small groups. Psychological Bulletin, 63, 384–399. All other images Wikimedia Commons, author image, or unknown
- 21. ThankYou! The Generative Dance: Knowledge Integration in Interdisciplinary Research and Product Development Teams Derek W.Wade @derekwwade dwade@kumido.com gplus.to/derekwwade www.derekwwade.net www.kumido.com (C) 2009-2011 Deana Pennington PhD @penningd ddpennington@utep.edu How is the model/framework relevant for you? #GenerativeDance
Editor's Notes
- This talk was presented at the 4th Science of Team Science conference, Northwestern University, IL, USA in “pecha kucha” format: 20 slides, 30 seconds per slide. We presented a snapshot of our work on a model for interdisciplinary teams. The work is still in progress.
- I’m Derek, and I’m not in the academic or science fields, so thanks very much for having me here. I work in Interdisciplinary Product Development, and my title is “team coach.” My background is in aviation, complex software systems, and organizational change. The relevance of this to the Science of Team Science is that given the complexities of market needs crossed with vast interoperating technical systems, we end up with a complex, even chaotic problem domain. My focus interest in this field is in TEAM-work vs. TASK-work: the idea that when facing this kind of complexity, the biggest factor for performance comes from addressing the human and interpersonal side of the equation.
- Dr. Deana Pennington works at the University of Texas El Paso’s Cyber-ShARE team science initiative. Her background and interests have come from data science, to systems change, to knowledge exchange. She presented her “Model of Knowledge Synthesis Across Domains” at SciTS last year, and I was fascinated: much of my work as a team coach, while successful, is based on rule-of-thumb and tribal knowledge -- we know what interventions to craft to help teams, but Deana’s model was something that explained much of the WHY behind it. So we got to talking and compared our respective domains.
- We found that my world of Interdisciplinary Product Development and Deana’s world of Interdisciplinary Research share several significant characteristics, some of which are listed here. I won’t read them; I’ll let you do that, but the thing that stood out in both our domains is the importance of the interplay between tacit and explicit knowledge; that is, between the facts of the development or research project and the team’s awareness of itself.
- I enjoy being a promiscuous collaborator, so I asked Deana if we could try to synthesize our work. That’s what we’re sharing today, a glimpse into our work-in-progress on a conceptual paper on “how innovation occurs.” By “innovation” we don’t just mean one person having a bright idea, but either an interdisciplinary research approach (in the IDR world) or, in the product development world, the creation of a useful solution that emerges rather than being specified at the same time the problem is identified.
- One of the biggest challenges with this kind of innovation is that attempting synthesis usually results in an additive composition. In Rhoten’s survey of a number of National Science Foundation projects, in most instances the research was along traditional modes and then patched together at the end, rather than generating new concepts. In the product development world we call this “Conway’s Law,” which says that the structure of a system will resemble the structure of the organization that built it. At best that results in something like the Saturn/Apollo stack of the 1960s where the rocket’s stages were delineated along contractor lines. At worst that results in the “Seuss-Army Knife” of multiple, barely-related concepts jammed together for no specific purpose.
- There are other challenges to innovation for interdisciplinary teams: different values among the team members, segregation and distance, and even penalties for collaborating built into reward/compensation systems. But Deana and I wanted to avoid the additive model trap ourselves, and so chose to synthesize around the team as a complex adaptive system, and how the team generates and integrates a shared mental model. This is a model for explaining team performance, rather than simply rating it on a linear scale such as the “Four Ormings.”
- We hypothesized that our focus areas would inform each other. Deana had a theoretical model for interdisciplinary research, a flow/accumulator model with feedback. I had some practical frameworks for interdisciplinary product development, “playbooks” for teams, if you will. There are several, Ken Schawaber’s Scrum framework is shown here. We wanted to avoid a simple union of our focus areas. Not two puzzle pieces added together. The two domains — and focus areas — don’t map that easily. Instead, we wanted to see how the theoretical IDR model informed the IDP frameworks for practice.
- What we found was that we could interconnect concepts around team shared mental models from both disciplines. We could explore how the model and frameworks deal with how teams generate, and integrate, this “cross-disciplinary capital.” A team’s innovation performance, in these terms, can be viewed as the accumulation of — or loss of — collaboration capital. This was less like sticking two puzzle pieces together, and more like crossing chocolate and peanut butter to get Reeses candies: the product development frameworks informed “what to do,” and the interdisciplinary research theory informed “how and when to do” to get innovation. We’ll look at four instances of how Agile team IDP practices can be examined as components of the IDR model.
- The first has to do with “initial connection capital,” or the conceptual connections between different disciplines, before they have had much time to work together. Deana’s research model suggests that finding new connections is something that happens via working together, more so than through passive information sharing via for example, “lunch and learns.” Where concepts from discipline 1 (say, database architecture or biochemistry) don’t have an analog in discipline 2 (say, user-interface design or discrete math), people from these two disciplines have to find the concepts they can use to bridge understanding.
- Experience in Agile product development bears this out. We have found that working together — even when there seems to be no shared understanding of how to achieve a goal — is far more effective than “team building exercises” or slide presentations. Here’s an example where a brand-new team worked together to rank opportunities and threats to their project by placing post-it note “good apples” and “rotten apples” on a “tree” representing their product. While the final artifact was useful in terms of prioritizing lines of research, the team benefit was the initial cross-connections and understandings that resulted how they had to interact to perform the exercise. This suggests that giving new research teams could benefit from an opportunity to work on a shared domain that makes demands on all of their skills at the start of a project — even if it’s a ‘toy’ domain not directly germane to their research. Apply minimal structure to the team, have them produce, and have them inspect their product.
- The second instance of how the interdisciplinary research model and interdisciplinary product development practices inform each other is in learning, specifically “learning” considered as the GENERATION of cross-disciplinary capital. The models suggests that team members close their gaps between their disciplines by finding, and creating, NEW, shared cross-disciplinary concepts. Almost a new shared language for that team. Common Agile product development practices include a “daily standup” meeting of the team to inspect work as a group, and a regular but less-frequent “retrospective” meeting where the team inspects their WAYS OF WORKING (for example, the daily standup itself) as a group.
- Here’s an example of a Daily Standup. One team member is walking his team through his tasks, on a shared task board. He’s explaining what he did yesterday, what he plans to do today, and anything that’s frustrating his progress. Then the next team member does the same, and so on. The whole meeting is short, under 15 minutes. What we often see as a failure mode of the meeting is when it’s held as a status meeting, usually for someone else outside the team to get a progress report. But the model suggests WHY this might be the wrong approach: because the Daily Standup at its best is a way to share and explore cross-disciplinary concepts, within the meaningful shared context of the project. Each day, the team generates new cross-disciplinary capital.
- The third instance of applying the IDR model to IDP practices is the concept of nexus points. The team starts with some initial cross-disciplinary capital — conceptual connections between disciplines. As they work together, learning increases this capital in the ways we’ve seen. In the model, at some point the amount of capital “tips,” and new research lines forward become apparent to the team. In Agile practice, the team realizes their “minimum viable” product, or service.
- Here’s an example. Out of all the paths forward that the team could pursue, through their collective generation of cross-functional capital they’ve determined what’s both most feasible and most valuable to pursue FIRST, even if what’s built at that point is not commercially valuable. What’s more, they’ve recognized that actually building this Minimum Viable Product will yield further insights about how to proceed. For interdisciplinary research teams, this may suggest that there is value in attempting to create something early, seeking that nexus point… even if it doesn’t appear to be an end-state of the research.
- Deana’s model is more complex than we’ve shared here today, this is really about a quarter of it. But our final instance of how we can apply it to interdisciplinary product teams has to do with team artifacts. In the IDR model, artifacts are a form of team shared mental models. In IDP, artifacts are anything built, measured, reviewed, or inspected — ostensibly for project status, but the model suggests that it’s actually for team learning and concretization of the team shared mental model at the time. We see this manifest as system design documents, team workflow policies, wiki pages, running code, code comments, and more.
- The application of the interdisciplinary research model to interdisciplinary product development practices suggests two bits of guidance: first, that research teams might benefit from examining the artifacts of mini-experiments that cross, that make use of the skills from, the entire team. And second, that “slower may be faster;” while such mini-experiments might be slower in terms of the research goal, they may be faster in terms of solidifying the Team Shared Mental Model. One Agile practice is that of “system metaphor:” the team asks itself “if the system we are coding was some kind of physical object, what would it be?” The ensuing whiteboard sketches, made collaboratively by all members of the team, often reveal surprising assumptions and opportunities forward. The IDR model also suggest good IDP documentation practices: before spending time documenting (beyond any regulatory requirements, of course) ask, “are these artifacts being used to foster inter-concept connections?” If not, creating the artifacts may be waste, as the software requirements quote here suggests.
- With these four examples, we realized that indeed, we were able to synthesize our perspectives, and not merely add two disciplines together in an over-simplified way. What’s interesting is that in pursuing this line of inquiry, together we actually used the IDP practices we’ve shown you here today. And while we started with a small amount of initial connection capital, through this effort we’ve created more shared capital and — as you see — this artifact of our findings. The paper is still a work in process, and while it seems to hang together conceptually, we need data.
- Deana and I continue to apply the IDR model to the IDP frameworks, and vice-versa, but we are looking for ways to instrument teams for that empirical data. A citizen science approach would be great. For Agile teams, we’d like to find ways and incentives to have them self-collect the data. For science teams, I invite you all to consider the previous 4 examples of model-and-practices in the context of YOUR teams. Could they be applicable? Are there any volunteers here who would want to try?
- Here are our sources, and…
- …thank you very much for your attention. We’d love to hear from you.