University of Southern California
Center for Systems and Software Engineering
WikiWinWin: Rapid Collaborative
Requirements Negotiation Using
Wiki and Shaper
Di Wu1, Da Yang2, Barry Boehm1
1Center for System and Software Engineering,
University of Southern California
2Institute of Software, Chinese Academy of Science
6/27/2016
@USC-CSSE
1
University of Southern California
Center for Systems and Software Engineering
Outline
o
Introduction
o
WikiWinWin experience and results
o
Conclusions
6/27/2016
@USC-CSSE
2
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
–
6/27/2016
Improve on the EasyWinWin solution
@USC-CSSE
3
University of Southern California
Center for Systems and Software Engineering
Enabling Technology: Wiki
•
Examples of wiki-based collaboration
–
–
–
•
Wiki platform lightens the groupware used in EasyWinWin
–
–
–
•
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
Distributable, collaborative platform
Easy editing of web pages, immediately publishable
Preserve revision history
Prof. Majchrzak’s research on using Wiki
–
6/27/2016
Shaper role is a critical success factor
@USC-CSSE
4
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
6/27/2016
@USC-CSSE
5
University of Southern California
Center for Systems and Software Engineering
Wiki Shapers Add Business Value
6/27/2016
@USC-CSSE
6
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
6/27/2016
@USC-CSSE
7
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
•
Applied the “shaper” role
•
Provided training
•
Used WikiWinWin in same-time negotiation and self-facilitated, off-line negotiation
–
–
–
Students: roughly 20% working professionals, located across the country
Clients: knowledgeable of organizational needs, not technical experts, limited availability
2 shapers per team (1 off-campus, 1 on-campus)
6/27/2016
@USC-CSSE
8
University of Southern California
Center for Systems and Software Engineering
WikiWinWin Result (Fall 2007)
1.80
1.60
1.40
1.20
1.00
0.80
0.60
0.40
0.20
0.00
Project package quality shortfall vs. shaper use
Log(Pk.Loss)
Log(Pk.Loss)
Project package quality shortfall vs. team use
p-value=0.004
R2 = 0.3672
0
100
200
300
400
500
Baseline for improvement:
Tool:
• Simplify GUI, shaper functions
1.80
1.60
1.40
1.20
1.00
0.80
0.60
0.40
0.20
0.00
0
50
100
150
Log(Pk.Loss)
250
300
Training:
• More context setting and
training for clients
• Better preparation for the
shaper role
Project package quality shortfall vs. team usage days
1.80
1.60
1.40
1.20
1.00
0.80
0.60
0.40
0.20
0.00
200
Fall 07 shaper use
Fall 07 total use by team
• Provide better overview page
and report layout
p-value = 0.007
R² = 0.335
Process:
• Mandate enough gaps
between brainstorming meeting
and identifying option meeting
p-valu e = 0.1
R² = 0.1421
• Provide guideline for sharing
Shaper responsibilities
0
5
10
15
• Establish accountability for offline tasks
Fall 07 usage days by team
6/27/2016
@USC-CSSE
9
University of Southern California
Center for Systems and Software Engineering
WikiWinWin Result (Fall 2008)
Project package quality shortfall vs. shaper use
1.60
1.60
1.40
1.40
1.20
1.20
1.00
Log(Pk.Loss)
Log(Pk.Loss)
Project package quality shortfall vs. team use
p-value = 0.06
R² = 0.359
0.80
0.60
0.40
0.20
0.00
1.00
0.80
0.60
p-value = 0.08
R² = 0.3266
0.40
0.20
0.00
0
100
200
300
400
500
600
0
100
1.60
1.60
1.40
1.40
1.20
1.20
1.00
p-value = 0.06
R² = 0.7254
0.60
300
400
Project package quality shortfall vs. shaper usage days
Log(Pk.Loss)
Log(Pk.Loss)
Project package quality shortfall vs. team usage days
0.80
200
Fall 08 shaper use
Fall 08 total use by team
0.40
0.20
1.00
0.80
0.60
p-value = 0.04
R² = 0.4827
0.40
0.20
0.00
0.00
0
5
10
15
0
2
4
6
8
Fall 08 shaper usage days
Fall 08 usage days by team
Log(Pk.Loss)
Project package quality shortfall vs. creating artifacts
1.60
1.40
1.20
1.00
0.80
0.60
0.40
0.20
0.00
p-value = 0.009
R² = 0.5955
0
2
4
6
Fall 08 days creating artifacts
8
10
@USC-CSSE
10
University of Southern California
Center for Systems and Software Engineering
Summary of Critiques
Fall 2007
Positive
counts
Usefulness
Comments on usefulness
•
Gather needs
Negative
counts
83
Easy to use
37
•
Better understanding of needs
UI
32
•
Communicate needs
Easy to learning
18
Efficiency
12
•
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
Robustness
4
Total
Fall 2008
Usefulness
83
Positive
counts
103
Negative
counts
57
Easy to use
20
UI
25
Easy to learning
4
Efficiency
5
Robustness
0
Total
6/27/2016
57
54
@USC-CSSE
11
University of Southern California
Center for Systems and Software Engineering
Conclusions
•
Success factors of use
•
Lessons learned for developing wiki-based groupware
•
High consensus on usefulness, further improve on ease of use
•
Investigate characteristics of good shaping
–
–
–
–
–
–
–
–
–
Use it early
Use it more
Use it often
Evolving artifacts
Shaper use
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
6/27/2016
@USC-CSSE
12
University of Southern California
Center for Systems and Software Engineering
Backup Charts
6/27/2016
Ph.D. Qualifying Exam, Di Wu
13
University of Southern California
Center for Systems and Software Engineering
WinWin Negotiation Model and Equilibrium Theory
Win
WinCondition
Condition
Issue
Issue
involves
covers
Agreement
Agreement
addresses
Win-Win Equilibrium
(Lee 1996):
• All win conditions
covered by agreements
• No outstanding issues
Option
Option
adopts
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.
6/27/2016
Ph.D. Qualifying Exam, Di Wu
14
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 colocated and remote team members across the country
6/27/2016
@USC-CSSE
15