Building an Agile Product Workflow
Looking at the workflow illustrated above, many IT Project Managers may find it a bit overwhelming at first glance. However, this article will breakdown this entire workflow into its major components for a better understanding and appreciation of it. The main benefit of creating and sticking to a product workflow in the software development domain is the system of check and balance when building an application. This reduces the chances of creating something users don’t want to use.
“Everyone feels process constricts progress, however without a workflow leads to chaos”
Typically, we use tools such as Jira to manage the workflow for teams, no need to try to memorize all the steps. However, it’s best to ensure that you walk through these steps with your team during the tech ramp-up phase of your project as well as part of your on-boarding process.
Let’s dive into the three (3) major iterations of the workflow that a User Story flows through when developing a product.
#1 Development
The first phase is no surprise. During the development component, the development team focuses on each story in order of priority from start to finish. From the sprint backlog, an item is moved to In Progress. If there is a point where that action is blocked or at risk, the story is then put on Hold until it can be solved. Once the item is coded and unit tested by the developer, then it can move into the next phase, Code Complete; this is typically a push request to your code repository for a more senior developer to review.
#2 Code Review
At this point, your code is sent to a more senior developer work backlog under the Code Complete. The Senior dev takes items to review the code in-depth to ensure that the code follows the best practice approach. Suggestions are made, at this phase, on how to improve a snippet of the code. It’s a feedback loop with the team to ensure they catch the majority of the issues that can create a high technical debt. If the code passes the Senior Dev review, it moves to a larger repository for QA review. If not, then the Snr dev fails the code and sends it back to the dev phase with comments and suggestions.
#3 Quality Testing
The final iteration within the entire workflow is the gatekeeper phase. This ensures that the changes made to the repository don’t cause any regression within that codebase. There is more in-depth testing done during this phase, such as smoke testing and regression testing. These typically will allow testing of the entire application thus far for any issues that might pop up. This is the only phase that a bug can be created. A bug will be similar to a user story, outline the issues, and give a bit more detailed information such as browser type, steps taken, and results. Most QA uses a combination of acceptance criteria and test cases to run their test review. If the code does not affect the overall codebase it is then accepted. After the sprint is completed the entire code that was accepted is then pushed to the staging environment.
“Extraordinary Software teams align to the need for workflow”
There is a need to ensure that all the team members have clear roles and responsibilities to ensure that there is a smooth flow within the workflow.
Here are a few tips to take into consideration when designing your team Workflow:
Start your workflow simple:
Ensure that whatever deviation of the standard workflow that you take on as a team is not overly complex and hard to follow.
Optimize your workflow:
As your team matures in a more agile and collaborative manner, look for ways to optimize your work to reduce or increase the number of transition phases. Assign teams to specific transition points. The decisions can be made from the team retrospective.
