How Do We Manage Student Projects

1
How Do We Manage Student Projects?

• Eddie Burris BurrisE_at_umkc.edu
• Khaled Alshare alsharek_at_emporia.edu
• Scott Sigman ssigman_at_drury.edu
• Dean Sanders sanders_at_nwmissouri.edu

2
TenImportant IssuesWhen Running Student
Software Projects

• Eddie Burris
• University of Missouri Kansas City

3
Presentation

• Every project and every environment is unique,
  but these issues apply to most projects most of
  the time
• Issues are presented in the style of patterns.
  For all issues, there is no one right answer.
  Each issue must be resolved in a way that
  balances the forces at play in its environment.

4
Real-World Community Project or Artificial
Problem?

• Working on real-world projects with real
  customers and users richer learning experience,
  but may also be more than what students are
  prepared to handle.
• Real projects have messy details that arent
  easily duplicated in fake projects.
• Targeted learning objectives are easier to meet
  with instructor-defined problems.
• Real projects are generally more motivating for
  students but can also be more frustrating when
  things dont go well.

5
One or Two-Term Project?

• Its difficult to complete a sizable project in
  one term, but keeping a team together across two
  terms presents its own challenges.
• The only way a two-term project is feasible is
  when the courses are part of the degree
  requirements. Its nearly impossible to maintain
  a stable team across two courses that are
  electives.

6
Coping with One and Two-Term Projects

• For projects intended to be completed during a
  single term, what topics should be given
  priority? Alternately, when a project class spans
  two terms, how do you divide the work between the
  two terms and manage disruptions to team
  composition?
• Single-term projects generally choose to focus on
  either the technical or non-technical aspects of
  performing a project. Multi-term projects
  typically focus on the early phases of the
  software life cycle during the first term, and
  later phases during the second.

7
Individual vs. Team Projects

• Should students be allowed to work alone or
  required to work in teams?
• Working in teams gives the students the
  opportunity to experience team dynamics,
  organization, coordination and negotiation but
  leaves less time for focus on more technical
  challenges.
• Students need some exposure to working in teams.

8
Selecting and Enforcing a Development Process

• Should instructors enforce process on student
  projects and if so, which process and at what
  level of rigor and formality?
• Should students be allowed to define their own
  process?
• Finding the right balance between discipline and
  agility.
• Students must be sold on the idea of following a
  process.

9
Deciding What to Teach vs. What to Assign

• What items should students be expected to learn
  on their own?
• Even over two semesters, its impossible to cover
  all topics that will be needed to complete a
  moderately sized project.
• Important topics project management,
  requirements, design, metrics.

10
Integrating Soft Skills

• Team dynamics and other soft skills are important
  for project success but not all computer science
  instructors are comfortable or qualified to teach
  these soft skills.
• Soft skills can be taught on an as needed basis
  or in anticipation of problems.

11
Weighting Intermediate Milestones in Comparison
with the Final Deliverable?

• When grading deliverables what portion of the
  project grade should be allocated to intermediate
  deliverables (requirements, design, test plan,
  etc.) vs. the final result?
• Putting more weight on upfront work helps insure
  a successful result but can also send the message
  that paperwork is more important than working
  software and a satisfied customer.

12
Assessing Individual Contribution in a Team
Environment

• When students are working in teams how do you
  accurately assess individual performance and
  structure the assessment in a way that encourages
  teamwork and discourages social loafing?
• One way of rewarding both group and individual
  effort is to assign a value to the team result
  and then use peer review to decide what
  percentage of this value is owed to each student.

13
Dealing with Hardware and Software Issues

• Students often need dedicated hardware and
  software resources to complete a project. Those
  responsible for campus computers dont like to
  give students admin authority on public
  computers.
• Special isolated machines may be set up for
  students to use. Also, several online ISPs offer
  hosting services at reasonable prices.

14
What Went Right and What Went Wrong in Managing
Students Projects?

• Khaled A. Alshare
• Emporia State University

15
What Went Right?

• 1. Forming Groups
• Discuss the process of group formulation.
• Form the groups based on student background
  sheet.
• Request each group to have a group name and a
  logo.
• Request each group to have a team contract
  (responsibilities and roles).
• Request each group to identify a method of
  communication and sharing information (e. g.,
  creating a website for the group).
• Request/encourage students to use project
  management software packages and techniques.

16
What Went Right?

• 2. Topic Selection
• Let students choose their own projects with
  instructors approval.
• Create small projects but complete ones (having a
  final product).
• 3. Managing the Project
• Request weekly progress reports.
• Request meeting minutes for each group
  meeting.
• Attend a few meetings with the group if it is
  possible.

17
What Went Right?

• 3. Managing the Project
• Request lessons learned.
• Divide the project into milestones phases.
• Make a due date for each milestone phase.
• Allow students to work on the project during
  class
• time.
• Provide students with laptops in the class to
  work
• on the project if it is possible.

18
What Went Right?

• 4. Evaluation Process
• Provide evaluation criteria for the project (the
  written report and oral presentation).
• Use peer evaluations.
• Use judges jurors to evaluate the
  presentations.

19
What Went Right?

• 4. Evaluation Process
• Give extra points for the group that completes
  the project before the due date.
• Ask each group to identify the hero of the
  group that student gets a certificate of merit
  and/or extra points.
• Set procedures for handling free riders early in
  the
• semester.

20
What Went Right?

• 5. Presentation
• Ask students to prepare professional
  presentations.
