Development team workflow
What is Kanban?
Kanban is a visual workflow management method that helps teams visualize their work, maximize efficiency, and improve continuously. It revolves around the use of a Kanban board, which is a simple yet powerful tool for tracking the progress of tasks.
Key Components of Kanban
Kanban Board: The central element of the Kanban system. It's typically divided into columns that represent different stages of the workflow, such as "To Do," "In Progress," and "Done."
Cards: These represent individual tasks or work items. Each card moves across the board from one column to another as it progresses through the workflow.
Columns: These define the stages of the workflow. The most common columns are "To Do," "In Progress," and "Done," but they can be customized to fit your specific process.
WIP Limits (Work In Progress Limits): These are set to restrict the number of tasks in progress at any stage, ensuring that the team doesn't take on too much work at once and maintains focus.
How Kanban Works
Visualize the Workflow: Start by mapping out your entire process on a Kanban board. This gives everyone a clear view of how tasks move through the workflow and highlights any bottlenecks.
Limit Work in Progress (WIP): By setting WIP limits, you help the team focus on completing tasks before taking on new ones. This reduces multitasking and increases efficiency.
Manage Flow: Monitor the progress of tasks as they move through the workflow. Look for any delays or obstacles and address them promptly to maintain a steady flow.
Continuous Improvement: Regularly review the process and make adjustments as needed. Kanban encourages a culture of continuous improvement, where teams consistently look for ways to enhance their workflow and productivity.
Benefits of Kanban
Flexibility: Kanban is highly adaptable and can be applied to any type of work.
Improved Efficiency: By visualizing work and limiting WIP, teams can complete tasks faster and with higher quality.
Better Collaboration: The visual nature of Kanban promotes transparency and communication within the team.
Continuous Improvement: The methodology encourages regular assessment and improvement of the workflow
Information on a Card
Steps in the Procedure
We will guide you through the key steps in the Kanban workflow necessary for the Synck development process, including:
What is the step?
What should be happening?
What should you be doing?
To Do
This step indicates that the task or card is ready to enter the development process. Tasks should be assigned and prioritized by the Project Manager (PM) or Tech Lead.
Once you are assigned a task, here’s what you should do:
Break down the task into smaller subtasks if necessary for better management, using a checklist.
Identify potential technical challenges in advance. If there is something you are unsure about, ask your Tech Lead for guidance.
Estimate story points for the task to understand the expected workload you need to handle.
In Progress
This step indicates that you have started working on the coding phase. You should create your own branch following Synck's standard procedures and begin your development process, adhering to the checklist set up in the previous step.
The most important aspect to keep in mind is that your coding must adhere to coding standards. Continuously check your current code to ensure it meets these standards.
If it doesn't, make the necessary adjustments immediately.
Do not wait until the end to implement the coding standards, as this will be time-consuming and may introduce errors into your code.
Waiting to Test
After completing the development work, the task moves into the Testing phase, indicating that it's ready for testing in the staging environment. You should configure your gitlab.yaml file to deploy your staging environment and test your feature on the Synck Development Branch to ensure that basic functionality works as it did on your local machine. Refer to this guide for detailed instructions.
Skipping testing in the staging environment will only delay the inevitable, as you will have to fix these issues eventually. Therefore, it’s crucial to ensure everything functions correctly in this environment before handing the task over to the testers. Testers will thoroughly check the work to ensure it meets the requirements, and they will not overlook any issues.
When you move the card to this step, make sure to:
Deploy to staging correctly and note the staging environment details on your card.
Manually test the feature yourself.
Notify the testing team or QA personnel about the completion of the task and its readiness for testing via Trello or Slack.
Testing
This step involves rigorous testing of the developed code to ensure it functions correctly and meets the specified requirements. It includes various types of testing, such as unit testing, integration testing, and user acceptance testing (UAT).
In this step, testers will manually test your features on the staging environment. Here’s what you should be doing:
Collaborate with the testing team to ensure thorough testing of your code.
Address any bugs or issues identified during testing promptly. Do not delay fixing bugs; if something can be fixed quickly, do it immediately.
Make necessary adjustments based on feedback from the testing team. The testers follow the product closely and see things from the user’s perspective, so their feedback is valuable. If you find any feedback improper, discuss it with the Business Analyst (BA) or Project Manager (PM) for a final decision.
Waiting to Review
After addressing most or all issues found during testing, mark the task as "Waiting to Review." Notify the code reviewer or team lead that the task is complete and ready for review.
Before submitting for code review, create a Merge Request (MR) for your feature and note it on the feature card so that the reviewer can quickly identify the changes you made during development.
Additionally, manually check your code against any previous code review comments. If you've committed any issues previously mentioned, update your code before the next submission.
Reviewing
In this step, your code is reviewed by peers or senior developers to ensure its quality, maintainability, and alignment with project standards. This process provides an opportunity for constructive feedback and knowledge sharing among team members.
Here’s what you should do during this step:
Actively participate in code reviews, both as a reviewer and as the one being reviewed.
Provide constructive feedback and suggestions for improvement.
Incorporate feedback from code reviews into your codebase promptly. Address feedback as quickly as you would fix bugs.
Merge your code from the master branch to ensure everything is up-to-date and ready for merging.
QA/QC
Quality assurance (QA) and quality control (QC) are performed in this step to verify that the software meets desired quality standards and functions as intended. This involves final checks before deployment to ensure the product is ready for release.
At this stage, feedback can come from various stakeholders, including designers, BAs, PMs, and even the CTO. Their goal is to ensure the final product is of high quality and includes any minor changes or final touches needed for perfection.
In the worst-case scenario, your work may need to be undone due to incorrect approaches, implementation errors, or false business logic.
Waiting to Live
After passing all testing, review, and quality checks, the task is ready to be deployed to the live production environment. Developers will wait for the deployment team to initiate the deployment process, making the changes available to users.
Final steps to complete here include:
Perform any go-live checklist tasks, such as running commands for migrating data in production
Merge your code from the master branch to ensure everything is up-to-date and ready for deployment.
Testing in Production
After the tech lead has followed the Go-live action and deployed the tasks online, any bugs that occur at this stage require your immediate attention for troubleshooting and resolution.
If an issue significantly impacts customers, the team may need to roll back the release to maintain stability.
Last updated
Was this helpful?