University of Southern California Center for Systems and Software Engineering 1 WikiWinWin: Rapid Collaborative Requirements Negotiation Using Wiki and Shaper Di Wu 1, Da Yang 2, Barry Boehm 1 1 Center for System and Software Engineering, University of Southern California 2 Institute of Software, Chinese Academy of Science

University of Southern California Center for Systems and Software Engineering 22 Outline o Introduction o WikiWinWin experience and results o Conclusions

University of Southern California Center for Systems and Software Engineering The Challenge Achieving WinWin in rapid collaborative requirements negotiation – Multi-stakeholders, multi-discipline – Have little understanding of each other’s principles and practices – Stakeholders’ interests are often in conflict – Rapid changes Leverage existing theories, Wiki technology, Shaper role – Improve on the EasyWinWin solution

University of Southern California Center for Systems and Software Engineering Enabling Technology: Wiki Examples of wiki-based collaboration – Wikipedia: collaboratively written by a group of about 50,000 volunteers – Yahoo: use wiki to manage documentation and project planning – Fraunhofer institute: wiki tool for collaborative requirements management Wiki platform lightens the groupware used in EasyWinWin – Distributable, collaborative platform – Easy editing of web pages, immediately publishable – Preserve revision history Prof. Majchrzak’s research on using Wiki – Shaper role is a critical success factor

University of Southern California Center for Systems and Software Engineering Example of a Shaper* 75-person software engineering group at a multi-billion dollar tech company “I spend up to two hours a day working on the wiki. Much of this time I reorganize other people’s materials, rename pages, create new links on the home page, or restructure the home page. Benefits aren’t to mean personally, but they help the group collaborate more effectively. They can find things easier” *Ann Majchrzak, USC Marshall School of Business, 2006

University of Southern California Center for Systems and Software Engineering Wiki Shapers Add Business Value

University of Southern California Center for Systems and Software Engineering An Example of Shaping Initial ideas from knowledge contributors Shaper organize them into a prospective win condition Stakeholders engage in a further discussion

University of Southern California Center for Systems and Software Engineering WikiWinWin Experience Evaluate annually using USC graduate software engineering course projects, rework per feedbacks – Real-client, e-service projects – 20 teams in fall 2007, 12 teams in fall 2008, 14 teams in fall 2009 Co-located and remote participants in each team – Students: roughly 20% working professionals, located across the country – Clients: knowledgeable of organizational needs, not technical experts, limited availability Applied the “shaper” role – 2 shapers per team (1 off-campus, 1 on-campus) Provided training Used WikiWinWin in same-time negotiation and self-facilitated, off-line negotiation

University of Southern California Center for Systems and Software Engineering WikiWinWin Result (Fall 2007) Project package quality shortfall vs. team use Baseline for improvement: Tool: Simplify GUI, shaper functions Provide better overview page and report layout Training: More context setting and training for clients Better preparation for the shaper role Process: Mandate enough gaps between brainstorming meeting and identifying option meeting Provide guideline for sharing Shaper responsibilities Establish accountability for off- line tasks Project package quality shortfall vs. shaper use Project package quality shortfall vs. team usage days

University of Southern California Center for Systems and Software Engineering WikiWinWin Result (Fall 2008) Project package quality shortfall vs. team useProject package quality shortfall vs. shaper use Project package quality shortfall vs. team usage daysProject package quality shortfall vs. shaper usage days Project package quality shortfall vs. creating artifacts

University of Southern California Center for Systems and Software Engineering Summary of Critiques Fall 2007Positive counts Negative counts Usefulness83 Easy to use37 UI32 Easy to learning18 Efficiency12 Robustness4 Total83103 Comments on usefulness Gather needs Better understanding of needs Communicate needs Prioritize on needs Eliminate paper work Individual use at convenience Involve all stakeholders to collaborate Keep history for tracking or future reference Capture important terms Generate broader and deeper requirements Fall 2008Positive counts Negative counts Usefulness57 Easy to use20 UI25 Easy to learning4 Efficiency5 Robustness0 Total5754

University of Southern California Center for Systems and Software Engineering Conclusions Success factors of use – Use it early – Use it more – Use it often – Evolving artifacts – Shaper use Lessons learned for developing wiki-based groupware – Provide robust support for gathering, understanding, and communicating needs – Design flexible tool to accommodate individual use – Facilitate knowledge sharing by allowing easy content update and preserving history – Reduce manual effort to improve efficiency High consensus on usefulness, further improve on ease of use Investigate characteristics of good shaping

University of Southern California Center for Systems and Software Engineering Backup Charts 7/16/201513Ph.D. Qualifying Exam, Di Wu

University of Southern California Center for Systems and Software Engineering WinWin Negotiation Model and Equilibrium Theory Win Condition : captures individual stakeholders’ desired objectives. Issue : captures conflicts between win conditions and their associated risks and uncertainties. Option : candidate solutions to resolve an issue. Agreement : captures shared commitment of stakeholders with regard to accepted win conditions or adopted options. Win-Win Equilibrium (Lee 1996): All win conditions covered by agreements No outstanding issues 7/16/201514Ph.D. Qualifying Exam, Di Wu

University of Southern California Center for Systems and Software Engineering Threats to Validity Non-uniformity of projects – Projects differ from one another in terms of application, technical characteristics, client needs, team members’ communication skills Non-equality of team experiences – More experienced teams may have the skills to achieve higher grades, also may be more conscious of adopting good practices Changes in the course – Changes in course instructions, such as development process and guidelines also add confounding effect Generalization of results – To some extent, our projects are representative of small dev teams in industry in terms of problems to be solved, diversity of clients, team skills, etc. – Somewhat representative of distributed dev teams given that our projects involve co- located and remote team members across the country