Team Survey - Pain Points

(btw I’m not answering the survey because I’m not a dev and most questions don’t apply to me)

Hi @daniel,

Thanks for formatting your feedback. I agree - it would be helpful if Typeform allowed line-breaks! You’ve given me a lot of valuable information to dig through. I appreciate it :slightly_smiling_face:

Hi @antoviaque

Sure. I see you’ve already created a team-wide ticket for Serenity. I’ll do the same for Bebop and Falcon, and ping each member on their ticket. I hope that’s what you had in mind…?

Edit:
I’ve replicated the tickets you created for Serenity member for Bebop and Falcon. I’ll ping each member individually and remind them (if necessary) to complete the survey.

2 Likes

@Ali Thank you! I had actually already created the tickets for Bebop and Falcon too - sorry that I wasn’t clear about this :/ They were linked from the Serenity ticket (which is the canonical ticket description for all cells), but I hadn’t explicitly mentioned them: https://tasks.opencraft.com/browse/BB-4886 and https://tasks.opencraft.com/browse/FAL-2415 . So we have a few duplicate tickets I’m afraid! I’ll close the extra ones.

@antoviaque Oh geez, oops! Sorry. I looked for Bebop and Falcon tickets but must have missed them. Sorry for giving you extra admin! :see_no_evil: Thanks for closing the duplicates.

1 Like

@Ali This is an amazing survey! Thanks for putting it together!

1 Like

Hi @team

The results from the “Improving the Work Experience at OpenCraft” survey are ready! :tada:

Thank you to everyone for taking part. I hope this document makes it easier to figure what the next steps should be, and how we can make OpenCraft even better. You can check out the results here.

12 Likes

@Ali Thank you for the nice work on this survey! This report, and the survey answers it contains, are really helpful to understand the situation better, as well as have everyone’s opinion.

I agree with many of the points made - it’s a good occasion to fix them, the pressure on the processes made the inefficiencies more visible. It could both help providing relief now, and make us more resilient to overload in the future.

In terms on action items on this:

+1

The way we are currently progressing on these fronts:

  • Confirming new core members:

  • Redefining and simplifying roles: We are working on several simplifications and merges of roles this sprint, with handbook PRs being reviewed on:

  • Allowing for more specialization:

We are all participating to the reviews on the points listed above through Log in - OpenCraft (and the related tasks for each cell), so we’ll discuss many of these points on the handbook PRs next week.

I also started preparing the follow-up survey, to get a better feel for what everyone is thinking, and making sure that we’re ready and ok to switch to the new changes, once the PRs are merged. The current rough draft is at Log in | Typeform - it still needs work (add open answers, URLs, refine the questions, etc.), but I’ve added most of the main questions I had noted, so if you see any missing question don’t hesitate to add a slide or a comment there. I’ll do another pass next week before publishing it - which should be once all the related handbook PRs are ready for the wider team review, so likely Wed-Thu given the timelines for reviews listed on Log in - OpenCraft.

This is something that I’m hoping we could get out of the developer/contributor advocate role that you are suggesting in Proposing a Developer Advocacy Role @nizar ? Having more time dedicated to this would be useful, I agree. I still do some of this work, like 121s, but we need to be able to scale this aspect.

Having someone in charge of maintaining the handbook actively, and taking care of what is describe here, seems useful yes. Part of the current issue is organizational debt coming from a lack of such maintenance. If OpenCraft is an open source project, then the handbook is part of its source code - it needs to be maintained. Maybe that would also be something part of the developer/contributor advocate role @nizar ? Or any of the community-related roles we have been discussing?

That’s definitely part of the pass on simplifying the sprint planning that @nizar is leading: Log in - OpenCraft with a great contribution on this by @giovannicimolin at https://forum.opencraft.com/t/sprint-retrospective/1012/85

6 Likes

@antoviaque, I haven’t yet read your reply fully. But I wanted to mention that I would like to be involved in providing feedback on the current situation and issues, even if it is collected after my last working day, since I have first-hand experience. I hope that is okay.

5 Likes

I definitely think a developer advocate role would help.

I honestly haven’t had the chance or mental capacity yet to think of ideas which would help monitor the happiness and efficiency more effectively.

However, with more resources dedicated to the team’s success in OpenCraft, I can have some ideas/suggestions, if and when I transition to such a role.

One main point I have in mind though is getting up-close with the members who have had a bad sprint. This should provide an idea regarding what issues might be faced early on.

Maintaining OpenCraft’s handbook should definitely be part of the Developer Advocate role. The DA should ensure that the handbook is changed in ways which would help ensure the success of the community at OpenCraft.

I don’t think having only the DA make changes to the handbook is the only solution. After all, some members might enjoy contributing changes to the handbook.
However, I think there should be a strict process for the changes which should be done to the handbook.

