3 ms·

Yeah, the whole cult around some of those authors is laughable; reminds of the Gilderoy Lockehart character from Harry Potter - those who can't do, write - and

Yeah, the whole cult around some of those authors is laughable; reminds of the Gilderoy Lockehart character from Harry Potter - those who can't do, write - and "teach". I did like the XP books by Kent Beck, though, because I thought they captured what for me is the most important aspect: you start with a simple process that seems reasonable, based in the values that are important to your organization. And then you adapt the process as you move along, without worrying about what some dude in a book said to do.

DanielBMarkham 19y ago
I think these guys have their heart in the right place, no doubt. I think what I see that is missing is organizational agility. There is a lot of organizational risk that just goes unanswered, and once the questions begin, these guys start sounding awful prescriptive. It's almost like they expect large organizations to run completely from a focus of one team, and one developer, instead of the entire structure. That might sell a lot of books to frustrated programmers on teams, but it kind of side-steps the whole issue of "how do we pick what to use or not use in a dynamic fashion? How dynamic can an organization be, anyway? Could you deploy to production different ways for different teams? Should project chartering be done with information that is also valuable to the team, like a business model? If you have running code and not enough people know what you are doing, do you stamp your feet and keep saying "integrated team of generalists" or do you acknowledge the fact that written communication is the only way your are going to reach some very important people?, etc." I don't see a lot of that type of thinking going on. I too do the coach thing, usually for big organizations. I also do the startup thing (which I love) with small teams. Care to guess which one I like more? (grin)

DanielBMarkham 19y ago

I think these guys have their heart in the right place, no doubt. I think what I see that is missing is organizational agility. There is a lot of organizational risk that just goes unanswered, and once the questions begin, these guys start sounding awful prescriptive. It's almost like they expect large organizations to run completely from a focus of one team, and one developer, instead of the entire structure. That might sell a lot of books to frustrated programmers on teams, but it kind of side-steps the whole issue of "how do we pick what to use or not use in a dynamic fashion? How dynamic can an organization be, anyway? Could you deploy to production different ways for different teams? Should project chartering be done with information that is also valuable to the team, like a business model? If you have running code and not enough people know what you are doing, do you stamp your feet and keep saying "integrated team of generalists" or do you acknowledge the fact that written communication is the only way your are going to reach some very important people?, etc." I don't see a lot of that type of thinking going on. I too do the coach thing, usually for big organizations. I also do the startup thing (which I love) with small teams. Care to guess which one I like more? (grin)