| My usual approach (coaching/mentoring agile teams for a few years) was to teach people how to fish, and try to become useless as a manager/coach/mentor on an everyday basis as soon as possible. If you have experience with software development processes, then you probably have an idea of how to run some/all of the required activities. It really depends on your situation, but to me the game was always to get people to take initiative themselves, then get out of the way, and to let the process develop itself (start with a loosely defined one, and see how much you can live without!). Communicating the high level goals and making sure everyone understands the reasoning behind choices, so they can make the correct decisions or raise the relevant questions when they are unsure of how to proceed (policies, breaking changes etc.). Everything was based around a basic Kanban approach with some Scrum-ish practices built in. Also process retrospectives at least bi-weekly, to improve the activities and discuss meta-level stuff. You're not really trying to improve unless you make bad choices some times. The most difficult part of the above was always to allow people to make mistakes, so they can learn on their own... So, with all of that in mind, make sure you understand whatever it is you / your team are supposed to achieve, read these: http://www.infoq.com/minibooks/kanban-scrum-minibook -- the free pdf http://en.wikipedia.org/wiki/Lean_software_development http://www.leanprimer.com/downloads/lean_primer.pdf Learn to recognize as many of these as you can (look at least at the Project management and Organizational section) http://en.wikipedia.org/wiki/Anti-pattern and try to minimize the amount in effect at any point in time. Optimize over time. Some things take a while to take root, and may require a lot of talking to be accepted. You might also be wrong :) Good luck! |