How the agile management style working out for you? Time to simplify?
https://www.google.com/amp/s/www.military.com/veteran-jobs/elon-musks-6-rules-of-productivity-show-divide-between-military-and-civilian-workplaces.html/amp
24 replies (most recent on top)
BB is the teflon don. He knows how to manage things.
Need to dump BB, unbelievable he hasn’t been fired after this atrocious imagine IT disaster…….
So, It's a "post your favoite link thread"? LMAO. Please children, we all know how to use the interwebs at this point in out lives, even the older ones who built and developed it, surprisingly enough to the zoom bo-m bang gen.
yawn.....
https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
We accidentally tried agile for floating facilities many times - meeting our sailaway dates (bonus $$) with only some of the facility complete and trying to agilely finish it during towing, installation and commissioning but not realizing bed space limitations and the logistics of no longer being dockside for loading equipment. It was always a horrible disaster.
@6rws: You said it perfectly: "...best suited for large teams of low value workers doing simple tasks that lead to results with low failure cost: Do it quick and recycle towards better results..." True of the vast majority of IT projects, painfully wrong for most other projects.
"agile"... "perfectly great framework". I find that questionable. Even reading the outside agile documents is appears to have way too much management overhead and is best suited for large teams of low value workers doing simple tasks that lead to results with low failure cost: Do it quick and recycle to wards better results. We are all keenly aware of the results of this process from using Microsoft's Windows, where endless hours or end user costs are acceptable if the development tean can get a new version out the door every year. The oil indistry, with many very high value specilized workers and very high failure costs is simpoly not a good fit for agile management. CPDEP, while no panacea, was at least focused on the way we work at Chevron: Basisically get all parties to stop, review, and agree before getting the flag to spend a huge amount of money on a decision that would be very costly to recycle.
Actually what Musk describes here IS agile! Our problem is that we take a perfectly great framework and “Chevronize” it.
What Chevron is doing right now is not true agile.
Despite CPDEP, most of our projects were disastrously mis-designed due to huge surprises from the reservoir, facility operability and reliability and more. We just can't seem to get it right.
@5zml, the idea of CPDEP was fine, but once you saddled it with all the review teams (internal and external to the BU), phase gates (when worked stopped in order to make spreadsheets and pretty powerpoints), and DRBs (go ahead and try to schedule a meeting with all of them), it became overly sluggish. A good DRE could cut through all of that, but most of them wanted to "hide" behind the review teams and DRBs in case something went wrong.
CPDEP worked just fine. Before each project started, you sat down with the stakeholders to work out how much of the process would be needed so they could make a decision. People didn't realize that it was fit for purpose and blindly did all that work for nothing except to check a box.
Post ID: @4lxn+1irylBU8: agree, and totally predictable. If you are selling software it is cheaper to put cr-p out the door and then sell incremental updates to fix features that were poorly planned. If you are placing billion dollar platforms, the cr-p planning with recycles method works poorly. SURPRISE!
Absolutely everyone but the SR crowd knew Agile was a poor fit for Chevron. Whereas CPDEP was overly cumbersome and slow-moving, Agile is 'fast-moving' but terribly inefficient and delivers half-baked results (by design, MVP). Both CPDEP and Agile were overly complicated processes to try and make up for poor local management.
CIO is one of those vague, responsibility- and accountability-free positions for high-pots who have stalled or fallen out of favor. Check out the last few CIOs, none have advanced in the company. Excellent position for EB.
When will she who shall not be named become CIO?
CPDEP would have been great without the PRC corruption. The execution part was always lost because of favoritism and the way they bring their friends.
The current ETC head is another disaster. She will do nothing good to the company. She over run FGP and they had to take her out but she is another fake face of fake diversity.
We need to turn the page on this chapter of our history ;-)
The low chapter value is driven partly by truly dismal chapter leads - the weakest and worst in ETC history. They manage to lack both technical AND leadership skills. Staff are horrrified.
I think CPDEP worked comparatively well, with its focus on major decision gates rather than continuous short-term reviews after fixed sprint periods.
The entire Chapter fiasco needs to end. We waste so much time just talking and planning. Nobody is Doing anymore.
None of the chapters have any sort of depth. They are playing the role of an internal consultancy that has no staff to hire out.
The idea is sound - you lump the software engineers together so they can learn from each other and not get siloed in some random corner of the company. In reality, the chapters are an exercise in overhead.
Yes, please bring back CPDEP (said no one)
No, I agree, We need to dump teh whole thing. It has run it's course.
rather dump chapters. How does having a sub chapter help? Why do we have open SW engineering positions but fully staffed chapter leads? Seems like we shouldnt fill sub chapter head openings until all postings are filled. They are supposed to be the experts in the areas right?