BB-10314 processes revamp poll

Discussions - Public
1

As part of the processes revamp discovery, we’ve identified several topics to address and proposed solutions. To get an overview of the general attitude towards the proposals and to identify controversial ones requiring further discussion, I’ve set up a series of polls.

Please consider each summary of the issue and proposed solutions, and respond whether you think we should go ahead with the proposed solutions in general. For more details, please refer to the discovery. Feel free to respond to this thread or comment on the discovery doc if you wish to expand on your answer.

  • Deadline: please respond by the end of the year. :slight_smile:
  • Time logging: please log time to your subtask of BB-10314.

1. Improve ping response

We have a strong policy of a 24h workday response time to pings. Sometimes pings have delayed responses or are missed. We propose:

  • Document methods of reducing noise from too many notifications.
  • Discuss Gmail filter effectiveness.
  • Document guidelines for effective pinging (eg. reducing pings, directly mentioning people, etc.).
  • Re-assert expectations for quick responses to pings.
  • Yes
  • No
  • Undecided
0 voters

2. Restructure the handbook

The handbook has areas that are difficult to read due to being very long or difficult to navigate. We propose:

  • Audit the content, decide what we want to keep, remove, need to add.
  • Work on a structure from the ground up (improving navigation, better categorisation, grouping content better, reducing verbosity, considering Diataxis principles, etc.).
  • Yes
  • No
  • Undecided
0 voters

3. Address worklog upload delays

Worklogs must be uploaded promptly (policy is within 24h), to help with planning and budgeting. Many members use third party tools to record time, then sync to Jira/Tempo later, which is fine. However there have been recurring issues with worklogs not uploaded promptly. We propose:

  • Schedule a ticket for each member having issues syncing worklogs, to give them time to address blockers, improve their automation, etc.
  • Improve documentation around worklog syncing automation tools, including supporting setup for non-technical members.
  • Test and improve the syncing automation tools.
  • Yes
  • No
  • Undecided
0 voters

4. Reinstate retrospectives

Retrospectives are important, but have fallen by the wayside. We propose:

  • Gathering retrospective comments in midsprint and end of sprint updates.
  • Include prompts somewhere to help think about aspects to be retrospective about.
  • Create a lightweight process for regularly discussing and addressing retrospective comments.
  • Update all related documentation to be consistent with the new process.
  • Yes
  • No
  • Undecided
0 voters

5. Rethink estimation sessions

Estimation sessions have low attendance and possible aren’t useful any more anyway. We propose:

  • Drop the estimation sessions.
  • Define who is responsible for estimating and reviewing estimates for story points (probably will fall to reporters, epic owners, assignees, etc.).
  • Add a point to the sprint process for reminding to browse tickets on the backlog to comment on, provide more context, or take.
  • Schedule follow-up forum discussions: do we find story points useful? Is there anything we’re missing by not having estimation sessions?
  • Yes
  • No
  • Undecided
0 voters

6. Improve task standards in Jira

Task standards are important for ensuring tickets have context for everyone who needs them (assignee, reviewer, future assignees, future debugging, etc.). However, some standards are outdated, and sometimes the standards aren’t followed. We propose:

  • Update the jira task and epic description templates, removing outdated fields.
  • Make it clear that all tickets should uphold a standard.
  • Define who is responsible for maintaining ticket descriptions (probably reporter, assignee, and reviewer, with a check-in by the sprint/planning manager).
  • Yes
  • No
  • Undecided
0 voters

7. Improve PR standards

PR standards are important for context, but sometimes they are not met. Also, the template we use is not flexible for all situations. We propose:

  • Update the handbook’s pull requests info page.
  • Make our own standard template and guidelines for PR descriptions (including for cases where we must use an upstream template). Mostly clarifying, not changing content so much.
  • Add responsibility to the reviewer to review PR descriptions too.
  • Yes
  • No
  • Undecided
0 voters

8. Improve PR review standards

Likewise for reviews, our review template is outdated. We propose:

  • Add checklist item for reviewing pull request description and title.
  • Add checklist item for reviewing the commit message.
  • Update the code drift checklist item.
  • Yes
  • No
  • Undecided
0 voters

9. Improve sprint updates attendance

