Ron Jeffries, one of the capital “A” Agile people, provides a great example of context-imperial talk in his critique of the context-driven approach to methodology:
Well, my dear little children, I’ve got bad news for you. It is your precious context that is holding you back. It is your C-level Exeuctives and high-level managers who can’t delegate real responsibility and authority to their people. It is your product people who are too busy to explain what really needs to be done. It is your facilities people who can’t make a workspace fit to work in. It is your programmers who won’t learn the techniques necessary to succeed. It is your managers and product owners who keep increasing pressure until any focus on quality is driven out of the project.
There is an absolute minimum of practice that must be in place in order for Scrum or XP or any fom of Agile to succeed. There are many other elements of practice that will need to be put in place. And yes, the context will matter … and most commonly, if you really want to be successful, it is the context that has to change.
Wow, he even addresses us as children! That completes the picture nicely. (The context-imperial approach to process generally involves appeals to authority, or a presumption of authority.) This is why I’m proud to be a part of the small “a” agile community, which is not about bowing to priests, but rather each of us developing our own judgment about agility.
Context-imperial methodology means changing problems to fit your favorite solutions. We are all a bit context-imperial (for instance, I prefer not to work in an environment where I’m expected dodge bullets). We are all a bit context-driven, too.
The interesting question is when should we change the problem and when should we try different solutions? For me, the starting point for an answer is skill. To develop skill is to develop both the judgment about context variables and ability to craft solutions for them.
It would help if Ron could explain the dynamics of project, as he sees them. It would help if he offered experience reports. It does NOT help for him to ridicule the notion that competent practitioners ought to evaluate and respond to what’s there and what’s happening on a project.
When Ron says there is an “absolute minimum of practice” that must be in for an agile project to succeed, I want to reply that I believe there is an absolute minimum of practice needed to have a competent opinion about things that are needed– and that in his post he does not achieve that minimum. I think part of that minimum is to understand what words like “practice” and “agile” and “success” can mean (recognizing they are malleable ideas). Part of it is to recognize that people can and have behaved in agile ways without any concept of agile or ability to explain what they do.
My style of development and testing is highly agile. I am agile in that I am prepared to question and rethink anything. I change and develop my methods. I may learn from packaged ideas like Extreme Programming, but I never follow them. Following is for novices who are under active supervision. Instead, I craft methods on a project by project basis, and I encourage other people to do that, as well. I take responsibility for my choices. That’s engineering for adults like us.