July 9th, 2006
On Being an Agile Critic
Boris Gloger and I ran our first public Agile Product Owner course last week in Cambridge, UK. It was an interesting experience, especially in that we had no actual product owners on the course. Instead we had a physicist, a software engineer, a CEO, an IT director, a partner, a scrum master, a consultant and a PhD student. The latter two were perhaps the closest to the role in terms of previous experience, but not engaged in that position at the current time. The material was of course essentially aimed at those immersed in the role, so its applicability was somewhat lost, and the course became rather academic in nature. Still, it was an interesting first run and most of the feedback at the end was very positive. Interestingly, one of the most skeptical and questioning people on the course gave us the best feedback. That always feels good. You can read some of the feedback comments here.
One of the roles we asked participants to take on after the course was that of critic. I have always felt that the Agile world lacks serious and informed critics in its midst and I have an aim to cultivate that skill on my courses. The participants were asked to write a three paragraph critique of the course in the style of a film or book review. Only one participant (to date) rose to the challenge, Paul Oldfield. Paul’s critique begins with “This course is good. It has the potential of being excellent, but it isn’t there yet.” and then goes on to pinpoint some areas of concern in the “usual ‘critic’ style guaranteed to get up the noses of authors, actors, presenters or whatever” (Paul’s words).
I have uploaded a PDF of Paul’s critique, somewhat nervously, but hey – it’s all about transparency, right? You can view the document here.
Do I agree with Paul’s criticisms? Not completely, but yes, in part. He and I have entered into a short dialog on some of the points, and perhaps Paul will comment further here. Whether or not I agree is really beside the point; Paul took the time to attempt a serious critique of the course, and that is what I was seeking with this exercise. I hope other trainers take up this idea. Scrum needs critics or it is in danger of becoming watered down and half-baked. All we have now it seems, are evangelists and skeptics (often uninformed skeptics). Criticism is an art, and we need to cultivate it among those entering the Agile field.
Boris and I plan to run the Agile Product Owner course again in the fall in Palo Alto, California and Manchester, UK. Criticism is optional (!)
July 9th, 2006 at 1:47 pm
Being a critic has a wide set of responsibilities, some of which I’m sure I don’t know about so I’m not a good critic yet. I find having time to reflect is important, so ‘interactive’ criticism has a different feel; more immediate but less well considered. Here I was definitely taking on a role, hoping Boris and Tobias would take it in good part. Criticism can be fun, both to give and to receive. Probably the main prerequisite for it being fun rather than just painful is having some reasonable understanding of what was being attempted. Yet having perfect understanding will not result in effective criticism, in my opinion. I try to make my reviews entertaining (this is the 3rd attempt – I’ll get better at that later, maybe?). Okay, I’m prepared to take it on the chin – anyone want to help me improve by criticising my crit?
I’d urge other attendees to attempt the exercise. My views are really important, of course – if you’re Me. In the ideal world, all courses would be tailored to My needs. If you want the course to be better for Your needs next time, do your duty to yourself and your colleagues, and respond.
Do I still stand by what I said? To some degree, yes. The niggling details were niggling details; they don’t matter. Some of the main concerns can be addressed directly; some are legitimate trade-offs whose symptoms might be capable of being addressed. I’m just putting my priorities on the backlog, and hoping to phrase the requirement at a level abstract enough to allow creative solutions.