CSCI 577a Software Engineering I Supannika Koolmanojwong Mobasser Client Interaction CSCI 577a Software Engineering I Supannika Koolmanojwong Mobasser

Seating Plan (c) USC CSSE

Purpose Mutual Learning Shared responsibility in mutual learning How to be a good team member and team lead Define what “clients” and “developers” are. (c) USC CSSE

Mutual learning process Do you have initial thought on how the final product would look like ? (c) USC CSSE

Avoid Pure Knowledge Transfer OnCampus (IT/CS) Clients (Business) Avoid Pure Knowledge Transfer DEN (IIV&V/ IT/CS) Don’t do knowledge transfer (c) USC CSSE

Prefer Collaborative Learning Clients (Business) OnCampus (IT/CS) DEN (IIV&V/ IT/CS) Prefer collaborative learning (c) USC CSSE

Practices for Encouraging Collaborative Learning I. Creating Shared Responsibility II. Elaboration III. Optimize creative friction to achieve learning Emphasize “between client and developers.” Three critical factors: coord norms, effective meeting management, and reconciling and managing differences (c) USC CSSE

Shared Responsibility in mutual learning A psychological attitude: We’re all on the same team. We’re in this together. In treatment, go fast on these slides… (c) USC CSSE

5 Core Values of Mutual Learning Teams Transparency Share thoughts, feeling, and strategies Be on the same page Curiosity Do not feel threatened by new information or ideas Engage others and allow them to question your ideas Take an interest in what others feel, think, and say Informed Choice Shared information, situation awareness Accountability Held accountable for short and long term consequences of decisions Compassion Aware and understand stakeholders’ needs and pains https://www.td.org/insights/5-core-values-of-mutual-learning-teams (c) USC CSSE

Practices for Encouraging Shared Responsibility: When Managing Stakeholder Relationships Help to make ALL stakeholders part of development team: Put on email distribution list Include in teleconferences Frequent interactions, even if brief Identify tasks that developer and client can work on together Use “we” not “I” during discussions Focus more on “system usage” than “system development” Shared repository Keep off-campus team members in the loop (c) USC CSSE

Practices for Encouraging Shared Responsibility when Project Starts 1) Identify a learning facilitator 2) Identify learning objectives for each stakeholder: - Client organization’s work process? - SE development process? - Technology developments? - Use of IS/IT/SE in business? 3) Identify & Assign development tasks related to each learning objective 4) End each meeting with assessment of learning (c) USC CSSE

What kind of learning? Sharing idea, illustrate, show me examples Clients – don’t just give some info – don’t just throw over the wall Difference between A client who learned A client who is satisfied (c) USC CSSE

Practice 1 10 minutes to discuss about Stakeholders Discuss who are the stakeholders? Who are the potential users? Characteristics (age, occupation, lifestyle) (c) USC CSSE

Practices for Encouraging Collaborative Learning I. Creating Shared Responsibility II. Elaboration III. Optimize creative friction to achieve learning Emphasize “between client and developers.” Three critical factors: coord norms, effective meeting management, and reconciling and managing differences (c) USC CSSE

Elaboration Practices Learning is not telling; self-explainers learn more than listeners Thus, allow time for everyone to “self-explain” How they might use it (c) USC CSSE

Elaboration practices Make abstract discussions concrete Use examples related to client’s work Diagram ideas Build on the client’s methods for describing work, not your own techniques Translate terms (c) USC CSSE

Active Listening Ask about unstated reactions to idea Switch roles Avoid talking too much Restate what you heard Build on the client’s examples & ideas (c) USC CSSE

Practice 2 10 minutes to discuss Client’s expectations What are the current business workflow and the potential improvement? What are the pain points / problems? How can the development team help? Development ? What are the capabilities? What does the end product look like? (c) USC CSSE

Purpose of elaboration Create a common body of knowledge shared by stakeholders about: A vision of the IT-enabled to-be work process Business & technical rationale for vision compared to alternatives Execution Plan Goals, preferences, and fallback options for each stakeholder The most efficient ways for each stakeholders to learn (c) USC CSSE

The Elaboration Process Focus on Actual Work Processes or business flow Not looking for hypothetical ideal, but actual tasks (Don’t say: “users “USUALLY/would” do X”) Let’s pick a user, do you have a name for this user? What Joe Smith does in this case? Immediately co-create prototype of how work done now or in future. Observe how client WALKS THROUGH using prototype to make DECISIONS Note client’s decisions, work around, process Give client opportunity to explain actions (c) USC CSSE

