These are great questions. Whatever you do, it’s probably more about what people see as their responsibility. Individual flexibility and team autonomy will only help if the individuals and teams feel that their responsibility is to get features from concept to (production-ready) capability. If they see their responsibility as doing their bit (e.g. writing code or finding bugs) then flexibility and autonomy probably won’t make a lot of difference.I’d explore ways to influence the culture of teams so they feel a shared sense of responsibility for getting working-features into production as well as looking for people who are open to being flexible and building trust to enable autonomy.With the hiring process, I think it’s more a case of looking for people who are open to being flexible. This can be explored by posing questions to people that set a context where the candidate has to make a choice – do the thing most relevant to their job title or the thing that is most relevant to the team. If they choose the thing that is most relevant to their job title, explain the consequences – e.g. the release is delayed by 2 weeks. If they still don’t choose to do the thing that is most valuable in completing the feature, I’d ask them why. If in the process of talking themselves through their reasoning they still are fixated on what’s in their job description I’d be reaching the conclusion that they aren’t flexible. That doesn’t mean I wouldn’t hire them because they may bring skills to the team that the flexible people can learn from and eventually use.
Autonomy is about trust. If management expectations are that people will do the bare minimum they can get away with to get paid then the biggest problem will be building that trust in a way that doesn’t give the impression that ‘command and control’ is the reason for people working hard. Building trust is largely about transparency. Give people easy access and visibility of everything they could possibly want to know and they’ll have no reason to mistrust. This is partly what end-of-iteration demos, visible charts etc. are about. Some of it is also about trusting in the skill of the people. I’ve had many conversations where, even C-level execs, try to tell teams how they should do things. A good CTO is like a good scrum-master. They protect the teams and steer others towards prioritising ‘what’ people deliver and fiercely guard the team’s autonomy on how to deliver. In the same way that a CFO wouldn’t appreciate the CTO saying what accounting methods should be used, the CFO isn’t really in a position to tell the CTO what delivery methods should be used.
Some people may experience fear of having autonomy if they’re used to being told what to do all the time. This is another thing to consider. So, introducing autonomy can be done in small experiments with small and increasingly frequent change.
One key thing to look at is organisational values. I’d be asking: What are the actual values today (not the ones written down but the ones people actually share in)? What do we want them to be tomorrow? How do we state those values? Are they a list of expected behaviours or the values that drive those behaviours? How can we influence people to care more about the things that will make us more effective? How can we find more people who already share in our values?
Thanks for sharing the questions that crossed your mind… I hope some of my thoughts have helped anyone wondering similar things and I hope I’ve added, in some small way, to your own thoughts on the subject 
Additional resources:
On company values: /blog/2010/12/your-company-values-what/
On making small changes: /blog/2010/11/my-tack-on-effective-change/
On autonomy: http://www.youtube.com/watch?v=u6XAPnuFjJc
I recommend the related book “Drive” by Dan Pink