INFO 324
Team Process and Product
Week 8
Glenn Booker
College of Information Science and
Technology
Drexel University
Copyright by Gregory W.
Hislop
1
www.ischool.drexel.edu
Introduction
Agenda
• Control in a project team
• Human dimension
– Control of team formation and performance
• Technical dimension
– Revision control
Copyright by Gregory W.
Hislop
2
www.ischool.drexel.edu
Control – Human Dimension
• What does it mean to control a team?
– What does a team leader need to do?
• Key perspectives
– “What to do” changes as a team forms and works
– Things need to happen for a team to jell and
perform well
• And those things don’t usually “just happen”
• Team leader and member awareness and action matter
•
A model can be useful for thinking about this
Copyright by Gregory W.
Hislop
3
www.ischool.drexel.edu
Team Development Model
• Tuckman (1965) – Defined stages of
group development based on lit review
– Forming (testing and dependence)
– Storming (intragroup conflict)
– Norming (development of group cohesion)
– Performing (functional role-relatedness)
– [Adjourning]
Copyright by Gregory W.
Hislop
4
www.ischool.drexel.edu
1. Forming
• At time of group formation
– And sometimes for a long time after
• Low commitment by members
• Lack of clearly understood shared goals
• Lack of clearly defined roles and
responsibilities
Copyright by Gregory W.
Hislop
5
www.ischool.drexel.edu
1. Forming
• Processes undefined or ignored
• Members question and test leader
• Leadership
– Directive
– Answering questions on goals and roles
– Defining and establishing external
connections
Copyright by Gregory W.
Hislop
6
www.ischool.drexel.edu
2. Storming
• Teams don’t gel easily
– Group and individual needs and goals often
differ
• Members jockey for position within the
team
– Leader gets challenged
• Alliances form
• Power struggles may occur
Copyright by Gregory W.
Hislop
7
www.ischool.drexel.edu
2. Storming
• Goals become clearer, but still lots of
confusion and discussion
• Leader
– Coaching and facilitating
– Encouraging compromise
– Continuing to explain goals and objectives
Copyright by Gregory W.
Hislop
8
www.ischool.drexel.edu
3. Norming
• Team gels
• Shared goals have been established
• Roles and responsibilities are known and
accepted
• Members are committed to the team
– Team has unity
– Members have loyalty and sense of belonging
Copyright by Gregory W.
Hislop
9
www.ischool.drexel.edu
3. Norming
• Team
– Discusses and develops processes and
approaches
– May socialize or share fun activities
• Leader
– Facilitates and enables
– Delegates smaller decisions
– Guides team decision by consensus for larger
decisions
– Has respect and support of members
Copyright by Gregory W.
Hislop
10
www.ischool.drexel.edu
4. Performing
• Team routinely produces useful results
• Everyone knows the goals
– And thinking is strategic and not just tactical
– Focus is on achieving goals (and going
beyond them)
• Members know and perform their roles
– And support each other
Copyright by Gregory W.
Hislop
11
www.ischool.drexel.edu
4. Performing
• Team
– Operates with autonomy
– Makes most decisions
• Based on criteria developed with the leader
– Works on improving relationships and processes
• Leader
– Delegates and oversees
– Coordinates and communicates
– Supports individual and interpersonal goals
Copyright by Gregory W.
Hislop
12
www.ischool.drexel.edu
5? Adjourning
• Not really a stage in team formation and
operation
– Added to the model about 12 years later (1977)
• Addresses team break-up
• Recognizes importance of transition for
people
– Difficulty of change
– Sense of vulnerability
– Need for organizational recognition of
accomplishment
Copyright by Gregory W.
Hislop
13
www.ischool.drexel.edu
Stages may not be linear!
Copyright by Gregory W. Hislop
14
www.ischool.drexel.edu
Key Team Development Themes
• Leadership role changes
• Team and team member needs both matter
• Team success depends on human
relationships
– Not just technical ability
• Key concepts need attention
–
–
–
–
Goals and roles
Leadership
People issues
Process
Copyright by Gregory W.
Hislop
15
www.ischool.drexel.edu
Crossover
• The concepts in Tuckman’s model apply to
other realms as well
– An infant
– A child
– Growth of a company
– Human relations training group
– Therapy patients
• Stage duration relates to task duration
Copyright by Gregory W. Hislop
16
www.ischool.drexel.edu
Tuckman Today
• Lots of follow-on articles (thousands)
– Mostly additions or modifications to the stages
• Still widely cited and discussed
– Memorable labels count for something!
– Model seems to resonate with reality
• For more information, Google “tuckman's
group development model”
Copyright by Gregory W.
Hislop
17
www.ischool.drexel.edu
Revision Control Tools
Copyright by Gregory W. Hislop
18
www.ischool.drexel.edu
Control – Technical Dimension
• Tools are very beneficial to imposing order on
team project work
– And more so for distributed teams
• For FOSS projects, revision control tools are
universally the central control mechanism
– Project “committers” are the key people on the
project
• The leading revision control tools are all
FOSS projects themselves.
Copyright by Gregory W.
Hislop
19
www.ischool.drexel.edu
Revision Control Overview
• Why do we need revision control?
• What does revision control provide for us?
20
www.ischool.drexel.edu
Why Revision Control?
• Software products are large and complex
• Development is done by teams
– Often distributed
– Working in parallel
• Active projects usually exist in several
versions
– Stable (“production”)
– Under development (“sandbox”)
– Prototype or experimental (a or b test)
21
www.ischool.drexel.edu
Informal Revision Control
• Could ‘Save As…’ the file versions
– MyFile_V1, MyFile_V2, MyFile, …
• Then use “diff” tools to compare two
versions of a file and show the differences
• Problems
– Labor intensive
– Not organized
– Hard to share with others
Copyright by Gregory W.
Hislop
22
www.ischool.drexel.edu
Informal Revision Control
Another simple manual approach
Copyright by Gregory W. Hislop
23
www.ischool.drexel.edu
Revision Control Benefits
• Backup and restore
– Repository lives in multiple places
• Synchronization
– Orderly way for team members to have the
latest revision
– Orderly way to integrate work from individuals
• Roll-back
– Ability to reproduce the product as it looked
at any point in the past
Copyright by Gregory W.
Hislop
24
www.ischool.drexel.edu
Revision Control Benefits
• Change tracking
– Ability to group changes to multiple files and
provide a tag explaining the change
• Change ownership
– Record of who created each change
• Multiple active versions simultaneously
– Local working copy – each person’s sandbox
– Branches – Project level sandboxing
Copyright by Gregory W.
Hislop
25
www.ischool.drexel.edu
Revision Control Terminology
• Branch – a trail of revisions for one version
of the product
• Conflict or collision – contradictory
changes from two sources
• Head – the most recent revision
• Repository – the set of controlled
documents
26
Copyright by Gregory
W. Hislop
www.ischool.drexel.edu
Revision Control Terminology
• Revision – a snapshot of the repository at
some level of change
• Trunk – the branch containing the
production product
• Working copy - your copy of the repository
27
Copyright by Gregory
www.ischool.drexel.edu
W. Hislop
Revision Control Actions
• Commit or Check in - to apply changes to
the repository which creates a new
revision
• Fork – to create a new branch within a
repository
• Merge – to combine two branches or to
combine two versions of a file
• Synch – to update your working copy with
the latest version from the repository
28
Copyright by Gregory
W. Hislop
www.ischool.drexel.edu
Revision Control Mechanics
• Control Strategy
– How to impose order on multiple people
working on the same documents
• Architecture
– Master repository and working copies – like
SVN (subversion)
– Distributed - Git
Copyright by Gregory W.
Hislop
29
www.ischool.drexel.edu
A Problem to Avoid
30
www.ischool.drexel.edu
Pessimistic Solution
• Assume that collisions like this are
common
• Solution: Ensure that collisions can’t
possibly happen
– Lock files for editing
31
www.ischool.drexel.edu
Pessimistic Solution: Lock Files
32
www.ischool.drexel.edu
Optimistic Solution
• Assume that most editing doesn’t really
cause collisions
– Changes in different files
– Changes in different parts of the same file
• Allow work in parallel
– Allow collisions but detect them and force
resolution
33
www.ischool.drexel.edu
Optimistic: Modify & Merge
34
www.ischool.drexel.edu
Modify and Merge
35
www.ischool.drexel.edu
SVN Demo
• “TortoiseSVN is an easy-to-use SCM /
source control software for Microsoft
Windows and possibly the best standalone
Apache™ Subversion®client there is. It is
implemented as a Windows shell
extension, which makes it integrate
seamlessly into the Windows explorer.
Since it's not an integration for a specific
IDE you can use it with whatever
development tools you like.” From here.
Copyright by Gregory W. Hislop
36
www.ischool.drexel.edu
SVN Assignment
• Install TortoiseSVN from sourceforge.net
• Create an empty folder
• Right click the folder and Select "SVN
Checkout“
• Enter the source forge repository name:
– https://currman.svn.sourceforge.net/svnroot/currman
• Edit, commit, create collision.
•
Print result and turn in
Copyright by Gregory W.
Hislop
37
www.ischool.drexel.edu
In Your Future...
• For next week
– Revision control assignment
• SVN conflict and resolution
Copyright by Gregory W.
Hislop
38
www.ischool.drexel.edu