Communication of Agile approach benefits and common misconceptions when compared to traditional project management

Lenka,
One of the biggest misconceptions I see with adoption of agile is everyone wants less detailed or complex documentation. Though the guiding principles call for a working product over comprehensive documentation, I know many environments such as those in the public sector often call for detailed regulatory documentation throughout development. Personally, I find it best to openly communicate these requirements and find ways to incorporate them into each increment.

i'm actually right now talking to a friend who thinks his company is Agile but it's not. People are confused about Agile, and they do Agile.

Pure Agile does not provide any predictions about when a given set of scope will be done. Some claim you use story points, velocity, etc to predict epic or feature completion. That is A) correct, and B)not Agile. Even Ron Jeffries, one of the creators of story points, regrets creating them. By the time you get enough history to predict velocity, the feature is likely almost complete. And very rarely are two features similar enough to use t-shirt sizing to predict another. Instead A) leverage your product owner, B) ensure you deploy code to production at the end of every sprint, and C) use retrospectives to predict next sprint and communicate actual progress made. Spend your efforts on right-sizing stories.

Story points aren't even in the 2017 guide.

Again, that is a pure Agile approach. In the real world no CFO would let us get away with that. Most organizations are command&control, and must use t-shirt sizes, velocity, burndown charts,or some such mechanism to predict completion.

If I was to promote a "true" Agile approach i'd find a way to tell the CFO that we need to fund teams, not scope. But don't release 6-9 months of funding, or release it to the Product Owner but don't be upset at them if they return the funding as it is inefficient. Stop predicting completion dates for a given set of scope, it just doesn't work. Anyone who says they can do a reasonable job of balancing scope/cost/time is selling you something (and this is from a guy who's been a PM for 20 years and makes a good living off it). Change Orders abound, dates or budget is missed. This is just wasted effort done to satisfy CFO / COO / CEOs, and if they really want to maximize efficiency they'll stop it.

I'd also ensure my resume is written because 90% of them would fire people for saying that, but then again i'm a consultant, I always have a resume ready to go. My job is to tell them what they need to know, not what they want to hear. I am CONSTANTLY brought into situations where there are material cost or time overruns because their PMO insisted upon knowing the unknowable.

First thing: something project management does not exists. What exists is project management performed in a way (PMI, IPMA, GPM, etc) into quit different environments or approaches (Agile, Lean, etc). If you do not understand that then you are lost. Agile, or any other thing you will use to make something, must be evaluated in terms of impacts on your organizational architecture. To give you some information that belongs to business analysis field. Agile must be used as a component inside a solution. So, to understand if your organization is ready for that or to understand the impacts you must perform "needs analysis". I wrote an article on a practical method to do that tha was published by PMI and the IIBA as "best practice". Hope it helps: https://www.projectmanagement.com/blog-pos...-right-solution