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

Question

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!

Answer 1

I agree with the comment from @salsolatragus... your problem is that the business side isn't using agile at all. From my experience this is a classic growing pain that happens... So force the business side to be changing the way that their interactions happen.

Lock them out. (But figure out how to sell it better than that...) Do it as a 'process change' that is supported by some kind of need. Perhaps just a bit of a rearrangement in conjunction with the new calendar year that is coming.

With that light reorganization, I would say that you need to teach them what your process should look like. They won't care. Tell them anyways. Here are the steps I would take:

Fence it in. (Your process). Based on the Agile methodology you're capable of working with, what should your development processes look like? How long are your sprints? How often do you complete stories? When do you run out of new requirements? How does your technology facilitate the basic tasks behind collecting, prioritizing, and executing project tasks?

Figure out how to fence them in. The business side needs to be told how it can use this process. No one has told them yet... no one knows how they should use it so it has grown like a sprawling, out of control tree. It's your job to figure out how they should be allowed to interact with this process. How often do they really need to provide you with new requirements? How often do they need to receive completed functionality updates? Define their use so that they can act that way. [BUT DON'T CHANGE IT BEFORE YOU'VE TOLD THEM]

Communicate... If you don't have the individual clout within the organization to make this change happen, find someone who does that will understand your pains. Make the business case very clear in terms of lost time due to confusion, or errors, or something. And then go about setting up the presentation or user's manual or process instructions that will support your 'new' way of doing this.

Then, communicate very clearly with the business stakeholders that you're going to obtain new requirements from them once every X... (month? quarter?) and that they're free to dink around as much as they like in their requirements-gathering sandbox outside that time.

Focus especially on how this makes their jobs easier, and how this makes it possible to move forward one step at a time.

If they're stuck on setting up mini-tasks because that's how they're most comfortable expressing their new functionality requirements, then let them. You don't need to battle with them to try to force them to completely change what they're doing... But make it clear that because they're the business side the tasks will be taken as a suggestion and that the development side reserves the right to add additional tasks that have to be inserted.

Then, actually fence them in... If you can figure out the right interface for handing off requirements requests, then lock the business users out of your 'task development' interface. That's not their job. And especially if they're not playing Agile with you, then they're not welcome.

Be diligent and disciplined in actually delivering. If you lock them out, make sure that you're doing what you said you would. Once every month or quarter... you meet with the business interfaces individually, tell them the sprint successes that have been completed... tell them what your group is planning next... and then ask if there are any other new requirements...

Come away from that meeting with a clear set of instructions for the next period of time in terms of tasks that should be completed and priorities. And then rinse and repeat.

Any project management system tends to formalize the communication processes that get overlooked otherwise. You just need to impose better communication here.

Answer 2

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.