If there was no law, would everybody be criminals? Creating an agile workflow

agile_flowAgile methodology gives an enormous amount of flexibility. This is also a challenge because flexibility and freedom means something slightly different to each team member . The goal is very simple – do the best in the most efficient way. Unfortunately without having a specific agreement on how we follow Agile it will become a mess. Due to that fact, based on SCRUM and Agile approach we have designed our own workflow which is applicable to all our employees and clients. We are alltogether in one workflow which is clear to everyone. At least in theory. To make it real we had to configure our project management environment to allow  following the Agile approach. After several improvements we think that we managed to implement a very suitable workflow in managing our daily operations and cooperation with customers in Agile way. Have a look!
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 tracker, but not everybody was able to make 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 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 where dependent on others i.e. when request, ended on accepted state, new ticket had to be created to work with (as a feature in implementation).To many restrictions for roles  –in some cases restrictions were imposed to ensure a 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 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 expirences 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 a ancillary fields. This way some information instead of being duplicated in statuses (like ready on, or completed on development server, test server, production server), was transferred to optional fields. Additionally we decided that we will not restrict our workers. Developers received possibility to create issues and could instantly start working with them. Project Managers were given an absolute freedom over the workflow, not dependent on the next status. The key to avoiding chaos in the environment was creating a 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 the 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 “, software is not to restrict, but to expand the team capabilities.
If there was no law, would everybody be criminals? Creating an agile workflow
Agile methodology gives an enormous amount of flexibility. This is also a challenge because flexibility and freedom means something slightly different to each team member . The goal is very simple – do the best in the most efficient way. Unfortunately without having a specific agreement on how we follow Agile it will become a mess. Due to that fact, based on SCRUM and Agile approach we have designed our own workflow which is applicable to all our employees and clients. We are alltogether in one workflow which is clear to everyone. At least in theory. To make it real we had to configure our project management environment to allow  following the Agile approach. After several improvements we think that we managed to implement a very suitable workflow in managing our daily operations and cooperation with customers in Agile way. Have a look!
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 tracker, but not everybody was able to make 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 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 where dependent on others i.e. when request, ended on accepted state, new ticket had to be created to work with (as a feature in implementation).To many restrictions for roles  –in some cases restrictions were imposed to ensure a 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 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 expirences 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 a ancillary fields. This way some information instead of being duplicated in statuses (like ready on, or completed on development server, test server, production server), was transferred to optional fields. Additionally we decided that we will not restrict our workers. Developers received possibility to create issues and could instantly start working with them. Project Managers were given an absolute freedom over the workflow, not dependent on the next status.
The key to avoiding chaos in the environment was creating a 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 the 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 “, software is not to restrict, but to expand the team capabilities.
Feel free to share your opinion with us by placing your comments below!

IT guy with head full of ideas, strongly oriented on achieving great goals in life. Currently working for Aspire Systems Poland, place where I grow.