11–20 of 42 posts
Earlier quoted context omitted.
The number "20%" scares me because people will makes his a hard rule. Soon you'll have to justify why you didn't refactor your stuff.
Or worse, I spent 1 hour writing it, so 15 minutes refactoring... And done, no more refactoring...
"Agile" should have stopped at the Agile Manifesto. The principles described there are useful. Scrum sounds good in theory but in reality I have never seen it really work. Mostly it devolved into a micromanagement tool.
You can't use methodology (or a pointed lack thereof) to change personality.
I fashioned a 90's Agile type methodology based on Release abstractions and project progress visibility.
There were always 3 Releases (MRTP - Multi-Release Technology Plan) for parking inbound feature requests from inbound stakeholders. Developers shared "minds eyes" on future releases.
Then we group scheduled integration deliverables (not activities) by Weeks. Rare deliverables were given longer extensions. Sharing a spreadsheet of weekly deliverables to the next release required enough analysis to share the schedule abstraction.
Going dark was impossible. Everyone documented short "So Far, More To Go, Defer It" lists with short rationales similar to version control commit comments. We could push schedule breaking "features" to future releases. Every Thursday was integration and retime boxing of the schedule. The dev notes were collated into report "Weeklies." In practice, more continuous integrations were daily to his weekly hard integration targets.
The methodology started with a workbook of about 15 product planning exercises from User "day in the life" to "operational cost estimate" spreadsheet formalisms.
In practice developers shared a subset of the planning formalism "intermediate representations." But all stakeholders (business too) were fully aware and SIGNED ON to every planning step skipped for schedule or cost necessities.
It was very ritual high visibility human applied "design by contract." We had a perfect execution record on early Linux tooling with teams from 2-15 (Product Planners, Information Architect, Soft Devs, System Architects) on about 125 high pressure engagements. Most was a mix of Java Servlet, SMTP and C telecoms projects. We had to write our protocol handlers back then on shifting sand.
I might write it up as "The Adrenaline Way." It doesn't easily apply to individual, exploratory or Kanban content "journey without a destination" project teams. But it applies well to products with inbound and outbound marketing teams involved.
To me, agile is endless micromanagement. Tracking every little thing in JIRA and having constant pointless meetings. The next time I look for a job, I'm going to categorically rule out any company that uses JIRA at all.
And then there's a particular quality associated with agile that just comes off as cult-like. A while back, I was googling "scrum master" to find out what one actually did, and I stumbled on the official scrum page [0]. Some of the terminology on that page just jumps out at me saying "this is a cult" (in particular, the phrase "servant-leader" is used in an almost religious sense). If someone were to state what's on that page in real life, I'd start backing away slowly. And the cult-like feel is only reinforced by the agile community's peculiar use of ordinary words such as "story".
Defer decisions until the last moment possible is one of the best things to do when making a tough decision. Its weird how we praise "quick decision makers." They are more or less simply gambling. Information tends to grow exponentially overtime. By waiting your chances of making a sound decision increase.
Agile always comes off as if it were intended for small consultancy firms who do specific jobs for individual customers. That honestly doesn't sound like a place I'd ever like to work at. I'd rather work for a company that puts out mass-market products with near-monopoly status and takes a stance of "you'll take what we give you". Basically something like Microsoft or Adobe. To me, agile is endless micromanagement. T…
"Agile" should have stopped at the Agile Manifesto. The principles described there are useful. Scrum sounds good in theory but in reality I have never seen it really work. Mostly it devolved into a micromanagement tool.
To a micromanager, everything is a micromanagement tool. You can't use methodology (or a pointed lack thereof) to change personality.
I cannot disagree more with this. You should make decisions as soon as you have a minimal amount of data. If you keep waiting the last possible moment, you will get a product that is the product of the least possible time.
If you make a decision too late, you have 100% failed.