State of Practice: ScrumI participate in a number of forums where I am happy to help people understand agile methods and practices. I see dozens of questions every week asked (and often answered!) by people who are operating in a system they simply don't understand.
For instance, one very well-intended manager called a meeting with HR and consultants and leaders of teams to decide what a scrum master's duties are, and what a PO's duties are. Only the consultant had ever read the scrum guide. Everyone else was going to make it up. Not understanding that roles may migrate (and can even evaporate), the HR wanted to make the roles have specific meaning benefit-wise.
In an online forum, a manager asked "since release schedules are fixed, how do you make up for slippages in sprints." Fixed content and date? This is a question that no agile practitioner should ever ask, because the premise is non-agile.
I am a consultant, and my clients often have a scrum-ish implementation they're trying to bootstrap, or re-bootstrap, or re-re-bootstrap. Often they reach a state I call "compliance scrum" and never make any real improvement whatsoever in their quality or productivity and don't even retrospect after the first few sprints. They accept the earliest plateau, and even consider that first plateau to be the very definition of the process.
Scrum people are remarkably likely to be working from a page on a slide, or some word-of-mouth from a manager who has an employee who once attended a conference talk. They tend to feel that is enough exposure to be able to lead.
I suspect it is because scrum tends to be sold to management, who decree that everyone will change. As a result, most scrum practitioners are operating not out of self-interest and curiosity, but out of obligation and compliance.
Sadly, a similar fault is present where people become certified scrum masters in order to get certain kinds of jobs, not because they use, understand, and value the process. It is me-too-ism at its worst.
This is different from XP shops.
State of Practice: XPXP practitioners tend to have read XP Explained and XP Installed and a few of the other very good (and surprisingly short) books by Jeffries, Beck, etc. Many of them have read other books about managing and agility as well, like Shore & Warden''s Art of Agile Development.
I suspect it is because XP people tend to be interested in programming in a new way, curious about the lessons learned and techniques developed, and typically more involved in choosing their process for themselves.
Of course, there are far fewer XP shops, because people opt-in instead of being pushed in. It is not sold to managers, doesn't have dues, and doesn't have people who don't understand it selling it. It is quite intentionally a process, not a product.
So What?I'm not saying all scrum projects and all scrum practitioners are ignorant hacks. Only that the nature of the beast is that most people doing scrum are woefully undereducated and disinterested.
What I want to call out is that the biggest issue facing scrum teams I meet is that they don't understand the system they're operating. This is easily remedied.
Don't go to a big certified grand poobah meeting and spend several thousand dollars and miss a few weeks of work, and for God's sake don't devote weeks of your life to free labor for someone who isn't paying you.
Read something. I have given four good links on this page. Read the XP materials even if you are doing scrum. These books are all quite small (The Scrum Guide is about 16 pages in a free pdf file, XP Explained is under 250 pages, Art of Agile Development is the largest at 389 pages). You don't have to read any of them in a single sitting.
Know the manifesto. Read the manifesto. Read the principles. Don't ask questions in forums about how to most effectively violate the principles and values. Instead ask your company how you can adopt these more fully.
That's not a big bottom line. Just be informed about the process you are trying to implement. You will be amazed at how much of a difference it will make. It won't "smooth the process of compliance" at all, but it will take your team to a much higher level of performance.
Finally, stop trying to not be involved in the process you're using. If you're going to do it, do it all the way. The indecision of being half-agile is going to ruin your transition before it has a chance. Jump.