Sprint updates are often late/missed, or missing the video component. We propose:

  • Drop requirement for videos in end of sprint updates.
  • Add a prompt somewhere for reminding members what to include in updates.
  • Implement reminders before any deadlines for submitting updates.
  • Yes
  • No
  • Undecided
0 voters

10. Increase face contact

We don’t have much opportunity for interactive with colleagues apart from text. We propose:

  • Provide flexibility for scheduling more social chats to cover more timezones. Use calendar events rsvp more, get consensus on more regular slots.
  • Schedule a roster of somekind for different people to make a “show and tell” video each week (especially since we’re planning to drop videos in sprint updates).
  • Yes
  • No
  • Undecided
0 voters

11. Revise technical handbook sections

NOTE: unsure if this will be part of this epic, or part of STAR-3886.

Some sections of the handbook need to be used by everyone, but the tasks are explained in a very technical manner, making it less accessible to non-technical members. We propose:

  • Identify processes in the handbook, private docs, listaflow checklists, etc. that are applicable to everyone but using technical language.
  • Update the language and steps in these processes to be more accessible to a wider audience, and have them reviewed by non-technical members.
  • Consider training for non-technical members in common tools like Git, Gitlab, etc.
  • Yes
  • No
  • Undecided
0 voters

12. Increase sprint checklist response rate

NOTE: this topic may require more discussion, as it appears that members use the checklist in different ways; it’s a complex topic.

Timely response rate for the sprint checklist is not bad, but there are always some late. There may be primary blockers (relating to listaflow) or secondary blockers (relating to the tasks to check off). We propose:

  • Reduce the number and verbosity of checklist items.
  • Add notifications for reminders.
  • Make it clear in Listaflow which role a checklist item is for.
  • Make the checklist items expanded by default where applicable.
  • Review the checklist items to ensure they line up with the handbook.
  • Yes
  • No
  • Undecided
0 voters

13. Improve upstream PR review tracking

NOTE: this is already approved work, that we’re simply moving to this epic.

How can we make sure that comments from upstream reviewers don’t go unanswered for extended periods of time? These are for PRs associated with tickets in external review / blocker. We propose:

  • Refine OSPR Liaison role, updating the handbook. Reassign the role.
  • Obsolete parts of OSPR Liaison role identified and removed.
  • Clarify how often external review/blocker tickets and long external review tickets should be checked by the sprint/planning manager.
  • Yes
  • No
  • Undecided
0 voters

14. Revise community relations roles

NOTE: this is already approved work, that we’re simply moving to this epic.

Volume of hours logged against Community Relations account is quite low (23h total in 2023). Maybe even too low to justify the additional overhead of regular epic management and budget tracking. We propose:

  • Review and refine Community Liaison role.
  • Come up with a budget for the two community relations roles.
  • Decided if we should resume regular epic management for FAL-3511 so that we can track budget usage better.
  • Create a new ticket with a different account for any existing ticket using the Community Relations account and is out of scope for the Community Relations epic.
  • Yes
  • No
  • Undecided
0 voters

15. Reduce sprint planning friction

This is a collection of things relating to quality of life for everyone’s sprint planning. We propose:

  • For any messages from Sprint Bot, linkify Jira ticket IDs, and cleanly format any structure data.
  • Document semantics of our Jira labels and “Fix Version/s”.
  • Consider improving quality and timeliness of epic updates. This will be further discussion.
  • Improve the vacation checklist for less friction and to encourage its use more. discuss.
  • Disable Crafty’s behaviour of moving tickets to stretch goals where it detects an injection. Also consider updating the rules around injections, as they may be too strict.
  • Yes
  • No
  • Undecided
0 voters

16. Define blocked/unblocked states

There can be confusion and extra back and forth around determining if a ticket has budget available, is ready to be worked on, or why it’s in stretch goals, blocked, or backlog. We propose:

  • Clarify and document how to mark tickets and blocked/unblocked on budget, blocked on external things, ready/not-ready to work on.
  • Rename the “ready to pull in” version (label) to clarify intent better. Discuss with the team whether it’s effective, and perhaps remove it altogether.
  • Clarify the purpose of the stretch goals sprint.
  • Yes
  • No
  • Undecided
0 voters

17. Maintain issues/PRs/repos backlogs

