Project Management

Keith VanderLinden
Calvin University

People and Processes Matter

“The major problems of our work are not so much technological as sociological in nature.”
— T. DeMarco & T. Lister, Peopleware, 1987.

We need to attend to:

• People
• Processes

• This idea:
  • Focuses on software development, in which so many notable failures were attributable not to bad software but to bad management.
  • Applies to data science (and lots of other things) as well.
• This is because CS (and DS, …) projects are too big to be:
  • Done by one person → understanding people.
  • Specified fully up front → understanding agile/lean methods.
• Process matters, human processes, that is; things other than data analysis, modeling, etc. E.g.:
  • Creativity, ideation, innovation
  • Management, communication, team work, (even counseling), aka “soft skills”
  • Anthropological analysis of systems in context
  • Usability studies and user experience design
  • Technical writing and presentation
• Thus, this module focuses on:
  1. Individual and team management
  2. Life-cycle models

People and Personality

The Big Five Personality Traits

• Openness
• Conscientiousness
• Extraversion
• Agreeableness
• Neuroticism

• People tend to think that everyone else is like them. They’re not. You don’t want them to be.
  • Know thyself!
  • Appreciate thy partners!
• Big Five Dimensions (OCEAN), cf. Meyers-Briggs (MBTI)
  • Openness - O’s:
    • Enjoy new intellectual experiences and ideas.
    • Are imaginative/curious/broadminded, not routine/boring.
    • Can be creatives and testers, but perhaps not operatives.
  • Conscientiousness - C’s:
    • Show self-discipline.
    • Are dutiful/competent/thorough, not lazy/careless.
    • can do management, but perhaps not joy (?).
  • Extraversion - E’s:
    • Seek stimulation in the company of other people.
    • Are sociable/energetic/enthusiastic, not into solitude.
    • Are good with users/communication, perhaps not public speaking.
  • Agreeableness - A’s:
    • are compassionate towards others.
    • Are pleasant/tolerant/tactful, not aggressive/rule-breaking.
    • are fine, but conflict is sometimes necessary for progress.
  • Neuroticism - N’s:
    • Experience unpleasant emotions relatively easily.
    • Are anxious/hostile/depressed/self-consciousness, not emotionally stable.
    • have unclear value; N’s can sense issues early.
• Notes
  • The questionnaire was pretty limited, so don’t take the results as a “straight jacket”.
  • There are good and bad things about each (really).

References

• These are my results for one of my runs:
  • http://www.outofservice.com/bigfive/results/?oR=0.525&cR=0.75&eR=0.281&aR=0.694&nR=0.531
• Other traits
  • Current research suggests that there might be a 6th: Self-centeredness.
    • Givers vs Takers
    • Let’s learn to do both.
  • Cognitive ability clearly enters into this as well, but it’s not interpersonal in nature.
    • See http://www.ijikm.org/Volume2/IJIKMv2p163-177Sodiya.pdf

Communication Management

Managing remote teams requires communication tools.

• Asynchronous
• Synchronous

• To instantiate interpersonal communication, we’ll be using MS Teams:
  • Asynchronous: MS Teams Channels; Slack; Discord
  • Synchronous: MS Teams Video meetings; Zoom; remote pair programming

Agile Methods

Agile methods follow the values of the Agile Manifesto.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

• Agile methods are characterized by:
  • Principles (i.e., the Agile Manifesto)
  • Practices (i.e., Agile = iterative (cf. DMLS pp. 32) + incremental (sort of)).
• Agile approaches were developed to fix the obvious problems with the waterfall approach (q.v., the engineering slides from module 1).
  • Big, high-ceremony processes, lots of documentation, contracts, and plans just didn’t work very well.
  • Nobody knows, up front, how a project should be scoped or designed.
• I don’t think that anyone in the DS world could even conceive of using a waterfall approach for a DS project. EDA and even modeling are just too open-ended, non-prescribed, and, well, exploratory.

References

• https://en.wikipedia.org/wiki/Iterative_and_incremental_development

Lean Methods

Lean methods also follow a set of principles.

• Push rather than pull planning
• Workflow visualization
• Limited WIP
• Workflow optimization over time

• Lean methods are also characterized by:
  • Principles (i.e., these principles)
  • Practices (i.e., Kanban boards)
• Lean methods were developed to improve process efficiency.
  • Doing only what needs to be done now (pull planning), and being able to view the process (visualize the workflow, limited WIP) helps to reduce waste.

References

• Lots of good articles: https://www.atlassian.com/agile
• Agile vs. Lean: https://www.atlassian.com/agile/project-management/lean-project-management

Agile/Lean Management

Though not the same, agile and lean approaches tend to support development that is:

• Both iterative and incremental.
• Driven by visual planning tools.

• Compare and contrast:
  • Agile: people-focused
    • methodologies: XP, Scrum, …
    • Customers - XP asks for a “customer” on the team.
    • Developers - XP & Scrum have frequent stand-ups and retrospectives.
  • Lean: efficiency-focused & visual
    • Kanban/project boards (GitHub Projects/Issues; Trello)
• Accounting for time:
  • Clockify
  • Jira has built-in time tracking (and project boards).

GitHub Flow

See the live demo.

• GitHub Flow is multi-branch collaboration model for using Git.
• Walk through GitHub Flow using this diagram.
  1. Create a branch from main.
     • The main branch is the official, running system.
     • The feature branches are for separate sub-tasks in progress.
     • Some approaches include a develop branch as well.
  2. Make changes on the feature branch (named feature/??).
     • The feature should be a coherent/complete/isolated change.
     • Develop the feature using commit/push on the branch.
     • If things don’t work out, just delete the branch.
  3. Create a pull-request (PR).
     • Pull from main again to merge the latest changes, re-test/fix, issue PR.
     • PRs ask someone to merge the feature branch into main.
     • Document the PR and ask teammates to review it.
  4. Merge the PR.
     • Appoint one (or more) “guardians” of the main branch; don’t merge your own pull requests.
  5. Delete the branch.
     • You can recover your commits and the PR if needed.

References

• Gitflow != GitHub Flow
  • https://www.alexhyett.com/git-flow-github-flow/
  • Atlassian characterizes Gitflow as “legacy” and calls GitHub Flow “feature-branch workflow”.
  • I’ve mistakenly conflated these two workflows. GitHub flow is simpler than GitFlow and preferable for most of our course projects.
• https://github.com/kvlinden-courses/cs262/blob/master/materials/03management/gitflow.png