Scrum is an Agile development framework that Jeff Sutherland invented at Easel Corporation in 1993. Jeff worked with Ken Schwaber to formalize Scrum at Scrum for Research Projects
Recently, a new ScrumMaster from Atlanta pointed out the project in the photos above is a medical research project at the U.S. Center for Disease Control. The EPM Solutions blog item by Lisa Grant has a nice description of how you can cut research time in half and increase innovation and collaboration with Scrum.I spent a lot of time this year at Johns Hopkins Applied Physics Laboratory where they invented GPS and many other innovations for military projects. The Los Alamos Nuclear Weapons Laboratory uses Scrum (scary thought). The secret is to timebox a research activity with clear entry and exit conditions. Often the exit condition is an answer to a question that will determine the next step in the research.
If I had to do another Ph.D. thesis, I would definitely use Scrum. I could cut the time in half and significantly improve the quality.
posted by Jeff Sutherland @ 4:22 AM
3 Comments:
Sounds like a reasonable approach when the project is a research project in entirety. But in case of Software Development if this option is left open it actually turns out to be a mini waterfall inside scrum where the team may go for analysis, design and actual development in successive sprints. Which, I believe is not right. Your thoughts??
You are right about this. A large distributed ScrumButt team using RUP in the elaboration phase successfully delivered nothing this year. An excellent implementation of ScrumButt with velocity zero.
I'm talking about professional research guys that are competent. In cases where software prototypes are needed for research they deliver them with good velocity along with the research tasks. I worked with a Palm team a couple of years ago where about a third of every Sprint had to be research tasks. They were one of the best Scrums I've seen in Silicon Valley and timeboxed all their research tasks to increase velocity.
The real issue for Spikes is you only do them when you do not know what needs to be done to do production code. They are rare for a good Scrum team unless you are working at Los Alamos Labs on nuclear weapons or Johns Hopkins Applied Physics Laboratory where you might work on the next generation of GPS systems.
Also these kind of spikes I'm talking about have nothing to do with analysis and design. They have to do with what (if anything) should you build, not how to build it.
Hi Jeff, nice post!
Some time ago I bloogged about my experience in using agile for research projects, you might be interested:
http://technocalifornia.blogspot.com/2008/06/agile-research.html
Post a Comment
<< Home