# Ansible Community Project Management

###### tags: `project management`

This is a rough draft document and will likely get many edits as we discuss and agree on where we want to go with this.

# Problem statement
The community team currently has to follow multiple project boards to track their work, which makes it difficult to get a clear view into work priorities. Without a coherent project management strategy, we lack clarity with each other and transparency to the community on what our team is working on and prioritizing. We also do not have a way for new team members to gain an understanding of what we are working on in the short/medium term.

## The details

The team currently uses the following:
* [Community team initiatives](https://github.com/orgs/ansible-community/projects/5/views/1)
* [Community-team project board](https://github.com/orgs/ansible-community/projects/4/views/1) (consists mainly of the [community team issues](https://github.com/ansible-community/community-team/issues/))
* AAP community engineering team JIRA
* [Documentation project board](https://github.com/orgs/ansible/projects/94/views/1)
* Various other project boards where we have assigned issues, PRs, or requests for help.

We also use the [community-topics](https://github.com/ansible-community/community-topics) for asynchronous discussions and decisions. It is TBD whether all community-topics that are in the implementation phase have issues opened on https://github.com/orgs/ansible-community/projects/2/views/1 (seems abandonded)

A new person joining our team has difficulties tracking across all of these boards, which slows their onboarding process. Existing team members flit between boards, but mostly self-manage their work today.

# Proposed Solution

**Vision** - To manage our backlog and create a project planning workflow that all team members can follow to deliver on our goals and initiatives while maintaining our abilities to self-manage and our community's ability to impact our priorities and deliverables.

**Strategy** - Use ~~three-week sprints~~ monthly goals to manage and track progress on initiatives and goals while providing space and opportunity for recurring responsibilities, unanticipated priority needs, creative experimentation, and personal/professional development.

**Execution** - A single GitHub project board that mirrors Jira tickets as the internal high-level tracking tool for management needs. We will use GitHub to turn those epic-level issues into concrete, smaller deliverables.

**Individual expectations** - Use GitHub to report issues, self-assign issues, and track toward the monthly goals, with the expectation that ‘things happen’ and some members may not complete issues. Others may step in to help or it becomes part of the next month's goals.

The goal is not to add pressure, but to clarify what each of us is doing toward initiatives as well as provide the flexibility to account for daily community needs that don’t always fall into a particular sprint focus. Success is measured by our ability to account for sprint-focused initiatives as well as accommodate the general support/interrupt and experimental nature of our work, without adding a significant process overhead for anyone.

## GitHub board and fields
We are using the [community initiatives GitHub board](https://github.com/orgs/ansible-community/projects/5/views/1). This is currently a private board that uses public issues from the [community-team](https://github.com/ansible-community/community-team/issues) repository. The issues are tracked and linked to our team's set of goals/initiatives, and categorized by:

* goal (aka top-level initiative)
* size (xl,l,m,s,tiny)
* impact (large, medium, small)
* Month (for our monthly issues focus)
* status and assignee

Do we need priority as well so we can see what items are urgent?

Impact, size, and priority are similar but differ in terms of:
Priority - something might be urgent, but small impact for example - getting requirements updated before the core branch build.
Impact - in general, we want to work on high-impact items first and focus our work on what gives us the 'biggest bang' for the ammount of work. This way we know we are focusing on the most important items and not bogged down by what seems important but really isn't compared to other items on our todo lists.
Size is for scoping only. Large etc items should be broken down to smaller issues so we can incrementally reach our goals.

# Summary of team interviews
I contacted each team member to gather their thoughts on the following:

What's working for you with the current approach?
What's not working/where can we improve?
What would make your life a living nightmare

## What’s working today?
General consensus that we individually do not want to be burdened with excess process. With that caveat, everyone leans toward an open GitHub project board to track the important initiatives and issues.
We also feel we have reasonable self-management skills and need to remain empowered to act/react as needed, not entirely driven by a project board.

## What’s not working/where can we improve?
Multiple people expressed a desire to have better clarity into what their peers are working on. This would foster better collaboration and understanding between our individual efforts on behalf of the community.

Having a broader view of what our goals are for the medium term (few months to one year) would also improve overall understanding of where we are going. This is likely started with Greg’s strategy document but we then have to break that down quarter by quarter, for example, to know how we will get to those end goals. We are also individually working on different ‘sub strategies’ for our focus areas. Would be good if we had a better way to share these with each other and to decide when we can share directly in the community (aka write with hackmd instead of gdoc etc).

Multiple people also expressed an interest in going over what each of us is doing in an open meeting like the Monday meeting, vs just in individual 1x1 with a manager. This seems a natural extension of what we do today in the Monday round-robin section and could be adapted to use a project sprint board to help facilitate the conversation and tracking.

## What would make your life a living nightmare?

Strong consensus that no project board can reflect all the work we do. We are by nature interrupt-driven and experimental. As such, the project board is best focused on our longer-term work, vs tracking the day to day things we each do to maintain the community. The project board is best focused on how we improve and grow the community.

There is also worry that working sprint to sprint to sprint leaves people feeling like they are a hamster on a wheel. We need to either account for exploration time within each sprint or leave a few days between sprints to recharge, experiment, and in general work out ideas that may not be in a sprint or ready for a full proposal to the team, or general personal/professional development time, which should be ongoing at our levels.

## Other feedback
Some of the conversations naturally veered off from general project management. Things that were mentioned included:
Why do we not have an actual community (WG) meeting on matrix? Today’s meeting seems to be all about Ansible the package and collections. This is only one part of the ansible ecosystem.
Some of our WG meetings are very detailed and not welcoming to new contributors. This may feed into the prior question - do we need a space for new contributors where they can help each other and in general get to know the entire ansible ecosystem?
Feels like each of our Ansible ecosystem projects are operating in silos. If I don’t know that molecule exists, how do I find out?

# Next Steps
GitHub project boards seems to have what we need to track our work, namely:
* Ability to create ‘epics’ through the issue/subtask feature (linked sub-issues).
* Ability to triage a backlog and assign characteristics such as size, impact, and priority.
* Ability to create and track sprints
* Ability to have a personal ‘view’ of one’s assigned work within the sprints.

Some ideas for next steps are:
* Agree on what we want to track with this new GitHub board, and how/when we individually open new issues (goal would be an initial self-triage when we open an issue, and a review during a weekly sprint update). **done**
* Design the fields and labels we want (meanings of tiny/small/medium/large sizes, impact categories and/or priority settings).
* Review and adapt the community initiatives board to make it ready to mirror the JIRA sprints that are needed for upper management tracking.
* Triage our backlog as a team (synchronously or async)
* Backlog consists of community-team issues and the initiative issues already created.
* We can add issues to the project but since the project is private, we cannot link between an external issue and any internal issues.
* Phase out/archive the older [ansible-community team project board](https://github.com/orgs/ansible-community/projects/4/views/1).
* Commit as a team to use this new board so we can iteratively improve on this effort.
* We will not work in sprints, but a monthly cadence where we plan for the comming month's goals. We are specifically avoiding sprint estimates as we are too interrupt-driven to work that way.

~~Once we have triaged the backlog, decided our strategy and duration, and created our first sprint, we can then use a portion of Monday’s meeting to do a weekly sprint review - progress made, what we each are doing next, and any blockers or areas where we need help.

We could use the matrix remindbot to remind everyone on Fridays to review their work on the board so that on Monday, we can show a quick view of the sprint status onscreen.
~~
## Other feeback/questions for the team
This came up during the discussions:
Do people want less interruptions? (for example, maybe certain hours of the day, we could individually turn off all chat and get deep work done). Or do we do this already on our own?