I’ll definitely consider this when creating the PR about the role.

2 Likes

@bebop @falcon @serenity
@braden @Fox @gabriel

The PR for merging these two roles is ready for team-wide review at public#353 :slight_smile:

CC @antoviaque

3 Likes

@bebop @falcon @serenity
@braden @Fox

The PR for defining the new role is ready for team-wide review at public#358. :tada:

The main purpose of the new role role is to help lighten the load of management work
that cell members have to take care of, so that they can focus more on coding/DevOps, and on handling their clients/epics.

It’s not a role that focuses on project management in the traditional sense, which is why I proposed to call it “Cell Supporter”.

CC @antoviaque @gabriel

5 Likes

Now all the pull requests from the current round of changes is ready (see the task description in SE-4838 for links), as well as the follow-up survey (to fill after reviewing the pull requests/tickets, since it’s about providing feedback on the measures).

4 Likes

Here are the results of the second survey: Improving the Work Experience - Decisions & actions review (PDF: Improving the Work Experience - Decisions & actions review.pdf)

I’m also listing the points/remarks made in the survey:

Sprint planning

I’m not quite sure why we even need that many actions with “stretch goals”. I’ve asked assignee about this. But other than that, work on simplifying, that is outlined in the Jira comment, looks good to me. Trying the new process and pivoting / improving would be the next step.2 days ago

What steps from stretch goals are too numerous? I see two listed for the sprint planning manager in https://docs.google.com/spreadsheets/d/1w4FOWrTrAwBaBIueulZICJ4WyddAWb8ZDo2tnQRxhJU/edit#gid=1908703638 and they seem reasonable?

It would be helpful to have someone check that the monday.com steps are properly completed and suggest solutions when they’re not or when everything happens last-minute5 days ago

+1, but doesn’t that remain one of the responsabilities (and checklist items) of the sprint planning manager?

next step is to take the feedback on board and test the simplifications

+1 – testing the changes, measuring the impact, and if needed iterating to fix any issues found with the new checklist, would be the next step here. @nizar has created Log in - OpenCraft for this.

Roles simplification

Yes, I still feel we don’t have an empiric measurement of how much time we can effectively save or how much metalwork we can reduce. How can we find out if the changes we are bringing in are actually working?

It’s true that it would be useful to have a metric for this. For metawork from cell roles, we do have a record of time spent, on cell roles budgets. It does not include project management on individual epics, but it could be worth compiling the numbers, to figure out the current time spent on it, and see how that evolves?

That said, probably the main metric we are trying to lower is the number of unwanted metawork – and that’s a more subtle thing to measure. For this surveying/polling of the team could also provide an answer – and then we can look more closely at the responsibilities of those who have too much unwanted metawork, to see if it can be reduced or pass on to someone else?

@nizar As part of your new role, would you like to schedule a ticket to look at those two elements?

Not, sure, but I see as much mention of new roles as I see of merging existing roles. Perhaps something to do for next iteration.

We still have just as many roles. Some are merged, but now we have new roles too.

This is the same comment from two different persons – but I’m not sure I understand the remark: for the new roles, do you mean the cell supporter and the consolidated developer advocate roles? They are non-cell, so they don’t add to the duties of cell members, they remove from it? The goal is to staff them independently, to support the work of cells – a bit like the sales and admin roles don’t add roles for cell members?

It doesn’t address: - the issue of developers getting stuck on too much metawork - capacity issues - the need to specialize

a proposal for the cells and their capacity issues haven’t been prepared yet. we need something ready to start resolving some of the issues.

For the capacity issue, what will solve it is to find more confirmed new core members. This is something we have already worked on addressing (cf threads from previous months on this), and it has allowed to increase the number of newcomers, but it takes time to confirm everyone. In this iteration, the step to improve further is the replacement of the trial period by a trial project, to accelerate the evaluation of newcomers. For metawork and need to specialize, merging roles helps reducing the duplication of metawork from similar roles (and thus the overall volume of metawork), and allows to focus on fewer types of roles (thus reducing context switching). It might not yet fully solve everything, but it goes in that direction?

Cell supporter

There needs to be more clarity on the management roles delegation, who will take on these roles, and for how long, how backups and rotating the roles work etc. need more discussion.

@tikr Can I let you answer this?

Taking off project management burdens from developers

Centralizing client communication, such as requested by ASU.

There is some distinction between a cell supporter and a project/client manager, and that needs to be disambiguated.

+1 – it would be worth clarifying this, there has been some confusion about this on the PR too. See [SE-4841] Define cell supporter role (!358) · Merge requests · opencraft / documentation / public · GitLab :

There is project management we do as part of roles (like the epic planning manager for example), and there is project management to do on individual epics/projects for a client. Let’s call the first one “cell project management” and the second one “technical project management”?

