Intro

I want to present here a very simple but quite effective tasks workflow which can be used in smaller or middle IT companies or startups with no "heavy lifting" techniques and limited staff resources. The process here was tested for many years of leading such companies.

Resources overview

We recommend following software/hosting resources:

• Version control system (VCS) for code management and storage: github.com, bitbucket.org or gitlab.com. Which one to select is completely up to you and highly depends planned team size and amount of private repositories (code groups which are note available for the outside world)
• Task management system, needed for controlling tasks lifecycle and organising people into the execution flow. One of the best TMS is Jira, which is not quite expensive for smaller teams. Other possible systems could be Trello, Github Issues or any other which allows to define some task, change it's status (e.g. pending, done, closed) and add some comments from the involved participants.
• Optional testing env is needed to test the new code manually by QA specialist before it goes to production
• Production env
• Optional continuous integration system (CI) (which is for sure required when skipping a human QA) which are needed to trigger automatic tests to make sure that no faulty code is reaching the production. The most known projects here are Travis, Codeship, Buddy, Codefresh. The selection decision is highly dependant on the amount of team members involved into the testing procedure.

Recommended minimal human resources/roles:

• software/hardware development team: 1 or more development specialists responsible for creating new features or fixing existing problems in the product
• project manager (PM): a person responsible for creating tasks, controlling their flows and interactions between team members
• product manager: a person who "owns" the product of the company (application, site, hardware product). This person would be needed to prioritise tasks according to their business importance and drive forward the company product with features, their proper qualitative and in-time implementation.
• quality assurance specialist (QA): a person responsible for testing of the new code and making sure, that the recent changes don't brake the already running system. In some cases this role may be not needed when doing proper test driven qualitative code delivery.
• UI/UX specialist needed to give a concrete visual representation of an idea

Tasks flow and lifecycle

We can separate task delivery into conceptual, implementation, testing and delivery stages:

Conceptual stage

1. Business Owner (BO) has an idea how to improve the product to gain more business value. He interacts with Project Manager (PM) to describe his idea. The business value is mentioned and the importance of the task is discussed (as there are probably other tasks including the running ones).
2. PM creates a task in the Task management system. Task has the status "New" and is assigned to the UI/UX specialist. 
3. UX implements the idea as a designed picture, discussing the task details with the PM. Different variants are also discussed with the BO, at the end one variant is selected.

Implementation stage

1. PM creates a development task, makes its status new and assigns it to a developer. The latter should write a code, which implements the design from the conceptual stage.
2. The code is pushed to the code base. It's recommended that the developer does this at the end of the working day. 
3. Dev interacts with the PM to clarify the task details. 
4. Once the task is ready, we call another developer to check the code. Normally the code review happens in the code base, where any developer from the team can do improvement suggestions:
5. If the reviewer is happy with the code, the task is marked as done and attached to the QA

Testing stage

This process describes the manual testing procedure for the teams with a dedicated QA role. As mentioned, this can be omitted under some circumstances:

1. QA picks up the next done ticket and deploys it in a testing env. This might be a dedicated server or mobile device or a client computer. The status of the task is changed to "Testing".
2. QA tries to find the problems in the code or discrepancies with the specifications. Sometimes this process might involve the PM to clarify the requirements or the developer to refine the implementation details. 
3. All discovered problems are reported in the task comments. If the developer can fix the problems very quickly, he does this on the fly, asking the QA to redeploy and retest his code. If the problem requires more than half a day of work, the task status is changed to "in development". This round repeats till QA is happy with the implementation. 
4. If all is good, QA marks the task as "Passed QA".

Automatic testing stage

This stage might be completely omitted if there is a QA in the team. On the other side, if no QA is involved, this stage becomes mandatory. Also this would require for the developer to use test driven development approach, constantly covering new features with automatic tests. 

1. CI System is an automatic testing env (a remote server, a device connected to internet, VM with a simulation software etc), which runs the tests from the code base, written by developers in the test driven way. This stage might also include triggering automatic checkers for the code quality. This stage is triggered either by developer manually or automatically when a new code is pushed to the code base (this would require some integration effort between the code base and a selected CI system).
2. For any failure CI will mark the task as failed (which also will require some integration).
3. Developer might fix the code immediately and push it to the code base triggering another round of automatic tests. In some code bases (e.g. Github) it's not possible to merge code changes into the production version, when automatic tests are failed. 
4. Green test results open the direct way for the code to production

Delivery stage

The aim at the stage is to make sure, that the new code appears on production. 

1. User merges his changes into the production version of code and marks the task as delivered. BO is attached to it as the next responsible person.
2. BO evaluates the final result on the website, or downloads the app and tests it on his device. 
3. If no problems are found, the task is marked as accepted. If some issues are found, BO asks to create a followup ticket, and marks the current task as "production issues". 

Analytics stage

For smaller teams and companies we recommend to organise a retrospective meeting once in 2 weeks. On those meetings people can shortly present what they did during the last 2 weeks and mention problems in the tasks implementation. It also recommended to develop a positive and productive culture of problems discussions with the main emphasis on the suggested improvements rather than on points of criticism. Special attention should be payed to the tasks which took longer than expected, especially about reasons and problems for that to happen. Those meetings should also lead to common accepted democratic decisions about how to avoid implementational or organisational problems in future.

Conclusion

The suggested approach could be pretty well integrated into small and medium IT companies with possible variations. The main principle is should stay the same: if the condition of the task changes, it should be reflected in its status and assigned person. Our workflow in this process becomes very straightforward:

• I open the task management system and find tasks attached to me
• I take the most important task (usually the one on the top of the list)
• I change the status, implement it and change the status for the next step
• I change the next responsible person field (in some systems this might happen automatically)
• I pickup the next task

The control points of task implementations are also quite obvious:

• We can check how much time a task took (since we are able to track when the task was started)
• We can do daily stand-ups to discuss tasks in work to have early infos about problems and track the progress
• We can see the performance of involved participants (how many equally complicated tasks were delivered per time unit)
• We can always have an overview about the occupation picture of our team 
• We can plan our next features far in future and make a delivery plan