We have many repositories across Gitlab and Github, with many open issues and PRs. These can get outdated or missed. We propose:

  • Expand an existing role to include periodic processing of old repositories, backlog of pull requests, and backlog of issues, checking for corresponding jira tickets for issues.
  • Schedule a once-off large task to tidy the backlogs, before starting the more regular small process to keep it tidy.
  • Yes
  • No
  • Undecided
0 voters

Thank you for making it this far, your feedback is valuable! :slight_smile:

6 Likes
2

I’m voting “Undecided” because I think the proposed changes mostly focus on how to collect retrospective comments, but I think that a much larger emphasis should be put on how the comments are processed and addressed. We had many ways to collect the feedback/comments, and we still do (e.g. end of sprint updates where people share how their sprint went; a box in the sprint checklist where people can enter comments on how their sprint went; in the past we had a semi-anonymous form; we used to have retrospective meetings). I think the main reason those failed is because the pain points went unaddressed for a long time. There could be many reasons to why they weren’t addressed, for example, may be they were lacking visibility, or because there were no assignees for this, or may be because cell members didn’t feel like they had the power or required energy to make the change. Either way, I think it should be the focus of the change.

2 Likes
3

I think that we should make tickets easier to create. I notice that I procrastinate creating tickets and will avoid doing it if I can because of having to fill in the ticket description. For example the “Story” part of the template doesn’t make sense in most of the tickets that I’m creating, but it takes a lot of effort to phrase it in a way that fits into that template, while providing little value.

2 Likes
4

Yes to this.

No to the rest.

1 Like
5

Yes to these 3, no to the rest.

6

Thank you for putting in the effort into the discovery and the poll :heart:

1 Like
7

+1 on this. Not every ticket needs a bunch of standard fields filled out. Some of my own tickets are as simple as “Review this OSPR: [link]” for example.

The important thing is that the person creating the ticket puts in all the info that the people implementing and reviewing the ticket will need, and a template/standard can be helpful for that but “tickets” vary a lot depending on the project.

For example, looking at the current standard, “Relevant repositories” is usually better to set at the epic level, not on every single ticket, and “Review timeline” is something that the assignee is going to be better at estimating than the person who creates the ticket. And on open source projects, all of the other information should be in a public ticket on GitHub/Gitlab, not our private Jira.

That said, there is definitely a temptation to under-specify tickets, which creates problems if someone else needs to take over the ticket, or (which happens all the time), someone like the CTO comes along weeks later and tries to figure out what the purpose of the ticket was and why we did it a certain way; the extra context is super helpful there and sometimes unfortunately missing.

What I think we need is a somewhat more practical template and it should be built into our issue tracker (e.g. Jira), just like PR templates are pre-filled on GitHub when you open a PR or issue, and you can generally fill them out but also delete irrelevant parts as needed.

1 Like
8

From a BizDev perspective, it would be amazing to have some automation or syncing. It’s probably more line with replacing the CRM, but since I’m the only one who uses it, it might be better to have a more generally accessible database of clients and leads. There’s no eyes on the CRM, so any updates are really only useful if someone was to take over the role in the future, it doesn’t actually facilitate the role day to day since nobody else is looking at it and it’s not synced to Gmail or Zoom. Manually adding a task for every single lead isn’t realistic, but I feel like it would be easier to keep everything in one place at this point. Currently I only add tasks for leads with good potential to move forward, but I think any team member should easily be able to type in a client/lead and see the status, but they’d only be aware of it if a task is created of course.

There are more leads in theory I’d like to create a task for but the admin of managing them into the sprints becomes too crazy. I have a system of managing follow up within Gmail using tasks and email filters, but due to the volume alone, it’s not practical to manually update tasks for every lead every time we check in. Ideally, I’d have a new task for every single lead, but the work alone creating and managing these tasks would take longer than the time spent reaching out to the lead.

From a relative newcomers point of view, I do find it difficult to quickly see/understand the status of our current clients and projects. I’m not sure I have anything better to suggest at the moment, but I certainly have gone down the rabbit hole of scrolling through a Jira comment history and still be left uncertain, as I’m sure others have. I think as things currently stand it’s quite difficult to keep track of new projects. Especially with new projects for existing clients as well. I’ve mostly taken on the role of handling new business for existing clients but we really need a lot more time invested here, and the role is quite different from client ownership and project management when they need proposals for new work.