For technical project management, for now we keep it as is – it’s part of the duties of epic management, which itself isn’t something we are going to delegate to others. It remains a technical role meant to be taken by core team members of a given cell.

For cell project management, the cell supporter will be able take on full cell roles like epic planning or recruitment for now (so not individual epics project management).

project management shouldn’t be mixed with the cell supporter also im not sure if one cell supporter, for three cells, will be enough

Whether it will be enough is an open question yes – see the discussion at [SE-4841] Define cell supporter role (!358) · Merge requests · opencraft / documentation / public · GitLab . Also note that the idea is to help with relieving pressure from cell roles, not take them all on. Here too, the long term solution is to recover capacity, and have more people able & willing to take on roles - a role one person doesn’t like (or doesn’t like anymore) might be one someone else will like. But yes, we’ll need to check that, between those two solutions, at the end we’re all happy with our respective roles.

I expected the manager role to be a cell role.

That’s because it’s specifically not a manager role, which would have broken the self-management principles – and just established a standard middle-management layer. Cf the previous discussions about this in the recent threads.

It’s a single point of failure to rely on Tim always being willing to do this role, and no one else wanting too. If no one else is willing to do this role or a backup for Tim, we need to consider hiring specialist administrator people to take the load off of him.

What if nobody wants to pick up that role? Most of the team members do not want (other) roles.

who’s going to take all the roles?

The single point of failure aspect is true, but that’s also the case with many single-person roles within OpenCraft - like @gabriel @fox @braden or me. When one of those people would get tired of their role, we need to either rethink things, or hire/find a new person for it. That’s something that would improve with scale, but I’m not sure we can do much about this now.

General comments

The ability to focus is not being handled by the issues listed in this form, but that is to be addressed by the upcoming Project-based Cells PR.

As mentioned above, there are measures that should help with focus/context swtching and metawork. But yes, project-based cells will be an interesting experiment for this – though we’ll see how it handles being a smaller cell.

This is a personal opinion but I feel we should try experimenting with a combination of sync and async combination for sprint planning. What we have right now does work but at a certain point, the sprint planning does become very sync with MM chats. I think a bit of async planning and then combined with a single end-of-sprint optional meeting might be a very subtle balance.

This would either exclude people who are on the wrong timezone, or make us go back to the issues of synchronous meetings for some timezones. The end of sprint planning switching to mattermost is definitely an issue though - it should be taken as a symptom of something having gone wrong in the planning or the async process though, and used as a basis for iterating over the async process. We’re breaking new grounds here, so we have more plaster to clean up than with processes everyone already uses like synchronous sprint planning meetings, they had more time to become refined.

I’m happy with the current measures and can’t wait to see cell supporter & sprint planning simplification in action.

I’d like to see how the proposed solutions pan out.

I don’t have much experience in management roles. After reading through the discussion, survey, and MRs to address issues, I am hopeful that these will resolve the issues we are having right now.4 days ago

:slight_smile:

Having someone actively and recurringly fixing the day-to-day problems identified by team members. This may be related to the developer advocacy role being suggested.

Yup, exactly – see [SE-4841] Define cell supporter role (!358) · Merge requests · opencraft / documentation / public · GitLab for this.

I think we’re hitting many of the major points from the team survey with the initiatives that we started in Sprint 256; they are definitely a good starting point. One important point that hasn’t been covered yet is per-person epic limits (and how to get better at sticking to those). We already have MNG-2437 for this, so it’s mainly a matter of getting that task scheduled.

True – @braden which sprint do you think you’ll be able to take this on?

I still think cell sizes should be better defined, and increased.

The handbook does define their size, but there have been discussions about increasing the size. Here, an experimentation would be a good next step, as we also know that larger cells have their own drawbacks. The potential merge of Serenity and Falcon could be one such experiment? @jill Given the results on the survey, are you going to proceed with the merge?

Have we made sure that every individual doing their cell and epic management roles actually wants to do them?

For the cell management roles, if there is one you don’t like and want to pass on, now is the time to say it! And if nobody in your cell wants or can take it, then you can ask @tikr if he can (the priority and preference remains with the cell members).

For epic management, cf above - for now it remains one of the core team member duties.

Some questions on the PRs are still opened / not resolved. We should resolve them, but I love the direction those conversations are going.

+1 – on the individual PRs/tickets I’ve asked the authors to merge everything we have agreed on, to move forward quickly with the bulk of the changes, and schedule follow-up tickets for outstanding points.

We haven’t been able to make much progress on the accelerated epics for 2021, and I think we need a more clear solution for that.

Here the solution seem clear to me – we need to recover capacity. We haven’t been able to make much progress on those, because people keep being pulled out of these epics to match capacity requirements on client projects.

5 Likes

Yes, that does remain one of the responsibilities of the sprint planning manager.

