I have a bit of an issue in my current company. We are implementing Atlassian JIRA as our project management tool for both business problems and software development and while the software development teams are enthusiastic, knowing fairly well how agile works and how projects should be managed, we have a problem 'selling the idea' to business managers - who are also integrated in the process.
The way things work in JIRA and the way we have set them up is as follows:
Each project is a separate project, maintained by separate project managers and software developers. Internally it has version numbers on issues and every issue has subtasks, which govern over different states of the issue, such as when the issue requires technical analysis, development or additional testing. Once the issues have their subtasks done, the issue is set to fixed and then, once pushed live, the status is changed to Live and the issue is closed entirely.
But we have a problem with business managers. Their old-school workflow is follows:
- They get requirements from different sources (upper management and internal development requests) that have not been fully analyzed yet. These may be badly worded requests for developments, bugs and fixes that need to be done but which are not clearly defined yet or whole new projects, like 'Make project C happen'.
- Depending on how 'large' their new incoming issue is, they used previous software to create subtasks to this first issue. And depending on how large those subtasks were, they created other subtasks and so on and so fort, in the end having this massive tree that grows new branches as it happens. Once the whole tree is solved, it is closed. This whole tree still has the original 'request' as the main issue, no matter how large the issue grew.
This approach is problematic, since it is terrible for getting reports, estimations and any kind of structure out of such a tree.
I've been trying to make it clear that it is not possible to think in this manner effectively and that at first they should simply send the first issue to analysis to see how many 'actual issues' should be created and those issues should be then sent to their appropriate departments for development and if needed, linked back to the original issue, for status updates on their end.
But it is not getting enough grip, it's a classic 'we have been doing things in this way and we are fine with it' locked guard and there's problem getting the old-school thinking of 'endless tree' in project management out of their minds.
Any ideas how to 'sell' the idea of project and queue sprint based project management? One of the problems seems to be that the users have a hard time knowing what to do with an issue, whether the issue is so big that it should be a whole new project or just a separate issue and where it should go next.
Grinding my teeth here :) Any ideas are welcome!