---
format:
    revealjs:
        theme: simple
        chalkboard: true
        auto-stretch: false
---

## Project Management

Keith VanderLinden<br>
Calvin University

## People and Processes Matter

&ldquo;*The major problems of our work are not so much technological as sociological in nature.*&rdquo; <br><small>--- T. DeMarco & T. Lister, *Peopleware*, 1987.</small>

We need to attend to:

- People
- Processes

::: {.notes}
- 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 &rarr; understanding people.
    - Specified fully up front &rarr; 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

::: {.notes}
- 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

::: {.notes}
- 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](https://agilemanifesto.org/).

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

::: {.notes}
- 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

::: {.notes}
- 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.

::: {.notes}
- 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.*

![](images/github-flow-walkthrough.png)

::: {.notes}
- GitHub Flow is multi-branch collaboration model for using Git.
- Walk through *GitHub Flow* using [this diagram](<https://github.com/kvlinden-courses/cs262/blob/master/materials/03management/gitflow.png>).
    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](https://nvie.com/posts/a-successful-git-branching-model/) != [GitHub Flow](https://docs.github.com/en/get-started/using-github/github-flow)
    - <https://www.alexhyett.com/git-flow-github-flow/>
    - [Atlassian](https://www.atlassian.com/git/tutorials/comparing-workflows) 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>
:::