It’s implicit, but the sprint planning manager should monitor the checklists to ensure that all cell members are doing their role in planning the sprint. It helps identify where problems are happening in the sprint planning process of a specific cell.

After all, the sprint planning manager’s role isn’t to do the sprint planning, but to ensure that members are able to fulfill their responsibilities towards planning their next sprint.

It’s also easy to do, a sprint planning manager can setup their own Dashboard using Tutorial: Utilizing Dashboards for Sprint Planning Checklists in Monday.com.

I’ve, personally, created three to monitor the use of the checklists in all cells:

I’ll try to be clear in my next announcement about the sprint planning checklist changes regarding the role of that ticket.

Yes! I created a reminder for creating a ticket to look into these elements next sprint :+1:

I’m not sure, as well, to be honest.

The only roles that remain are: Sprint Planning Manager, Sprint Manager, Recruitment Manager, and DevOps Specialist.

I think we can reduce them to 3 roles per cell by merging Sprint Planning Manager and Sprint Manager, if members are interested in further reducing the number of roles…

That’s a pretty low number of roles in comparison to the number of members in a single cell.

The forum mod and the OSPR Liaison will both be removed since they will be included in the Developer Advocate role. They already are included, now, under the Community Liaison role.

I’ll reach out on those tickets to ask them to re-assign them to me starting next sprint.

I raised this point, so we can dedicate major effort towards that proposal. Based on @adolfo’s latest sprint update, that’s the case. So I am no longer worried about that point, because @adolfo will be focused on that proposal during this sprint, I suppose.

During the meantime, finding more newcomers and the trial project will definitely help in that direction.

So please disregard my comment, since it’s no longer applicable based on the latest updates. Apologies for that inconvenience by the way!

The long term solution definitely will help, I see a lot of effort done towards recovering capacity, and huge kudos to the team for that.

I understand that the cell supporter wouldn’t be picking up all the work, I’m just slightly concerned that the cell supporter might face burn-out and/or not all members who want to pass-on their cell roles will have the chance to.

If it’s alright, would it be possible to have all members, including non-cell ones, submit the bi-weekly-checkup? It would help alleviate those concerns because it would allow us to identify any slight burn-out.

2 Likes

I’m planning to look at it this week

1 Like

@nizar @braden Thanks! Perfect. :+1:

Definitely, that’s a good idea - we need to take care of everyone in the team, regardless of their roles.

2 Likes

Sure :slight_smile:

In a nutshell, the idea is to have one cell supporter for now, while we test the concept, and to add more in the future (e.g. up to one per cell) if the concept proves to be helpful.

I am planning to take the cell supporter role, and to work on transitioning into it over the course of next sprint (i.e., Sprint 258).

The epic planning and sustainability role for Serenity will be delegated to me from the beginning. I’m also planning to help Falcon with the same role (from Sprint 259 on).

There are no plans for other role changes at the moment. If I end up with capacity for helping with additional roles, I’ll post another update on the forum. (As laid out in more detail here, the idea is to leave some room for working on process improvements and cross-cell planning, as opposed to spending all available hours on delegated roles.)

In terms of rotating roles, for now the plan is to provide an opportunity to do this once per quarter.

There will be no backup for the cell supporter in the short term, and we will keep the current approach of having backups for the cell management roles within cells.

Just to mention it here as well, I removed the items about project management from the cell supporter role definition and added some text to clarify the distinction between project management and cell support prior to merging public#358. See this comment for details.

2 Likes

Small update regarding this.

Due to still being responsible for client work, I won’t be able to schedule two tickets to look into those two elements. In the meantime, I can only create a single ticket.

In order to help address the more immediate issue, I created Identify unwanted metawork and new potential assignees.

The goal behind that ticket is to create a form to collect data regarding unwanted cell roles and create a satisfaction metric in comparison to their current responsibilities. Once the data is collected, the Cell Supporter will propose different swappings and coordinate between each cell’s members.

This will give us a “breather” by making the members more comfortable with their current responsibilities. It will also give me a chance to finish up the client work I’m responsible for and transition slowly into the DA role.

I’ll need @tikr’s review on the form creation ticket, since the future tickets will most likely be split efforts between us both.

Regarding the epic metawork, I’m still not 100% sure of what to do. I have some ideas like creating a dedicated ticket or asking epic owners to add a specific substring to identify metawork timelogs. I’m sure both have downsides, so I need to look into it more. But I don’t have the capacity at the moment.

3 Likes

Thank you so much @tikr ! It will be great to have your help here from my personal perspective, but it will also assist with the large (and likely shared) project work coming up for our teams.

:+1: to this too. The process changes are already feeling much less onerous, but I’m sure we can do better if we keep working on it.

Huge thanks to you, @nizar and @braden and everyone else for these improvements!

5 Likes