Isn’t it more that people tend to use agile as an excuse for not having any kind of project plan.
It’d be interesting to know how many of those agile projects actually had an expert project lead versus just some random person who was picked who isn’t actually experienced in project management.
In my experience It’s not about a project plan for features, but actually doings things correctly instead of doing the minimum to finish what you need to do on the current sprint.
I’d say it’s that people tend to use Agile because consultants tell them they can be piss poor managers dealing with the crappiest developers and stupid business ideas and still make awesome stuff if they just make everything buzzword compatible.
I’d say projects without much of an upfront project plan can still be very successful, but it’s all about having a quality team, which isn’t something a two week ‘training and consultancy’ session isn’t going to get you, so there’s no big marketing behind that sort of message.
Agreed. We follow agile, and we have a team of product owners who know where the project is likely headed in the next 3 years. Our sprint to sprint is usually pretty predictable, but we can and do make adjustments when new requirements come in. The product team decides how and when to adjust priorities, and they do a good job minimizing surprises.
It works pretty well imo, and it hinges on the product team knowing what they’re doing.
Isn’t it more that people tend to use agile as an excuse for not having any kind of project plan.
I’d say it’s more about continuously milking customers on projects that never seem to end. I’ve never done software project management, but I have seen it’s “tenets” applied to other types of projects. The results were arduous - to say the least.
I’ve seen it being done even on internal projects though. Things within an organization.
It tends to be that they start developing a feature and then someone comes along and says, ooh wouldn’t it be nice if it did x, so they modify it to have x feature. Then someone decides it should be able to sync with Azure (there’s always someone that wants that), so Azure sync is added, but now that interferes with x, so that has to be modified so that it can sync as well. Then we get back to original product development which is now 3 weeks behind schedule.
Repeat that enough times and you can see why a lot of this stuff fails.
Even internal projects have a facet of ‘milking customers’ even those customers are internal. There’s a rather large internal team that has managed to last years by milking the fact their stuff always sucks but any moment when they are challenged about their projects they always have a plan to fix all that’s wrong within ‘3 months’.
During my project management days one of the things I learned the hard way is to nail down exactly what something has to deliver and getting everybody involved to sign onto it in black and white - if you don’t, disaster follows.
Agile seems literally designed to make this impossible.
Isn’t it more that people tend to use agile as an excuse for not having any kind of project plan.
It’d be interesting to know how many of those agile projects actually had an expert project lead versus just some random person who was picked who isn’t actually experienced in project management.
In my experience It’s not about a project plan for features, but actually doings things correctly instead of doing the minimum to finish what you need to do on the current sprint.
I’d say it’s that people tend to use Agile because consultants tell them they can be piss poor managers dealing with the crappiest developers and stupid business ideas and still make awesome stuff if they just make everything buzzword compatible.
I’d say projects without much of an upfront project plan can still be very successful, but it’s all about having a quality team, which isn’t something a two week ‘training and consultancy’ session isn’t going to get you, so there’s no big marketing behind that sort of message.
Agreed. We follow agile, and we have a team of product owners who know where the project is likely headed in the next 3 years. Our sprint to sprint is usually pretty predictable, but we can and do make adjustments when new requirements come in. The product team decides how and when to adjust priorities, and they do a good job minimizing surprises.
It works pretty well imo, and it hinges on the product team knowing what they’re doing.
I’d say it’s more about continuously milking customers on projects that never seem to end. I’ve never done software project management, but I have seen it’s “tenets” applied to other types of projects. The results were arduous - to say the least.
I’ve seen it being done even on internal projects though. Things within an organization.
It tends to be that they start developing a feature and then someone comes along and says, ooh wouldn’t it be nice if it did x, so they modify it to have x feature. Then someone decides it should be able to sync with Azure (there’s always someone that wants that), so Azure sync is added, but now that interferes with x, so that has to be modified so that it can sync as well. Then we get back to original product development which is now 3 weeks behind schedule.
Repeat that enough times and you can see why a lot of this stuff fails.
Even internal projects have a facet of ‘milking customers’ even those customers are internal. There’s a rather large internal team that has managed to last years by milking the fact their stuff always sucks but any moment when they are challenged about their projects they always have a plan to fix all that’s wrong within ‘3 months’.
During my project management days one of the things I learned the hard way is to nail down exactly what something has to deliver and getting everybody involved to sign onto it in black and white - if you don’t, disaster follows.
Agile seems literally designed to make this impossible.