Thanks for you insightful comments and for clarifying my misunderstanding of your presentation.

I think you highlight an important problem – are we engaged to adopt some Agile practices and get help a client get some improvements or to help them transform their group/organization. The statements “I don’t accept” and “I don’t tolerate” are consistent with a transformational approach. Sometimes clients understand and want this and at other times they don’t.

- Michael

P.S. I just had a question from someone reviewing my upcoming eBook on adoption and transformation ask me why I didn’t respond. I didn’t respond because, I consider Arlo’s comments on his own work to be correct and any discrepancies with my summary to be a mis-understanding on my part. I am responding now as there is apparently confusion around my lack of response.

Well, my world is full of legacy code – pretty much everone has a few million lines of really crap code, a very poor DB schema, no build process, no way to deploy a DB change, and political structures that make it impossible to ever remove anything from the schema.

Also, most of them are playing with offshoring, usually because their teams aren’t that effective anyway, so the powers that be might as well pay less to get that result.

My teams are filled with average programmers. They only become programming gods after a year or two of a good environment – it’s not that we have the chance at a good environment because we hire programming (or planning, or …) gods.

In other words, my world is your world.

The difference is that I look for what I can do to make that world effective. I don’t tolerate a lack of ability to change the database. I learn from others (eg, Ruby migrations, SqlAlchemy & Linq ORMs) how to make them malleable, and then do so. I don’t accept the politics; I ask why the assumption is present, then show how the tech advancements in the last 5-10 years make that deccision now invalid.

And distributed teams is just one more assumption that turns out to be changable, because the decision to distribute teams is based on assumptions that are not based in fact. At the time the decision was made, there was a legitimate reason. Usually, it’s because there was a problem (low productivity, typically), so they decide to lower costs. However, there’s another solution: improve the effectiveness of the team.

That’s the approach I take. It seems to work. In a lot of different contexts.

It’s really good for connecting the dots between a while range of stuff, and for a team fortunate to have onsight co located teams, complete control of the technology, and control of the political climate that may be all you need. Same goes with XP.

Problem is, I live in a place called reality. Working with legacy systems and people can’t be avoided, packaged software (think sap or peoplesoft) is a major component on most big business rodmaps. Offshore is huge.

Are these all ideal, no, but they are a huge part of the IT landscape.

You have taken kanban, something that can actually universally provide value to all of these contexts, and made it as narrowly applicable as XP. Kanban appeals to me becasue it can help even stodgy big business get on the path to agility.

This is not to say I don’t like your approach I think it’s a great practice for XP teams, I guess I think most XP teams are already quite good, if not excellent, I’m looking for help on getting others to become more XP like.