也谈 SCRUM vs. XP
Just read an entry on Dong Bin's blog about SCRUM vs. XP, 忽然来了兴致也想讨论一下。
Scrum and XP are very popular concepts in agile development these days. I have been "SCRUMing" for about three years, two years at DoubleClick and one year at FreeWheel. Two completely different experiences: At DoubleClick, we switched from traditional water fall process to SCRUM overnight for a team of 600+ IT professionals across different locations, different countries. The engineering code base was a 9 years+ code base for the most part, with a lot of complexities and legacies. Whereas at FreeWheel, we cultivated SCRUM-like culture since day one, we also had the luxury of starting everything from scratch. I am not going to talk about everything I have learned — that is gonna take a while
, I just want to touch base on one specific point.
I think SCRUM and XP are not exclusive of each other, SCRUM is rather an implementation of XP, focusing more on cross function team communications. I think what SCRUM brings to the table is the communication framework it provided and the transparency it brings. Process doesn't get work done, people does. Good process is meant to help people get their work done. If you think being SCRUM will automatically get your job done, you are dead wrong. Implementing SCRUM process sets up a framework for people to communicate, communication builds trust and transparency, hence help people to get their work done. Trust and transparency are very important elements when working with cross location, cross function teams.
However, is communication alone going to get your work done? Obviously no. You actually have to do the work. Hence other aspects of XP, such as TDD, pair programming, continuous builds, integration automation. These core practices are designed to help you doing your work in an agile and sustainable fashion. The key principle in any agile development is to build your product in small increments. This means small and frequent releases. SCRUM promotes monthly releases, in order to do monthly releases successfully, you need continuous builds to provide immediate feedback when something is broken or you are on the wrong path, otherwise your month would fly by and you realize you did nothing. You need TDD and pair programming to reduce program error, otherwise the chances of having production error will be much higher due to continuous code modification. You need automated testing, otherwise you won't be able to finish all the regression test cases in time, and the quality of your release suffers. Etc, etc, etc.
If you just implement SCRUM without other aspects of XP, are you agile? I say no. You can still do monthly releases, following the SCRUM process religiously, however, your product quality may suffer, your engineering life style may suffer too, not sustainable. What if you implement XP without SCRUM? You maybe agile on development, however, the entire team may not be on the same page, you may constantly find yourself happily working on items are not as important to the product. The more complex the product, the more spread out development teams are, the more obvious the problem is. A solution is to introduce some sort of communication framework to help, SCRUM is one of them.
After all, the value of a company is about building a great product, and the key of building a great product is not just about building features, it is about building the right features at the right time.
Scrum and XP are very popular concepts in agile development these days. I have been "SCRUMing" for about three years, two years at DoubleClick and one year at FreeWheel. Two completely different experiences: At DoubleClick, we switched from traditional water fall process to SCRUM overnight for a team of 600+ IT professionals across different locations, different countries. The engineering code base was a 9 years+ code base for the most part, with a lot of complexities and legacies. Whereas at FreeWheel, we cultivated SCRUM-like culture since day one, we also had the luxury of starting everything from scratch. I am not going to talk about everything I have learned — that is gonna take a while
, I just want to touch base on one specific point. I think SCRUM and XP are not exclusive of each other, SCRUM is rather an implementation of XP, focusing more on cross function team communications. I think what SCRUM brings to the table is the communication framework it provided and the transparency it brings. Process doesn't get work done, people does. Good process is meant to help people get their work done. If you think being SCRUM will automatically get your job done, you are dead wrong. Implementing SCRUM process sets up a framework for people to communicate, communication builds trust and transparency, hence help people to get their work done. Trust and transparency are very important elements when working with cross location, cross function teams.
However, is communication alone going to get your work done? Obviously no. You actually have to do the work. Hence other aspects of XP, such as TDD, pair programming, continuous builds, integration automation. These core practices are designed to help you doing your work in an agile and sustainable fashion. The key principle in any agile development is to build your product in small increments. This means small and frequent releases. SCRUM promotes monthly releases, in order to do monthly releases successfully, you need continuous builds to provide immediate feedback when something is broken or you are on the wrong path, otherwise your month would fly by and you realize you did nothing. You need TDD and pair programming to reduce program error, otherwise the chances of having production error will be much higher due to continuous code modification. You need automated testing, otherwise you won't be able to finish all the regression test cases in time, and the quality of your release suffers. Etc, etc, etc.
If you just implement SCRUM without other aspects of XP, are you agile? I say no. You can still do monthly releases, following the SCRUM process religiously, however, your product quality may suffer, your engineering life style may suffer too, not sustainable. What if you implement XP without SCRUM? You maybe agile on development, however, the entire team may not be on the same page, you may constantly find yourself happily working on items are not as important to the product. The more complex the product, the more spread out development teams are, the more obvious the problem is. A solution is to introduce some sort of communication framework to help, SCRUM is one of them.
After all, the value of a company is about building a great product, and the key of building a great product is not just about building features, it is about building the right features at the right time.
恩，我们要吸xp和scrum之精华，没必要拼出个你死我活。
Reply to this
i am a little curious about how you practice scrum when the Team members are located at different places around the world. The time difference make it a pain, someone has to sacrifice, to stay late in the night doing conference calls?
Reply to this