This is going on my wishlist but I’d love to be able to link/associate an email thread to a task or client. At this point, manually adding a lead to the CRM and the meeting notes and then also copying it to the task is more just an admin task in case someone else is reviewing it down the line. I’m guilty of not posting updates regularly on all of the lead tasks, because it’s basically just copying the check in from the client from the email to the task and becomes difficult as the numbers grow.

If someone is looking for an update with what’s going on with the client, in my mind, it’s easiest just to pull the email thread. If you have 3-4 leads, it’s easy enough to post updates to the tasks, but when you have 20-30 ongoing, posting regular updates eats more time than the actual client work. Again, in an ideal world I’d have tasks for every single lead that comes in but it’s not practical to manage.

I’m not sure the Jira workflows make as much sense from a purely BizDev perspective. It’s likely been adapted to make it work, but as our lead volume increases, it’s not totally sustainable in my mind. Generally speaking, probably 10-20 minutes is spent on a general client reply depending on the context, but there’s probably 20 minutes of admin if there’s a task involved, CRM update and Salesforce if there’s a referral. From a cost perspective, it would save a lot of time to just be able to reply to the client without having to update multiple records, i.e. the emails or meetings sync to the task or record. If there’s a meeting with a client or lead, the notes or the recording should be automatically linked to the task IMO.

Just sharing my thoughts in case it’s useful at all to these discussions.

3 Likes
10

These sound good, but please keep the retrospective optional.

1 Like
11

@jordan While it would still be a manual step at the moment, would it be helpful to grab the link to the first message of an email thread from the mailing list and add a weblink to the lead ticket that it belongs to?

Unless there were multiple different email threads for a single lead, you’d only need to do this once, at the start of the conversation. And everyone that wanted to review the conversation would be able to find it easily :slightly_smiling_face:

1 Like
12

I’m wondering, aren’t people doing this anyway when looking for work to pick up in the following sprint?

Either way, since we’re generally looking to simplify processes, and this seems to be adding to the number of things to complete each sprint, it isn’t something I would mandate.

13

I voted yes on this poll, but I’m not sure about this particular suggestion. Including items for mid and end-of-sprint updates in the Listaflow sprint checklist seems sufficient to me.

14

Yes to scheduling more social chats to cover more timezones.

No to a fixed roster or cadence for “show and tell” videos, for reasons mentioned here and here.

15

I voted yes on this poll but wanted to mention that I’m agnostic regarding notifications for reminders. I have my own system for keeping track of what needs to get done on which day of the sprint, so I’d support whatever the majority thinks would be most useful in terms of adding notifications or not.

16

I voted undecided here because I’m not opposed to it but I also don’t think it’s strictly needed. Priority-wise, it ranks much lower than the remaining items in my mind.

17

Besides dropping the current estimation sessions, could we also take the time to try other existing tools? Eg:

…or even something Saas/proprietary, it’s more to see if there are ways to do estimation sessions that are more useful, or not. We only know the crappy Jira estimation tool’s way of doing it, from 10 years ago.

Agreed, but not sure how the proposed items would improve this?

I’m in favor of this in general, but it would be good to let the people affected by this decision to take it, and direct the approach here. So I would be focusing on the votes of non-technical people for this question, and make sure we have them all. Objections from anyone are worth considering, but we should make sure the approach is the one that would be preferred by those it is intended for.

Here, not sure the measures suggested will be enough, and it does sound like there are discussions to complete on this. +1 to schedule a discussion as follow-up here.

@braden Maybe besides having a global template, each project could also redefine its own template, if the “standard” one doesn’t work well for the project? If we put those in a repository, this would give a way for anyone in the team to iterate over it by opening PRs, and for everyone involved or interested in the project to review changes to the template?

Automation-wise, the step to update it in Jira or its successor could eventually be automated, or done manually at first - but if the canonical template documents are in a repo, it makes it easier to understand how to contribute to it, and to bring up small changes progressively when we notice them.

@jordan Given the nature of working leads, I would expect that to be one of the primary features of a CRM: to help you track and organize discussions with leads - maybe it could be worth looking for a better CRM, or maybe to integrate better what is currently in the CRM with our task tracker & mailing-list software? It could definitely be worth a discovery on this, in its own epic that you could take on, @jordan , since you are the main user.

I think we have tried not setting a fixed roster for shows & tells - actually without the fixed roster, the show & tell videos are already in place, it’s just that nobody does them.

