-
Great article about Tobias Meyer. I don’t know why I never stopped to think about XP as being over a decade old, but he’s exactly right. Software craftsmanship is a great movement, but I’m concerned that without the “package”, there’s less for people to talk about.
XP may be getting long in the tooth, but it’s a set of principles that an organization looking to make the evolutionary change from non-Agile to Agile practices can rally behind. As much as the “do this, and this, and this” mentality can hinder teams, it’s also something that management can understand.
Working to help adopt Agile practices - both project management and software development - I believe that the team’s the easier collection of converts. They get it, they can see the empirical evidence that adopting XP practices, say, brings to a team. In this respect, I think Tobias is right on the money.
But management? I think it’s much harder to explain “We’re doing TDD and CI, with a little bit of pair programming, and mixing that with short iterations and cross-functional teams” than to be able to say the conversational short-hand “We’re adopting Scrum and XP.”
Will any team ever do pure Scrum? Pure XP? I doubt it, and again, I totally agree with Tobias on this point. Being able to have a team pick up the right collection of engineering practices is key to the success of an Agile team.
But, having the understanding and support of the organization as a whole - the conversational short-hand to be able to explain to a division President exactly how you’re developing software and, more importantly, why it’s so much better, is key.
“Scrum” and “XP” are labels, but labels can be important.
-
Watering Things Down Is Not Good For The Plants | xProgramming.com
I love reading Ron’s work. He’s so straightforward and to-the-point, and has a fantastic way to cut through the bull to the point we’re all talking around.
The recent conversations about Scrum and engineering practices, or between @michaelbolton and @thatqaguy are perfect examples of us getting lost in the words, and losing focus on the intent of what we’re all trying to. While it’s an interesting discussion from an academic perspective, how does any of it actually help us deliver more quality software?
