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.
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.
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!
Tags: Agile
Hi Maciej,
The main point I keyed in on in your post is that to be effective a process needs to be as simple as possible. I remember when I worked for an IT consulting shop that the overhead of logging all of my travel and what I did added many minutes onto everything I did. Had the process then been simpler, I could have been even more productive. As a result, I became frustrated and annoyed at the process. At the time, they didn't want to change how things were done, so I continued slogging my way through the day. I'm hoping they, as you did, were able to find a better way.
Hi Robert,
Your remark is very accurate. Our previous workflow consist of 30 states and different for each task type. That was very difficult for our team members to use it effectively. We have simplified it but this is only one step forward.
What we have in our plans is to allow people to put their daily tasks in form of excel sheet. What do you think? If you could use excel sheet and write there your daily operations and at the end of the day press submit and the job is finished?
While I'm not a big fan of using spreadsheets for anything other than crunching numbers, it can work. There are a number of lightweight tools that you can use for this type of thing. If you do decide to use a spreadsheet, I recommend using Google docs so that everyone can see what is going on all the time from anywhere. If you are tracking hours too you can build burndown charts too.
Let me know what you end up with.