Dr. Idit Caperton’s Class Summary as of 18/10/2005 What did we accomplish so far?

1. Dr. Idit Caperton’s Class Summary as of 18/10/2005What did we accomplish so far? • We have been together in classes for a total of 14 hours, in 7 sessions, over 5 weeks (including the holiday week): (W)14/9, (T)20/9, (W)21/9, (T)27/9, (W)28/9, (T)11/10, and (W)12/10. • Total semester length is 14 weeks. • We have 8 weeks left to do our work. • You were given 8 Small Assignments so far. • It’s a good time to review everything, check what you missed – to be completed this week.

2. October 19 Flash Lecture Prof. Liu • October 25 Lab Profs. Liu and Zhang • October 26 Flash Lecture Prof. Liu • October 27 Teams Meetings with Idit • October 28 Teams meetings with • Idit@MaMaMedia.com • SEE YOU ON THE WIKI!

3. Activities and Assignments • Write a Short Essay about Yourself - post it on Wiki. (28/43 students; and very few students did it correctly). • Start visiting the Wiki regularly, read other students’ postings, add pages, organize it well, edit your essays and read other students’ essays. It is our class “shared community space.”(No one has done this). • Register into the Forum and start using it regularly. It our “class discussion space.”(10/43 students). • Write a Critique of One Piece of the Readings and post it on the Wiki. Visit other students Essays. (0)

4. Activities and Assignments 5. Write a short description of your own idea for Internet software application (email to Dr. Idit, and post on Wiki). (Only 10/43). 6. Start learning Flash on your own, using the Tutorials that we put on the Class Server. (Only a few students did this). 7. Form Teams and meet twice a week to talk in English and discuss the class readings and decide on your software projects. (8 Teams were formed, but teams are not meeting regularly twice a week to do group work). 8. Brainstorm as a team; select ONE topic for group work; write a description of team’s software project (schedule a meeting with Dr. Idit to discuss, and post on Wiki, expand to include professional presentation with more pages and more details). (8/8, but not all teams completed in full detail as of yet).

5. In this class we place an emphasis on GROUP WORK.- WHY? Why is working in groups an important skill to master for Software Engineers?

6. Why do Software Engineers Need to Learn to Work in Teams? These days, there is a large set of software engineering problems that can only be attacked by small or large teams. These are problems that require: • Significantly large human (brain) efforts • Multiple points of view • Overlapping skills • Complementary skills

7. Team work requires certain techniques There is no guarantee that every group you participate in will be easy or enjoyable. There is a known set of methods for making group work successful. It is worth the effort to learn how to work in groups, because when a group works well together, there's nothing like it!

8. GROUP WORK IS HARD, BUT WORTH DOING • ECNU-SEI academic work typically focuses on well-defined individual achievement, and clear instructional units that are fully-controlled by the Professor. • My class is unusual, it requires more independent work and a large amount of team work is required. • Team work is the content of this course. • I believe that real-world teams in the industry are very common these days, and you have to be prepared well. I saw many of my employees that were not well-prepared for team work, and they failed to produce good work. • Real-world teams are usually assembled after the goal has been identified by the top management, but in this class the team must invent both the problem and the solution. It’s a bit harder. • It’s more like working in a “software startup mode” where a small team of early stage employees brainstorm about the problems and the solution.

9. The Problemkey issues groups usually face • Groups require synchronization among people with: • different skills and levels of knowledge • different backgrounds • different styles of work • different goals • No group can be perfectly in synch all the time. • Group work can create periods of boredom and periods of stress (sometimes even at the same time, as when a group is procrastinating). • Given these conditions, the surprise is not how often group software projects fail, but how often they succeed.

10. Meeting Regularly is RequiredEach team must set the times in advance • When a group does not meet regularly, and does most of the software project work at the last minute, there is little time to consider alternate approaches to the problem at hand. • Lack of reflective time is a disadvantage in any creative endeavor, but it is doubly bad in an educational setting. • Second, the experience of the individual often has more to do with the group process than the final product. Therefore, even if the software project is a success, it can leave the participants with a ‘bad taste’ for group work if the process was dissapointing. • The bad news: Working in groups is not like cooking rice -- there is no recipe for getting it right every time. Groups are fantastically complex entities, and teams can fail, no matter what you do. • The good news: There are a number of things you can do to improve the odds of success.

11. How to make your Team Work Fun • Here are some things you can do to prepare for good-quality group work. Some of them are things the group can do together at the outset, and some of them are ongoing habits. They are: • Embrace ego. (Translate this to Chinese) • Use the group for generating new ideas, not just approving them. • Beware premature optimization. • Structure is not tyranny. • Decide together how to decide. • Use the Wiki social software as common space to interact. • Get everything in writing. • Match people’s roles with project’s goals. • Talk about the relationship among team members. • Accept inequality of knowledge and skills. • There is no substitute for time. Meet often. Talk often. • At the end of the project meet to discuss and reflect and learn.

12. Embrace Ego • Admit to yourself that you have interests and goals, then share them with your fellow group members up front. • The flipside of embracing your own ego is to embrace those of the rest of the group as well. They have interests and goals too. • Getting a list of interests and goals out in the open in the beginning (ideally in the first meeting) will help everyone imagine shared work which could create interesting overlaps.

13. Teams a great for Ideas! • Groups are fantastic tools for having ideas. • Brainstorm often • Throw out ideas rapid fire, express everything in one sentence, postpone judgment until you have a big list. • Produce more ideas and more varied ideas than if you each work alone for several hours. • Teams are also fantastic tools for shaping ideas. Having someone re-express your thoughts and vice-versa exposes ideas to multiple points of view, and the hallmark of a good working environment is when no one can remember who first thought of a particular idea.

14. Do not finalize your software and do not optimize too early • Give yourself some time to work together • Generate lots of ideas before you settle into any one course of action. • Enjoy the PROCESS!

15. Learning about Project Management • You should also choose someone responsible for project management, who will be the keeper of those procedures you've agreed on.

16. Use Social Software(eMail and Wiki and Forum) • No matter how short the project, or how small the group is, if the work is conducted outside class, the members will spend more time apart than together. • This makes your use of communications software critical. • USE OUR CLASS WIKI

17. Write + Write + Write • Expressing a shared group goal is harder than it seems. Especially in English Language. • In a free-wheeling conversation, its easy for everyone to hear what they want to hear, but trying to get something down in words can expose significant differences of opinion and ideas. • For that reason, writing is always worth doing -- in person -- with all group members in attendance, if possible.

18. Reflect During Process, and at the End • Pick a time when you can all get together to reflect about how the project is going. • Find time to reflect - after the project is over. • Sit down together and talk about the experience of working together. Imagine alternate problems you might have taken on, alternate approaches for the problem you did take on, what a next version of the project might look like, and so on. • Talking together after the pressure's off will also be useful for understanding the work you did together, and the ways the group dynamic affected that work.