Elaboration Practices Customize learning techniques Try different techniques Keep creative ideas flowing Hand-drawn prototype (c) USC CSSE

Practices for Encouraging Collaborative Learning I. Creating Shared Responsibility II. Elaboration III. Optimize creative friction to achieve learning Emphasize “between client and developers.” Three critical factors: coord norms, effective meeting management, and reconciling and managing differences (c) USC CSSE

Practice 3 10 minutes to discuss Values and Benefits What will the client or stakeholders receive from this project? Quantitative / tangible Qualitative / intangible (c) USC CSSE

III. Learning through Creative Friction Don’t be afraid to disagree. Talk through, rather than avoid differences of opinions (c) USC CSSE

Problems with Many Teams Participants’ creativity not engaged Look for solution that creates quick consensus Unwilling to confront others with different ideas Politeness takes precedence INSTEAD: Sources: Facts (from miscommunication or from your backgrounds – users are not typically very technical and developers are not very well versed in business) – cure with deeper probing, clarification. Objectives (explicit and hidden) – sometimes true objectives are hidden, e.g. get an A for the course. Commitment (non-compliance) – some parties are just more committed than others. Because of differences in power (acquiesence, non-assertiveness, passive acceptance), differences hard to be surfaced. You can’t tell a boss you disagree too often: ain’t good for your health. But you have a difference. Culture – always blamed for breakdowns. Stereotypes like “Asians are shy” etc. Beliefs, which are often irreconcilable. Differences of opinion WILL occur. At least know there is a difference, and start from that point. Work around the difference. An example difference is: clients might be more concerned with getting a simple prototype that can easily be implemented into a final system while developers might be interested in creating a technically elegant solution. Elicit from the class on how differences might be manifest. Then…the presentation forks from the placebo in the “recognize they exist” point. Recognizing that differences of opinions exist; understanding why the differences relate back to goals (is it the goals were not as well-understood). This is harder than you might think. You'll need Cognitive Elaboration tools to explore this. Differences of opinion WILL occur. An example difference is: clients might be more concerned with getting a simple prototype that can easily be implemented into a final system while developers might be interested in creating a technically elegant solution. If you are lucky, differences will emerge as disagreements, If you are not so lucky, they may appear in the guise of miscommunication, conflict over some other issue, failure to comply with agreements, silent treatment, sarcasm, acquiescence. Once differences are identified, we need to understand them (using the techniques already identified in the previous section) Some differences can be managed just with better communication techniques. Other differences are more fundamental. If the communication techniques already identified don't eliminate client/developer differences, then it is necessary to negotiate a mutually acceptable solution. Let's give an example of a possible area of disagreement: Every time Dvlprs talk about the interface between the database and the prototype application being designed, client shows a lack of interest (but doesn't say anything) and then asks them about alternative user interfaces. Dvlprs feel the UI is simple and irrelevant to the key problem, which they believe to be the DB design. So, this shows a disagreement over where to spend limited time: Team feels need to resolve how to make the DB interface work; Client wants to see more alternatives for user interface. So what do you do? First, you acknowledge that there is a disagreement: "every time we talk about DB design, you show a lack of interest; are you more interested in the UI design?" If based on this public acknowledgement, client confirms that there is a disagreement, move to next step (which is to figure out how to resolve it)   Don’t assume that an initial no-diff between client-dvlpr will hold. Search for underlying or less apparent diffs. Innovation Creative Friction (c) USC CSSE

Example: Difference in Practices INDIVIDUAL COLLABORATIVE Use prototypes for single solution Use prototypes to explore different concepts Enforce single representation of knowledge Represent knowledge in different ways Explain own knowledge Have others explain your knowledge Talk Draw, listen, ask questions Stay in role Reverse roles (c) USC CSSE

Checklist during meetings Did you? Use prototypes to explore concepts? Let clients develop prototypes? Create “test-drivable” prototypes? Make sure client asked as many questions as you did? Stimulate creativity through questioning? Restate dialogue to improve understanding? Use examples from more than one work context? Avoid using SE-language? (c) USC CSSE

Checklist during meetings (Cont) Did you: Use visual examples to explain concepts? Reverse roles? Try more than one way to represent how work is done? Elaborate on client’s idea? Ground ideas in client’s physical world with a role play by sharing stories of how work is done? Ask about client’s unstated reactions to an idea? Show any software that client might want to emulate? (c) USC CSSE

