How does one entice people to thrive by sitting and writing documentation? Rather, how do you reach out to a greater audience of developers that you could enlist for the betterment of your project? The classic model has been, organize a theme, have the “elders” show up, and get some work done. This sort of works.
The problem with this model is that I find a ton of people who basically show up to the sprint for a free tutorial. You get them up and running with your source code, hoping they contribute something useful, and you spend an awful amount of time doing so, because they have some weird configuration or are in way over their heads, and by the time you get them set up, the sprint is over. Now you just wasted your own time, and that of the project’s. The only person that benefitted from that situation is the sprinter, who can use the information he gathered to thrive.
The only way I have personally been able to contribute a serious amount of work is to hide in a corner and code for hours alone while everyone else is “sprinting”. Well, that sort of seems to negate the need for a sprint, since I can do that without the hands-on interaction that a sprint is supposed to encourage. So, when no one showed up at the last sprint, I had a bitter sweet taste in my mouth, but I closed about 20 todo items.
The main benefit I have seen from a sprint is that it is typically a gathering for the “elders”. The elders might talk about the future direction of a project. In the best case scenario they write some test code to see if an experimental idea will work or not. Sprinting is an incredibly valuable time for this, but often times the elders are held captive by (what we call in the climbing world) “gumbies” who capitalize on the elders’ knowledge of whatever project you are working on. Often times I will see the elders hide in another room to have a discussion, much in the same way I have done to get code done.
One solution we have come up with to deal with this problem is to institute a “babysitter.” This person is usually also the sprint organizer, and whether they know it
or not, their drive to have a successful sprint ties them to help the gumbies succeed, even if the chance of such an occurrence may be low.
I have played this role quite a few times, and while I am happy to answer questions at a sprint, I generally point people towards the docs and have them work through our examples. If they find a problem with the tutorials, they have just found something they can sprint on and be successful!
The other major benefit we get from sprinting is that it is an awesome venue for starting new things. Since the elders get together and sometimes create some test code, you are often left with a nice base to work off of. Many times I find myself working the next 3 or 4 evenings after a sprint trying to finish things out. This is often how new features are added to a project.
So, the question you have to ask when organizing a sprint is not only how to get people to show up, but how to get the “right” people to show up. I think for this we need to change the way we think about sprinting, and come up with a new methodology for organizing sprints.
This is part two of a four part series on sprinting. In the next segment, Sprint Organization: New Rules! I talk how we could improve sprinting using our current resources.