I had a lovely dinner with Brian Marick and our spouses Saturday night. (Now that he's blogrolled me, I can't tease him about that. Thanks, Brian!) Two things made me reconsider the way I manage people while managing a project: things we discussed at dinner, and Brian's recent posting about the explicit role of the ScrumMaster, (from Brian's blog):
- “Removing the barriers between development and the customer so the customer directly drives development;
- “Teaching the customer how to maximize ROI and reach their objectives through Scrum;
- “Improving the lives of the development team by facilitating creativity and empowerment;
- “Improving the productivity of the development team in any way possible; and
- “Improving the engineering practices and tools so that each increment of functionality is potentially shippable.”
I haven't used Scrum in particular to make these things happen. But, I firmly believe in each point (even if you take out the “through Scrum” parts), and have been managing projects and workgroups that way since I can remember. I'm in the midst of writing down some of these lessons learned in an article for Crosstalk. If you'd like to review the article before 7/19/04, send me email, and I'll send it to you.
I'm having trouble with describing how to make the customer drive development work in a very large engineering organization that creates a mass-market product, where the product managers believe they don't have to sit with the developers to drive development. If you have experience changing the product managers' minds, please comment or send me email.