
For those considering Extreme Programming, this book provides no-nonsense advice on agile planning, development, delivery, and management taken from the authors' many years of experience. While plenty of books address the what and why of agile development, very few offer the information users can apply directly.
I encourage you to read 'the art of agile development' as they do provide some guidance around that.
But if there is micromanaging going on your org has ignored one of the core principles.
"Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get the job done"
There are places Agile is inappropriate or impossible and the book I suggested above calls that out.
While I like agile, I don't think of it as gospel.
But the people I see who bristle at the mention of it have probably only been exposed to the productized version.
Even if the methods don't work the above book provides alternatives that may help.
But I promise you, you haven't experienced an agile development environment if you believe the above.
Micromanaging is the the polar opposite of that collection of values and principles.
The benefits that people are claiming I find are true, so far. It’s different, but it has almost eliminated all lead and wait time for us which I consider to be a huge obstacle for effectiveness.
I got convinced by The book The Art of Agile Development (https://programmingbooks.dev/#the-art-of-agile-development) where he describes mob programming as an easy mode for collaboration.
We used the book Code with the Wisdom of the Crowd (https://programmingbooks.dev/more/#code-with-the-wisdom-of-t...) as a guide to learn of to do mob programming.
The answer is that you, alone, don't. By spending more than a small amount of time building out the simplest possible version of what the customer wants, you get their feedback along the way.
It's generally not true that you need many weeks, or even a full week, to build something you can show a user. Usually you're not being creative enough to figure out what to show your customer if you can't think of a way to provide value in a few days.
There are rare exceptions, but in the vast majority of cases you can build something for the user quickly, even when you initially think you can't.
This isn't even my opinion, it's the observed practice of a whole generation of developers. Read "The Art of Agile Development" if you want to know more, it's extremely helpful if you're trying to understand how to achieve the delivery I'm talking about.
Here is a list of books I'd recommend:
Tuned In Joel on Software Don't Make Me Think The Lean Startup The Mythical Man Month The Art of Innovation: Lessons in Creativity from IDEO The Design of Everyday Things Escape Velocity Competition Demystified The Art of Agile Development