Gina presented this (see 20150921 17.40 Neos Team Structure.pdf) agile team concept to us during the first day of the sprint. Tobias Gruber summarized the current status (in our internal Slack channel) and how we got there because we wanted to vote on it (if we will adopt it):
We started by brainstorming problems that we currently have in the Neos team (image 1+2).
We then brainstormed tasks/activities we are currently doing (image 6+7) which translate more or less into departments in legacy companies.
Gina then started to develop the agile team structure (image 8 ), consisting of the "community cloud”, cross-functional teams (max 12 members - image 5) with 2 specific roles (Syncronizers and Prioritizers - image 10), communities of practice (COP - image 9), the council of elders (image 3).
We then thought about pros and cons of the agile model compared to the current situation (image 4).
The last thing we did was to translate our current problems into things we need to take care of (image 11+12).
With that we formed 3 groups (image 13) working on a) the description and guidelines for the Syncronizers and Prioritizers, b) the decision guidelines and the description and guidelines for the COPs and c) the description and guidelines for the community of elders and how the task force for the transition should be formed and what it should do.
Team size: 3-4
Objective: manage initial team formation, drive implementation of new project structure and provide support for all transition-related issues
Required contribution: a lot in the first month, then gradually less over the next half year
push the transition
Visualize progress and tasks (JIRA)
Communicate progress to stakeholders
Most important task: manage initial team formation
create a list of skills needed for Neos Project
create a list of candidates (educated guess) and let the elders check the list
do permutation (is it possible to create 3 teams with minimum 6 members with the candidates and their skills)
interview every candidate if they are willing to work in a team and ask for their skills (possibly extend the skills list)
with confirmed candidates and update skill list: set up meeting of all candidates to form initial teams (within guidelines: 3 teams with min. 6 members, skills should determine team allocation)
Things that need to be taken care of periodically (not planable) that aren’t features.
Support queues (inboxes)
Activity updates (blog posts)
Review (pull request triage)
Issue queue triage
As small as possible (cannot be broken into smaller pieces) – should be less than a day of work
Needs to have a ticket
Needs to be brain stormed/reviewed by another team member
Tasks that have been selected by the prioritizer should be worked on first
No necessarily part of a project (not a sub-task)
Responsibility of the team when selected for the team backlog
Writing a blog post
Fix a bug
Add a test
Take care of something
Epic in Jira
must be an accepted Project Proposal (see below) and is created by a prioritizer (e.g. website update)
Consist of multiple tasks
Multiple people need to work on
Limited and defined scope (can be finished, not a topic)
Can be solved by a team autonomously
Can vary in size
Should be broken down further if they are not achievable for the team in less than three months
Note on Accepted Projects and Proposals:
Even if a project has already been decided upon, create a Project Proposal for documentation purposes so it is transparent what it is about and who decided it. Projects coming out of an RFC must also have a Project Proposal (as a linked topic).
Project Proposals are to be posted in Discourse in the Project Proposals category and probably follow some template. Discussion period etc. need to be defined, probably.
Project proposals and new RFCs should be announced in the relevant Slack channels and on any other channel that makes sense to raise awareness and give everyone a chance to know about it.
Releasing a Neos/Flow version is a project
Every bigger feature is a separate project
A marketing campaign
Setting up and adjusting to a new tool
Guidelines for filling project / kitchen duty / task backlog
A team backlog for each team
A general backlog for the whole Neos/Flow project
Team backlog filled from the general backlog by the prioritizer
Team members can influence team backlog through the prioritizer
Can come from team members, community, CoP, customers (through team members) by creating project proposals
can only be added to in-progress projects if the prioritizer approved
Can come from Jira tickets, incoming emails – create a jira ticket or send an email a fitting inbox for all other inquiries