I think if we are going to drop the requirement to do a video every sprint, it’s fair to keep a requirement to do a video every 2-3 months. It doesn’t need to be longer videos or well edited – worst case you just give an update about what your last 2-3 months were about like you do now every sprint, or quickly show a piece of software that you have worked on. In 2-3 months it shouldn’t be too hard to find something?

As for keeping keep track of this, we can reuse what we already have to track firefighting rosters.

1 Like
18

I’ve done a few, and I would love to do another, but usually what stops me is that there is no explicit budget for something like this. The learning budget is there for this but I think if we leave scope for a video every 2 sprints and someone can just choose to take that slot (or not) it would be using an allocated budget rather than negotiating a budget from an unknown place.

Retrospectives are important; however, I feel that forced retrospectives have less value. As @maxim mentioned, if the issues aren’t something that will or can be fixed, it’s just a space for people to vent. I think that is valuable too, but maybe not as productive. We can add scope for a personal retrospective to the sprint checklist, and these can be posted to the retrospective thread and action items can be created from there.

I agree with @maxim that tickets should be easy to create.
Currently there are are too many sources of hidden tasks, that email you got and have to respond to? It’s a task, just not in Jira, same with any ping, or sometimes a personal action item. If tasks and action items were lightweight in Jira I’d put everything there an have personal action items in Jira. This is something I liked about Huly, that you could add action items to tasks that could be personal but linked to the task.
I think the main point of the task description that we can often fail at (I definitely do) is that it has enough info for the me of today, and the reviewer, but not for the me of the future and someone else in the future trying to understand the ticket. I think more valuable than estimation would be for someone to quickly look through tickets they didn’t create and comment if there is something they don’t understand in the ticket.

I’m not sure it’s outdated? Is there anything that needs to be removed? @antoviaque I think adding a checklist item like this will remind us to check these things (especially commit messages which can often be ignored).

I personally think that more important than the PR description etc. is the commit description. That is the data that is actually part of git and survives whether you have it on Github, Gitlab or your local computer. We should improve our commit messages to have all if not more context than the PR description. I often aim to enhance the commit message and just use that as the description.

I think a week would be too quick, but can definitely have a slot + budget for a video every 1 or 2 sprints so that anyone who has something to share can pick the closest slot, schedule their ticket and know that they have the budget ready to go.

I guess I’m the one to propose Listaflow for everything, but we could move sprint updates to a more structured format there. Having sections for the kinds of things you should include in the update will automatially structure the responses people give. This can be combined with the current checklist, but for each sprint we can just post everyone’s responses in the sprint update section automatially.

I’d personally would like to get a reminder for these tasks. I personally use todoist, and even began to create a small tool to do 2-way sync with it, but the lack of due dates on individual items in the checklist made me pause and then not go back. I now just have a reminder to check the list.

Thanks @samual for taking on this huge task! Hoping to see good stuff come out of this.

19

Video Updates
I really enjoy watching the videos in the end of sprint updates. I feel the videos are what keeps the updates personal and interesting. Without the videos the updates (the mid-sprint ones for example) simply looks like a list of ticket numbers and descriptions which we might as well automate.

I would vote against dropping videos completely, but I like the idea of posting video updates perhaps once in 2-3 sprints showing the most interesting things that we worked on since last update.

End of sprint updates schedule
The last Moday of the sprint is often quite hectic/stressful and posting sprint updates at the end of a long day is easy to miss. Changing the schedule for posting the updates to first day (Tuesday) of the next sprint would, I think, would be very helpful in ensuring timely sprint updates.

Mid sprint updates
Lastly, I haven’t found the mid sprint updates to be very useful. We should perhaps consider eliminating that and just sticking to end-of-sprint updates only ?

1 Like
20

Thanks everyone for your responses! I’m sifting through everything now (poll responses, replies, comments on the doc) and this will drive the final proposal. Stay tuned!

If you have more feedback from this point, please ping me so it’s not lost. :slight_smile:

21

Update: I’ve prepared a spreadsheet based on the poll results where I’ve added the hours estimate, whether to include the item in the first iteration of development (based on how controversial it was, whether further discussion is needed, and importance), and some notes.

Please take a look if you’re interested and let me know if there are any issues. :slight_smile:

cc @tikr @pooja

1 Like