Ideas how to convince old-school tree project management users to agile project management?



  • 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.

    This works.

    But we have a problem with business managers. Their old-school workflow is follows:

    1. 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'.
    2. 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!


  • QA Engineer

    Lead by Example or hire a consultant

    In my previous company, we in the the software development team switched over to the agile development process. Over a period of time the following benefits became visible to the larger organization:

    1. Vertical slices of work were delivered to end users frequently. We were demoing completed features every two weeks and deploying them every month successfully.
    2. Our productivity increased.
    3. Our quality got better.
    4. Our teamwork got visibly better.

    Partly inspired by this, one of the business teams started following the agile development process for non-software development work. All that we did was to invite that Scrum Master over for an occasional brown bag lunch session to share best practices.

    You might want to try a similar approach. However, be prepared for it to be a very slow process. If you are looking for quicker results, try hiring a good agile consultant.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2