Agile, IMHO, was meant to be a sort of zen-like "process-less process". After a few decades it became understood that software development wasn't working and do

Agile, IMHO, was meant to be a sort of zen-like "process-less process". After a few decades it became understood that software development wasn't working and doubling down on borrowed traditional engineering practices wasn't resulting in better software, only incredible delays in delivering broken software. Here's the manifesto: "We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more." This is deep stuff and an incredible (and rare) set of pragmatic philosophies set down by folks who'd been suffering through the industry for a while. Processes are intended to minimize risk and ensure reproduction of already achieved work. If you aren't making yet another copy of something that already exists, you don't want a process. (sorry if this comes off a little braggardly), I've been known to run incredibly effective teams that produce tons of work very quickly. I use what I call an "Agile-ish" approach based on some personal meditations on getting software done. I call this approach the "Get Shit Done" model. 1) Is this new work or reproduction of old work (should I explore and evolve or reproduce?) 2) If this is new work, the goals are set down as very coarse milestones with exit ramps in case things are working out. 3) If this is new work, work is broken down into a check-list in a pipeline with the following steps: To Do->Doing->Paused->Done Work is first filed as tickets in To Do. When it's being worked on it moves along to Doing. If, during "Doing", new work is identified, it's created and put into "To Do". If necessary the current work that's "blocked" is simply moved into "paused". Once Paused work is unblocked, it moved back into "Doing". It either finished, creates new work tasks or is paused again. Rinse and repeat. Kanban boards work pretty well for this, but you can do it with a spreadsheet in a pinch just fine. 4) If this is new work, work is only considered "Done" if it's checked in, tested and documented (and builds). Everybody hates it when they're doing it, everybody loves it when they need to figure something out later and the customers drool over getting rapid delivery of already documented, tested and validated stuff. This scales pretty well for teams of 1-to-100 (but starts to strain on the larger sizes). Teams are organized into hierarchies each with their own pipelines. Each team has a team-lead. I meet once a week with all the team leads and require all team leads to meet with their teams once a week. During crunches or abnormal events, we meet more often. This creates a cascading "clock" that identifies things that are taking too long and might need extra attention. I give team leads extraordinary autonomy to figure out the details at their level. This also gives people a week to be create and figure out ways around issues and problems. Team members can generally float or matrix if needed. Work moves along a general "discover, productionize, deploy" model. What's amazing about software is that it's almost always new work. If it's not new work, you still don't really need a process to reproduce it. Just copy the code into the new place, configure it and start it up. This is unlike any other engineering endeavor in human history and it takes entirely new ways of thinking to get it done. What I've found is that many many organization simply want to repurpose waterfall models and apply "Agile" sounding names to everything. I once turned down work because the customer had a 500+ page manual on their formal "Agile Software Process Methodology". No, no, no, NO. You don't get it. Here's another protip: Sprints are for engineering, Kanban is for Research. If you know what you are doing, use Sprints to force a development clock. If you don't know what you are doing and need to figure it out, Sprints just make everybody angry and create useless artificial pressure that accomplished nothing. If you're engineering, you already know what to do, Sprints help provide motivational energy.