When working with a development team to move to a new delivery methodology, the hardest part in the transition is getting all the other stakeholders on board with the changes and realizing that they need to do some changing on their side as well.
Backing it up a bit — the problem generally starts with — “We’re not delivering software well, we need to do something new, I’ve heard of this thing called Agile, we should do that”. (Feel free to replace Agile with any other development methodology, framework, implementation du jour that everyone is going gaga over).
The fallacy in this is that the rest of the company (the stakeholders) don’t need to change anything and that this will “just work” and numbers will improve.
Think of it this way, you have a car that needs a completely new engine — the simplest approach, with no changes required, will be to get an exact replica of the old engine, but you don’t want a new engine, you want something different, something faster, something more efficient. That’s all fine and dandy, but you’re going to have to change the connections that interface with your engine so the rest of the car can use it.
Just look at all the work that had to be done to get Mr. Fusion online in Back to the Future!
Your company doesn’t need to go Agile simply because your software teams are, but they will still need to change.
We’ll use Agile as an example (because this is what I get hit with the most).
Everyone Needs to Use Sprints
No, and they don’t need to use JIRA either. What they do need to understand (I’m looking at you Sales and Marketing) is that the team is now focusing on delivering value every 2–3 weeks instead of going into a cave for 3 months. You might not see the completed deliverable after the first or second sprint, but you will see the incremental improvement, be able to provide feedback and be able to contribute earlier.
But just because the Dev team is using Sprints does that mean you need to? No of course not, you might see some value in it, but I would…