Recently, I had to complete a research paper on distributed programming for the Agile 2006 Conference in a two day weekend. Russian XP expert and project leader, Anton Viktorov, flew into Boston from St. Petersburg to help write up the SirsiDynix project. Over 1,000,000 lines of code were written in record time by a set of Java teams distributed across Utah, Colorado, Canada and Russia. As a pair, we had widely divergent experience.
Starsoft Labs, the leading XP shop in Russia, was selected as a partner by Scrum company, SirsiDynix, to replace a large library system installed at over 12,500 sites worldwide. CTO Jack Blount, formerly COO of Borland, ran the project as a distributed Scrum of Scrums with individual teams distributed across geographies. Anton had been pair programming for years at StarSoft Labs with little experience writing research papers. I had over 20 years experience writing research papers and 13 years of Scrum. We decided we better pair write the paper to meet our two day deadline in the middle of a Boston blizzard. I did most of the wordsmithing as he framed the details of the project. The SirsiDynix/StarSoft 56-person distributed Java team was as productive as a 6 person colocated team using Scrum. Needless to say, we pair wrote the research paper in record time. You can judge the result for yourself at the ScrumAlliance site. See:
Sutherland, J., Viktorov, A., and Blount, J. (2006) Distributed Scrum: Agile Project Management with Outsourced Development Teams. Submitted to Agile 2006, Minneapolis, July 23-28.
http://scrumalliance.org/index.php/scrum_alliance/ for_everyone/resources/scrum_articles/distributed_ scrum_agile_project_management_with_outsourced_dev elopment
This is exactly what Scrum does which is why it is used on some open source projects.
"What I like about Linux and other F/OSS projects is that they deliver in what I'd call a "tactical" mode. Find the biggest annoyance and address that first. Deliver a good but not perfect feature. Then as you're starting work on new stuff, polish up the old. Deliver frequently, get the code in front of your customers, and let them tell you whether or not it works."
After reviewing the first 73 comments on this book review, there are some important background pieces of information missing.
SCRUM was invented by technical people for technical people by a Smalltalk team in 1993. The inventors were well steeped in Brooks Mythical Man Month. The challenge was to get mere mortals to function as well as Brooks Surgical Team, which IBM had shown was the highest productivity approach to software development. The solution came from the Japanese auto industry where they first applied the SCRUM term to new product development. Critics should read:
Takeuchi, Hirotaka and Nonaka, Ikujiro. 1986. The new new product development game. Harvard Business Review 64:1:137-146 (Jan/Feb), reprint no. 86116.
SCRUM is designed to eliminate all project management meetings and replace them with one technical meeting a day about 15 minutes long. It should be led by a technical leader, i.e. someone who does real coding. All decisions are made in the SCRUM.
SCRUM is designed to get management out of the way and to assign them tasks they are responsible to fix, i.e. get stuff out of the way that is blocking team progress. If they can't do that, the SCRUM should replace the managers.
SCRUM is designed to completely eliminate project leaders. Project planning and reporting including complete charts and graphs that will satisfy senior management is designed to be done in less than 10 minutes a day. Development input for project status should be restricted to less than 60 seconds a day. GANTT charts are verboten.
If a SCRUM doesn't do the above, it is not a good SCRUM. Management must give up some control in return for getting a better product faster. Anyone who has seen SCRUM really work will never go back.
Slashdot Mirror
Recently, I had to complete a research paper on distributed programming for the Agile 2006 Conference in a two day weekend. Russian XP expert and project leader, Anton Viktorov, flew into Boston from St. Petersburg to help write up the SirsiDynix project. Over 1,000,000 lines of code were written in record time by a set of Java teams distributed across Utah, Colorado, Canada and Russia. As a pair, we had widely divergent experience. Starsoft Labs, the leading XP shop in Russia, was selected as a partner by Scrum company, SirsiDynix, to replace a large library system installed at over 12,500 sites worldwide. CTO Jack Blount, formerly COO of Borland, ran the project as a distributed Scrum of Scrums with individual teams distributed across geographies. Anton had been pair programming for years at StarSoft Labs with little experience writing research papers. I had over 20 years experience writing research papers and 13 years of Scrum. We decided we better pair write the paper to meet our two day deadline in the middle of a Boston blizzard. I did most of the wordsmithing as he framed the details of the project. The SirsiDynix/StarSoft 56-person distributed Java team was as productive as a 6 person colocated team using Scrum. Needless to say, we pair wrote the research paper in record time. You can judge the result for yourself at the ScrumAlliance site. See: Sutherland, J., Viktorov, A., and Blount, J. (2006) Distributed Scrum: Agile Project Management with Outsourced Development Teams. Submitted to Agile 2006, Minneapolis, July 23-28. http://scrumalliance.org/index.php/scrum_alliance/ for_everyone/resources/scrum_articles/distributed_ scrum_agile_project_management_with_outsourced_dev elopment
This is exactly what Scrum does which is why it is used on some open source projects. "What I like about Linux and other F/OSS projects is that they deliver in what I'd call a "tactical" mode. Find the biggest annoyance and address that first. Deliver a good but not perfect feature. Then as you're starting work on new stuff, polish up the old. Deliver frequently, get the code in front of your customers, and let them tell you whether or not it works."
After reviewing the first 73 comments on this book review, there are some important background pieces of information missing.
SCRUM was invented by technical people for technical people by a Smalltalk team in 1993. The inventors were well steeped in Brooks Mythical Man Month. The challenge was to get mere mortals to function as well as Brooks Surgical Team, which IBM had shown was the highest productivity approach to software development. The solution came from the Japanese auto industry where they first applied the SCRUM term to new product development. Critics should read:
Takeuchi, Hirotaka and Nonaka, Ikujiro. 1986. The new new product development game. Harvard Business Review 64:1:137-146 (Jan/Feb), reprint no. 86116.
SCRUM is designed to eliminate all project management meetings and replace them with one technical meeting a day about 15 minutes long. It should be led by a technical leader, i.e. someone who does real coding. All decisions are made in the SCRUM.
SCRUM is designed to get management out of the way and to assign them tasks they are responsible to fix, i.e. get stuff out of the way that is blocking team progress. If they can't do that, the SCRUM should replace the managers.
SCRUM is designed to completely eliminate project leaders. Project planning and reporting including complete charts and graphs that will satisfy senior management is designed to be done in less than 10 minutes a day. Development input for project status should be restricted to less than 60 seconds a day. GANTT charts are verboten.
If a SCRUM doesn't do the above, it is not a good SCRUM. Management must give up some control in return for getting a better product faster. Anyone who has seen SCRUM really work will never go back.
Jeff Sutherland http://jeffsutherland.com/scrum