Their manager got an “agile PM” forced on them and it broke.
The problem is charlatans, dictators and career ticket shufflers that deliver little to no ROI and generally abject chaos.
Their manager got an “agile PM” forced on them and it broke.
The problem is charlatans, dictators and career ticket shufflers that deliver little to no ROI and generally abject chaos.
The only time I've ever seen this not happen was when we had a 55 year old delivery manager who viewed his job as facilitating team meetings in a way that meant everyone got the chance to speak and that consensus formed. Didn't try to dictate process or anything, just made sure everyone got heard and that decisions got made. He was patient enough to wait and not force the issues, too.
(I refuse to utter the above phrase without accompanying it with tjis: "not everything that counts can be counted")
You will still get cold emails and LinkedIn messages from these people but you don't have to respond
I still don't understand the role of PMs when there are engineering managers, product owners and self-organizing teams involved.
If it’s not described, and only works via the “minds of a few engineers”, you get amateur treehouse-quality engineering like the 737 MAX.
I guess chance can make it work well like that “once” sporadically, but when you need to touch that code again to maintain it, we go back to the amateur treehouse.
[edit] Too many of these people want tomatos, so they plant a tomato, when really they want seasonal tomatos, and need to consider a farm, and take into account growth cycles. The term I like is "sustainable development."
As mentioned by user "phkahler":
> 1) Come to work.
> 2) Look at the current state.
> 3) Decide what the product needs from you.
> 4) Do that.
> 5) Use git.
> Steps 2 and 3 may involve communication. Step 5 is tracking changes. Have a PM that tracks main things people are working on and estimated dates (not dictated dates).
> This is how my current job works and we are unbelievably productive.
[edit]
I like the book "phoenix project," and I think they wrote "Team Topologies" which I am curious to read.
[edit]
In general, psychological safety was the number one factor for productive teams, according to a massive google study. From this viewpoint, it's easy to see why there are so few productive teams, as there is little to no safety for most people. Remember though, "There are no silver bullets."
[Edit]
The goal should be continuous delivery imo.
And of course that is where the cost savings are usually made because it is seen as a null function in some businesses. It creates waste and reduces delivery and ROI. Those are all symptoms of other problems in the business but that's how it is generally perceived. And sometimes clients are happy to receive muck if it's cheap.
But that's also how we get planes that crash and Microsoft firing their entire QA and delivering shit for the last half a decade.
And that in turn is because management and project management culture is data driven by people who have no idea what the fuck they are doing whatsoever.