Process Design

From “Requirement Management” to the actual “Product to be Deployed” the process that we follow as a company can be seen below.

process-design

This process flow also helps us to add any CR (Change request) during development since the teams are already changing their architectural and software design during the implementation phase. The thing that we are trying to achieve is failing fast so that we can adapt to any circumstance, like environment limitations, or CRs.

Subsections of Process Design

Agile Software Development Lifecycle

The part that has been marked as the “Agile” is the part that we focus as development team and use the Agile Frameworks (Scrum or Kanban) to track our development. This part can be extended as follows:

software-development-lifecycle

This way of working helps us to work closely with stakeholders and adapt to any request from them immediately.

Process Flow

The process that we follow for each sprint is shown below, this also shapes our scrum board for sprints as well. Each box represents a column on scrum board while to move an issue from one box to another requires the “Quality Gateway” between those boxes to be met.

process-flow

Stages

Each stage here represent a column on a team’s scrum board. These can differ based on client or team needs. It can also change based on the project type itself, yet, this creates a good basis in order to follow a common way of working.

  • Backlog: The issues are not required to be groomed here. They can represent a huge deliverable or a small bug at this point. Issues might be prioritized or not. Grooming and planning meetings are done in order to refine these issues.
  • To Do: These are the issues that teams agreed on finishing within a sprint. These issues have clear goals, prioritization, estimation, well written description and all the other required things from the team in order to start the development. Issues here should meet “Definition of Ready”
  • In Progress: Here, all the tasks are being developed by a member or members of the team. In development, developer should consider all the things written inside the issue, and should aim to satisfy the acceptance criteria.
  • In Review / QA: This part is where PO or QA tester takes an issue that is marked by a developer as “Development is finished” and tests it against the acceptance criteria and other test cases.
  • Done: If an issue is marked as “Done”, this means that it will be delivered with the next increment and the feature is completed. Issues here should meet “Definition of Done”

Quality Gateways

In order to help each member of the team, we have some “Quality Gateways” that we highly suggests teams to use in order to increase the product quality as well as saving teams time for not going back and forth between the stages.

  • Quality Gateway 1: The first “Quality Gateway” is there in order to help developers understand everything about the issue. There are things to be taken into consideration before taking any issue to the next sprint, and they represent this QG.

    • Issue should be well groomed with clear acceptance criteria and story (if applicable, it can be a bug or technical debt issue, thus, it might not have story)
    • Estimation should have been done by the team.
    • Priority should be set.
    • Should satisfy “Definition of Ready”
    • Impact analysis should be done.

  • Quality Gateway 2: This gateway is really similar to the QG1 where all the things that were mentioned there should be reconsidered. Other than those we recommend:

    • Tasks should have been created by the team. (if applicable)
    • Issue picked up by a developer

  • Quality Gateway 3: This part is supported with the CI pipelines for achieving the quality, yet, it still needs some investigation by the team itself.

    • Unit tests are executed and they pass (if applicable)
    • Merge request is submitted.
    • Automated build succeeds.
    • Code review is done.
    • Static code analysis is done. (if applicable)

  • Quality Gateway 4: This gateway decides if the feature should be in the next increment. Here PO and QA testers checks the issues and sees if it satisfies the requirements.

    • Acceptance criteria is checked.
    • QA tests are executed and they pass.

Waterfall vs Agile

Unless there is strict request from client, we highly encourage our teams to use “Agile” as their software development process. However, there can be projects where all the things are already planned, all the deliverables are time boxed and decided beforehand and when there is a priority on delivering a finished product instead of failing fast, instead of calling our methodologies “Scrum, but…” we can decide on working with different processes for software development.