Tips for collaboration Encourage early involvement Connect the Dots & Explain Product Benefits Ensure Inclusion in Priority Discussions Collaborate on Release Planning Solicit Feedback During Reviews Use Shared Repository Institute Team Ambassadors Set Regular Meetings https://agilethought.com/blog/articles/agile-stakeholder-engagement/ (c) USC CSSE

10 qualities of an excellent team player Show genuine commitment Be flexible  Don’t stay in the shadows Be reliable and responsible Actively listen Keep your team informed Always be ready to help Support and respect others Be a problem-solver Recognize when you are wrong  (c) USC CSSE https://www.collegerecruiter.com/blog/2015/07/14/10-qualities-of-an-excellent-team-player-at-any-workplace/

Tips for a team lead Make time to lead Get to know your team Communicate, communicate, communicate Lead by example Reward the good and learn from the bad Delegate Be decisive, don’t procrastinate Enjoy it https://www.liquidplanner.com/blog/8-tips-new-team-leaders/ (c) USC CSSE

Summary Every client-developer encounter is an opportunity for learning Every client and developer learns differently Controlling the learning process is better than leaving it uncontrolled Control it by: Building and maintaining a sense of shared responsibility for outcomes Managing conflict for learning Using elaboration techniques by “surfacing” assumed (implicit but often misunderstood) norms, agendas (hidden or otherwise), and differences (ranging from pure misconceptions/misinformation to true irreconcilable differences), we set a positive tone for problem-solving and moving forward. In addition to surfacing, clients and developers must share some responsibility and make an effort to learn from each other. Such sharing and mutual learning helps generate creative alternatives, which in turn leads to successful outcomes. (c) USC CSSE

Back up slide (c) USC CSSE

Beneficiaries (For Whom) Program Model Assumptions: Under what assumptions is this model true? Stakeholders (Who) Initiatives (What) Value Propositions (Why) Beneficiaries (For Whom) Who/what resources are required for ‘executing’ the initiatives Do you need to ‘partner’ with another department or organization? Do you need to hire anyone? What are the key activities that must be done to for delivering/ realizing the value propositions/ benefits? Why undertake this project/ program? What are the value propositions you seek to satisfy/serve? What are the goals? Who derives value from the project/program? (Usually the customers or end users; can also be project sponsors) Cost Benefits What are the ‘costs’ involved for successfully implementing the program? What are the measurable (tangible/intangible) benefits? The cost and benefits (or revenue) sections complete the program model. Their use/impact will be discussed in detail in the lecture on feasibility analysis. (c) USC CSSE

Beneficiaries (For Whom) Assumptions Growing needs of volunteers Continuously growing volunteer pool Increasing activities requiring more volunteers Stakeholders (Who) Initiatives (What) Value Propositions (Why) Beneficiaries (For Whom) Developers Maintainer IIV & V Volunteer Volunteer Coordinator Supervisor Develop new volunteer management system Create web application outreach Develop improved volunteer management process outreach Provide training for new job management process Deploy job management process Setup work stations for volunteer use Improved Productivity Faster volunteer management and less person-to-person time Improved volunteer management process Volunteers Volunteer coordinator Cost Benefits Development Costs, Maintenance Costs, Maintainer (admin hire), Web Server (hardware), Web Hosting, Oracle License etc. Decreased: Application Data Entry Time sheet data entry Job request time Job assignment time Increased volunteer applications Complete program model for an example volunteer management system (c) USC CSSE

Horrible engineering managers Obvious Not so obvious Not technical enough Coding full time Arrogant Overprotective of team Stubborn Too nice Indecisive Jump to conclusion Poor communicator Talk too much Ref: Building great software engineering teams, Brian Link (c) USC CSSE

Essential attributes of an Engineering manager Build Trust Earn respect Ask good questions about challenges and technical details Contribute to code and insightful ideas Express an opinion Know when to delegate Be transparent Protect team from unnecessary interruptions Involve team in decisions whenever possible Ref: Building great software engineering teams, Brian Link (c) USC CSSE

To be a good team member Must haves: Integrity and IQ Should haves: Energy, Energize, Edge, Execution, Passion Game changer: Generosity Gene (passion for people, rewarding and positive) Ref: - Jack Welch, GE - Building great software engineering teams, Brian Link (c) USC CSSE

To help the team Culture of sharing vs heroism Frequent updates on each other Speak up when something is not working Volunteer to help people in need Understand why you’re building stuff Contribute ideas that solves business problems Identify risks Keep track of technical debt Be brave about trying new things Be bold about trying new technology, but ask first Ref: Building great software engineering teams, Brian Link (c) USC CSSE