My team has been using agile processes in bits and pieces. xplanner, scrum, sprints. Most of my team members consider daily scrum a headache and make up points to report. This is clearly wrong, but management wants this to keep themselves updated on the status of the project. I know this sounds like a Dear Lovedoctor question, but does your book cover how not to go overboard with agile and customize it to the project and organization ?
I can't speak for the book, but I still want to comment.
To me, this doesn't sound like "Agile going overboard", but like an Agile practice being *misused* for "non-Agile" purposes.
The purpose of the Daily Scrum (aka Stand Up Meeting) is *not* to provide status reports to the managers. It is to allow the team to *self-organize* and to raise *problems* that they need managements help for to solve.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Our book focuses on how to decide what will be valuable to customers and then deliver that value as rapidly as possible. This is done by complete teams that understand what is really important to customers and deliver value in minimum useful feature sets, as rapidly as possible.
All of the tools and practices that you hear about are not - necessarily - agile. What makes them agile is the repeated, reliable delivery of value by an engaged team. I suggest you look into Chapter 6 of our book, the chapter on people. It talks about what makes a team and how to think about engaging the team.
Think about a sporting team that plays enthusiastically after work or on weekends. How to you engage everyone on the team to want to play and do their best to win the game? Certainly not with status reports! You get the team in a huddle and have members give each other a pep talk on how the game is going and how to work together to win, and then everyone breaks from the huddle and gets on with the game. If that's now how the daily meetings work, then you may as well not hold them.
Author of Lean Software Development, Implementing Lean Software Development, and Leading Lean Software Development