A typical problem in an organization "starting to be agile" is that some managers (typically middle managers) don't see where they fit into the new process. So in order to complete the transition successfully you need to have especially middle management in the plan. At a talk at Scrum Gathering 2008 it was mentioned that middle managers should be involved early and encouraged to participate in the process of identifying their new roles.
So what are these new roles? If we use Scrum as an example (because it is popular and has three well defined roles) it is obvious that managers typically don't are part of the team. They're manager and often cannot contribute to the sprint just like any other team member. Managers also typically dislikes being demoted to team members. They worked hard to be managers...
So many managers thinks Scrum master sounds like a new cool title for them. I think this is where many companies go wrong. The Scrum master is not a manager. It's a coach, facilitator and guardian of the process, the team and product owner. As such the Scrum master must be skilled and be really excited about the cause. Another warning. Even when the manager actually has the skills and desire a Scrum master needs it might still be a bad idea making him a Scrum master because of the risk that the team will hear him speak as a manager and not Scrum master hence "following orders" rather than "listening to advice".
So that leaves us with the product owner role. In my experience companies successfully adopting Scrum tend to make their former managers product owners. This way their old management backpack does not affect the team's evolution and also the managers are doing what they've always done; prioritizing and deciding what the team should do (but now in a new way).
Sometimes the manager is not skilled enough to be a product owner because someone else has more knowledge of customer requests and so on. Don't panic! In my experience people with good knowledge of what the customers really want often feel they have little or no time to spend with the team. So even though this is not an ideal scenario the former manager can step in as a product owner proxy when needed. You can also be assured that the team will come up with a list of impediments they cannot solve. So you as their former manager can come to their rescue help the team unblock some impediments.
And even if you're not the Scrum master nor the product owner you can still help the team by coaching them toward "better". For more tips on what managers can do read about daily stand-ups and impediment involvement.
Your favorite agile literature probably talks about the importance of defining what done means so everybody (team and product owner if we use Scrum terms) knows what we mean when we say something is done. And having a catchy acronym to remember what your definition of done is is in my opinion a good thing.
When I did my Scrum certification a few years ago I learned an acronym that was a suggestion for what done meant. The catchiness in this acronym is that it is the Swedish word for done:
Some teams come up with a number of team rules that are posted next to the task-board. The idea is to have a number of rules that everybody in the team are committed to follow. And there is typically one rule at the top:
Anybody can remove a rule they are not committed to at any time, this rule excluded.
I think this is a great exercise to force the team to talk about their expectations on each other. Because rules can be anything from detailed practices to general things. So the discussion is actually more important than the resulting list of rules in some cases.
An observation we made in our team when we recently had a team rule discussion is that the word "rule" implies a punishment when not followed. So in my opinion a better word for this exercise is "team values" because that's what we're discussing. A number of common values that the whole team have the same understanding of. Because if you just list a number of values without discussion the meaning, then different people with interpret them differently. So what kind of values can a team come up with? Well here are a few examples:
Do you have more examples of values you think a team should consider?