3 ms·

I more or less liked it, but I was sort of confused by the sell... I do a lot of gigs where I play an agile-shmagile "coach", and much of what you wrote sounds

I more or less liked it, but I was sort of confused by the sell... I do a lot of gigs where I play an agile-shmagile "coach", and much of what you wrote sounds to me like you're in violent agreement with the rational portion of the "agile" community.

DanielBMarkham 19y ago
What I'm seeing is people dropping one onerous system -- say traditional waterfall -- and creating a new onerous system built around favorite authors and books. I think people get the "feeling" of agile but miss out on really how it is supposed to work. I mean, I'm seeing customers quoting books back and forth to each other -- even calling in famous authors to make decisions on what they should be doing. Famous authors, bless their hearts, don't know jack squat about any particular team or project and shouldn't be making blanket announcements about what teams "ought" to do. That's the same stuff they're trying to get away from. There are no perfect answers. I come from the rational side of agile as well. This is the first time I've seen so many people so excited about giving teams freedom that they're prepared to spell out exactly what those teams should do in order to be free. If you only concentrate on delivering code you miss the other value you add. Teams can't run on manifestos and slogans.
- projectileboy 19y ago
  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

What I'm seeing is people dropping one onerous system -- say traditional waterfall -- and creating a new onerous system built around favorite authors and books. I think people get the "feeling" of agile but miss out on really how it is supposed to work. I mean, I'm seeing customers quoting books back and forth to each other -- even calling in famous authors to make decisions on what they should be doing. Famous authors, bless their hearts, don't know jack squat about any particular team or project and shouldn't be making blanket announcements about what teams "ought" to do. That's the same stuff they're trying to get away from. There are no perfect answers. I come from the rational side of agile as well. This is the first time I've seen so many people so excited about giving teams freedom that they're prepared to spell out exactly what those teams should do in order to be free. If you only concentrate on delivering code you miss the other value you add. Teams can't run on manifestos and slogans.

projectileboy 19y ago
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)