I get involved on anything at the task level and, if I do, it's usually to clarify a point), sometimes that freedom can be too much. Here's an analogy I use when talking to new recruits.
A friend of mine, who we'll call "Laura," was raised in a strict household with perhaps overbearing parents. When she turned 18, she packed her bags and flew across the country to attend her first year at college. Our alma mater is a liberal arts institution where really everything was "optional." Unlike larger universities, liberal arts programs individualize your learning experiences by encouraging you to take a wide variety of classes spanning multiple disciplines. Laura wasn't ready for this brave new world. She could go to class or she could skip. She could sleep all day or stay up all night. The freedom that this new paradigm offered was too much for her. She was used to strictly enforced 10 PM curfews, homework reviews by parents, and the like. In other words, she had no idea how to function without someone to tell her what to do and when to do it.
Sometimes people aren't ready for the freedom Scrum offers. Some people have had their tasks managed for years and wouldn't even know where to start without knowing their place on the load balancing chart (I'm talking people, not servers here). Or they may be so beat down from the constant supervision that they abuse their newfound freedom by simply doing nothing at all.
Your team may not be ready for self-organization, or it may experience many challenges before seeing the benefits. If you hired someone with the expectation that you'd be telling them how to do their tasks and then you ask them to figure it out on their own, they may not know how to do that and, ultimately, they may leave.
My colleague Dan Rawsthorne, PhD. makes a similar case. He asks the students in his class, "What's your business model? Are you in the business of keeping people busy, or are you in the business of producing product? If you're in the business of keeping people busy, don't bother with self-organization; in fact, don't bother with Scrum. Scrum is about producing product."
Another pitfall is the lack of an established career track for team members. To help avoid this particular pitfall, human resources departments need to develop a strong understanding of Scrum principles and play a role in the transformation process. Usually when I tell people that, they're surprised to hear it, but developing opportunities for professional growth and advancement-within a framework that values teamwork, not individual performance-is necessary for talent retention and satisfaction. Team members are team members, so how can they advance in the organization or earn more money? Those questions should be answered by the human resources department. If you're interested in reading more about Scrum and HR, I recently wrote a piece on the topic for the Scrum Alliance here.
As you can see, the Scrum framework is a carefully constructed system that relies on its own authoritative checks and balances and distribution of labor as much as common sense and human psychology. Not only does every role work to maximize the productivity of the other two, but is, in turn, supported by the other two roles, as well. In the case of the team, it is aided by the ScrumMaster, who helps enforce the rules of the road, encourages the use of agile engineering practices, and radiates metrics, progress, and impediments, and the Product Owner, who articulates the vision for the product to