Secure uses a workflow based on the Product Development Flow with some additions that are under experiment or specific to this sub-department.
Specific deadlines of this workflow are defined in the Product Development Timeline and should be followed unless specified explicitely.
To maximize our velocity and meet our deliverables, we also follow an engineering refinement process for all issues, before actually scheduling them into a given milestone.
The Product Development Flow implies the existence of queues identified with
workflow:: labels and depending on your role in the group, you may be involved in different queues.
|ready for development||X||X||X|
The Product Development Flow guideline explains each step in detail, but here are some clarifications/additions for Secure.
~frontendlabels to the issue as early as possible.
workflow::designissues collaborate with PM, UX and EM to provide a practical solution to the problem.
sub-issue. See breakdown vs refinement.
secure:refinement-frontendto distinguish which teams need to refine it.
sub-issue. See breakdown vs refinement.
workflow::ready for development
We leverage issue boards and relevant filters to allow each team member to clearly see what they should focus on depending on their role.
Here is a (slightly outdated) video about how to work with issue boards as an Engineer: https://www.youtube.com/watch?v=7CdVG9mAE30
Here is a (slightly outdated) video about how to work with issue boards as an Engineering Manager: https://www.youtube.com/watch?v=YjPmsXkbxI0
We value asynchronous communication but it is also highly recommended to have a weekly sync meeting between PM, UX, and EM to review these queues:
planning breakdown, and
scheduling. This ensures we keep moving issues forward and constantly have items to work on in each step of the process.
While these two steps both imply to break things down, and sometimes are tightly coupled, they aim at different purposes.
The goal of Planning breakdown is to create implementation issues that represent deliverable chunks of the solution from a user perspective. There can be some exceptions like having a technical pre-requisite, but the main purpose is to split big features into smaller independent bits. If an implementation issue needs both Frontend and Backend work to be delivered, it still needs to stay as a unique issue so that anyone can track the feature itself, instead of looking to several issues to know when the work planned for that iteration is completed.
Then, as part of the refinement process, engineers can break down an implementation issue into technical sub-issues by following the sub-issues convention. For the above use case, this could mean one sub-issue for Frontend and one sub-issue for Backend but this could also end up into several sub-issues.
Here is an example of these two steps applied to a feature:
milestonefilter with the current milestone +1 (the current milestone is already released).
See our Issue Refinement page.
To avoid change fatigue, Secure team members stick to the same workflow for a quarter (aligned with Fiscal Year Quarters). Updates such as grammatical fixes, typos, and clarifications are welcome at any time but substantive changes must be submitted to the draft of the next version and will only be rolled out when the next quarter starts.
To make updates such as grammatical fixes and typos, you can create an MR and have it reviewed and merged by anyone with merge rights.
For updates that affect the overall phases by modifying core definitions, workflow labels or other cross-functionally utilized processes, you can create an MR to the the draft of the next version and assign it to the relevant impacted counterparts (Engineering, roduct, UX, QA, etc.).
All team members are encouraged to expirement improvements to the existing workflow. Trying things out is often the best way to see the benefit or downside of a suggested change. To make sure this is clearly understood by all counterparts who may be affected by this temporary change, it is very welcome that the experiment is listed here and clearly communicated first.