• Ask students to practice their presentations
  before the due date.

21
What Went Right?

• Online Groups
• Make sure every group has an active member.
• Ask students to check their physical locations.
• Utilize technology to conduct virtual meetings.
• Check with real businesses on how do they handle
  online groups.

22
What Went Wrong?

• Students form their own groups.
• The project was not divided into milestone
• phases.
• No progress reports.
• No peer evaluations.

23
What Went Wrong?

• No discussion of the project during the
• semester.
• No clear evaluation criteria.
• Project topics are selected by the instructor.
• Small group size (3 or less).
• Thanks!

24
What I Thought I Knew

• Managing A Software Engineering Course
• Scott Sigman
• Drury University

25
Paradoxical Question

• On One Hand
• A major goal is to teach students to manage a
  software development project.
• On The Other Hand
• Students lack the skills experience to do so.

26
My Experience

• First SE Projects in 1984
• Developed two semester approach early on
• Teams have developed projects for both internal
  customers and external customers.
• Course is much more challenging to teach today!

27
What Has Changed?

• Bright Students Has not changed!
• Lack of experience organizing
• Deadlines are much less meaningful
• Moving On Syndrome
• Ignore problem as if it does not exist

28
The Challenge

• IMHO
• Learning to effectively create and execute a
  project plan is vital. We must resist the urge
  to do the management for the students.
• Teach Scheduling W/O Scheduling
• Teach Management Without Managing
• Implications for
• Artifact quality
• Product Scope

29
My Approach

• Studio Approach
• My role Mentor resource person
• Students Create a Software Management Plan
• Create Weekly Detailed Schedule
• Review prior weeks schedule w. emphasis on what
  was done.
• Look at schedule for next week.
• Grading
• Require 12 hr/week
• For C or better, must meet schedule 12 of 15 weeks

30
Using Scrum With Student Projects

• Dean Sanders
• Northwest Missouri State University

31
Origins of Scrum

• Initially developed by Jeff Sutherland in 1994
  for teams at Easel corporation
• Formalized and documented in conjunction with Ken
  Schwaber (1996 OOPSLA paper)
• Based on empirical process control

32
Process Control Theory

• Two major approaches
• Defined
• Empirical

33
Defined Process Control

• Requires that every piece of work be completely
  understood
• Given a well-defined set of inputs, the same
  outputs are generated every time
• Essentially, an assembly line philosophy

Do I hear a waterfall?
34
Empirical Process Control

• Expects the unexpected
• Provides and exercises control through
• Frequent inspections
• Adaptation for processes that are imperfectly
  defined

35
Rationale for Scrum

• Software development is an intellectually
  intensive activity that requires too much
  thinking and creativity to be a good candidate
  for the defined approach
• The proper control for software development is
  frequent inspection followed by immediate
  adjustment

36
Scrum is

• a management and control process that focuses
  on building software that meets business needs
• superimposed on top of and wraps existing
  engineering practices, development methods, or
  standards
• primarily a team-level process
• adaptable and scalable (up or down)

37
Scrum is Not

• an agile lifecycle model
• a magic bullet
• for those who crave strong oversight and control

38
Key Participants

• Scrum Master
• The instructor should play this role
• Product Owner
• The client will play this role
• What if the instructor is also the (simulated)
  client?
• Scrum Team
• The students play this role

39
Communications Among Stakeholders
Stakeholders
Scrum Master
Product Owner
Scrum Team
40
Key Artifacts

• Product Backlog
• Sprint Backlog

41
Scrum Game Plan Developing the Product Backlog
Stakeholders
Product Owner
Ideas
42
Sample Product Backlog
43
Scrum Game Plan Sprint Planning
Scrum Team
44
Sample Sprint Backlog
45
Key Activities

• Sprint Planning
• Sprint
• Daily Scrum
• Sprint Review

46
Sprint Planning

• Two consecutive meetings
• First meeting
• Stakeholders, Product Owner, and Sprint Team
  determine next sprint goal and functionality
• Second meeting
• Team meets alone to determine what work needs to
  be done to meet the goal and build the
  functionality into the product
• Team creates the Sprint Backlog

47
Scrum Game PlanThe Sprint
Scrum Team
Scrum Master
48
Sprint

• Team works on Sprint Backlog for a fixed time
  period, usually 30 days.
• Team has full authority to do whatever is
  necessary to meet the Sprint Goal
• Team updates the Sprint Backlog as necessary
• No one outside the team has the authority to
  change the Sprint Goal or Sprint Backlog during
  the sprint

49
Daily Scrum

• Team meeting
• Required attendance
• Max 15 minutes
• Scrum Master conducts meeting
• Each person verbally answers three questions
• What have you done since the last meeting?
• What do you plan to do before the next meeting?
• What impediments need to be removed?

50
Sprint Review

• Informational meeting for Product Owner and
  stakeholders
• Scrum Master provides concise overview
• Team presents the product increment that was
  constructed during the sprint
• Sprint Goal and Product Backlog are compared to
  actual results
• Discrepancies are investigated

51
A Comparison
Scum
My Class

• Team size 4-7
• 30-day Sprint
• Team creates Sprint backlog
• 40-hour work week
• Daily Scrum
• Review after each Sprint

• Team size 3-5
• 2-week Sprint
• Team creates Sprint backlog
• 4-hour work week
• Scrum each class period
• Review after each Sprint
• Less documentation

52
Using Scrum With Student Projects

• Final Whistle