Just from this morning, on the Lean Development mailing list.
The problem with roles – ANY roles – is that they tend to become a laundry list of stuff a person is expected to do, instead of a checklist that a team is responsible for looking into.
Note that this applies to Scrum roles too… In her words from the same email:
When I was product champion, I certainly never could do all of the things expected of even a product owner all by myself, but I did know how to get the right people on the team and get them engaged in the goal – so all of the necessary technical and marketing things happened.
On a recent project, I was trying to talk the (competent) business analyst into doing some .NET coding. He refused (though protesting that he’d be interested to do programming, which he had done not long ago), as he had been brought to be an analyst, not a coder. Conversely, the developers refused to help him with specs, because 1) they had gotten no help when they were overwhelmed with work, and 2) “the most efficient way to have things done is to have them done by experts” (as a side note, these developers also tried to get rid of the issues with the database by electing the analyst the official database keeper; it barely lasted one iteration). This was rather depressing to me, as I had been coaching the team for 6 months already.
Mary is an example to us all. We are priviledged to have her as program chair for Agile 2008.
