We figured out that the best way to ensure a proper workflow is to include as much information to it as possible. As a consequence, we created four different trackers in our management environment: request, ticket, bug and question. All of them had a separate collection of statuses (like new, working on, needs testing ect.), which were restricted to some roles. So there was one path of workflow for a tracker, but not everybody was able to take another step in that path. At the end we had 4 trackers, 30 statuses (the sum for all trackers) and roles, that work was dependent on some other roles. It was complicated, but on paper, it looked good.
And then the problems emerged. The workflow was hard to understand and not easy to explain, but we thought, that it was just a question of getting used to it. After a solid amount of testing, it turned out it was not the case. What went wrong?
- Workflow was too complicated -4 trackers, 30 statuses and at least 4 roles with different paths for each tracker.
- Additionally, some trackers were dependent on others i.e. when request, ended on the accepted state, the new ticket had to be created to work with (as a feature in implementation). Too many restrictions for roles –in some cases restrictions were imposed to ensure better control of the project, but in fact, they were actually slowing down the work (e.g. developers had to wait for Project Managers to start the ticket, but PM’s where busy elsewhere).
- Our workers acted as projects developers in certain projects and in some as managers. The path was changing depending on the project, creating the confusion.
- Too much mindless clicking to get to the right status – when the job was already complete, or the task was non-standard, it still had to follow the restricted path. If the task encountered problems and needed to return to the previous state, it was required to guide it to special status – a returning point and then start the work again.
“If you have ten thousand regulations you destroy all respect for the law.”Winston Churchill
Having learned a lesson from our experiences we decided to simplify the paths of the statuses as much as possible. We also considered creating one path for all trackers our highest priority. As a result, we managed to achieve 12 statuses, adding two custom fields as ancillary fields. This way some information instead of being duplicated in statuses (like ready on, or completed on the development server, test server, production server), was transferred to optional fields. Additionally, we decided that we will not restrict our workers. Developers received the possibility to create issues and could instantly start working with them. Project Managers were given absolute freedom over the workflow, not dependent on the next status.
The key to avoiding chaos in the environment was creating new transparent documentation. Thanks to it any uncertainty in directing the issue on the path could be eliminated.
“You cannot make men good by law: and without good men you cannot have a good society.”C. S. Lewis
In conclusion, it turned out that it was the best job we could do. We realized, that it wasn’t restrictions that made good workflow, nor a large number of statuses. It’s the people. Their understanding and their teamwork skills made it possible to properly control the issues. As the basic rule of Agile development says “A good team in a good environment “, the software is not to restrict, but to expand the team capabilities.
Feel free to share your opinion with us by placing your comments below!