Comments on: Investigating Scrum for Project Development
In the game of rugby, a scrum is a method of starting play. The name comes from scrummage, a modification of the word scrimmage.
In the product development domain, a scrum is a development process that defines the roles of participants along with project objectives organized in incremental, achievable sprints. It's often referred to as an agile framework because progress is made in short, well-defined bursts of activity, rather than with traditional planning methods (which tend to fall apart under the complexity scales of modern software development.)
This burst mode of operations also tends to fit well with common human behavior allowing team members to focus their attention on specific tasks and not be distracted with other projects or issues. I know from my own experience that this burst mode is how I personally operate to get anything done (in just about any domain, not just software.)
Here's a brief easy-to-read summary of the scrum method as posted on the Scrum Alliance. Scrum values "individuals and interactions over processes and tools, completed functionality over comprehensive documentation, ..."
Robert Muench recently suggested that this approach would work well for REBOL-related projects, and I'm very interested to give it a try. I'd like to get it started in the next few days... and we're going to need the help of all developers in the community to make this approach succeed.
I plan to say more about this very soon.
Sign me up
So Carl, by willing to try this, are you going to commit to a brief daily scrum where you have to update everyone on your status and any blockers as they come up? I nominate Petr to be the Scrum Master - he's been good at constantly prodding things along.
I have some questions regarding various roles, though. In general, there would be product management acting in the interest of the company (RT), the dev team, the Scrum Master and the product owner (representing the interest of the client (the wider dev community here?)).
Since a company can have multiple products (say a REBOL aimed at the general dev community and one customized for partners such as Qtask), there could be multiple owners.
The Scrum Master acts as an buffer helping to keep things running smoothly between management (both the product management and product owner) and dev team.
You fall into two, maybe three roles: product management, dev, and, possibly, product owner. I would say that you should try not to act as the latter if at all possible because you'd be assuming too many roles that, to some degree, have opposing interests. Maybe a combination of Henrik, Brian H and Cyphre (and Reichart?) could play the role of product owner (representing our interests) - being three(+) might help in clarifying their own dual roles in the process.
One of the products of a successful implementation of Scrum is good visibility into the status of the project. Even if things don't move any faster, having this would be welcomed by everyone, I'm sure.
If scrum requires daily/weekly meeetings, reportings, then I am worried a bit, or Carl would have to be really focused, and devoted to the methodology :-) We can try it.
But - history suggests, that we were not much successful at that. Remember Status udpates? Those provided community at least with some info, about what happened, and what is going to happen next, even if schedule slipped here or there. I found them kind of sufficient. But - those were abandoned in December.
But yes, let's try anything, that might get R3 released ASAP ....
I think the point is that sprints are short-term instead of long-term. It takes the bite out of long-term commitments that are impossible to keep up in the long run. While a sprint is short enough that it allows the contributors to make the commitment on a sprint-by-sprint basis, keep focused and get a fitting reward in a meaningful time frame.
So you'd have to get near-daily attention and status reports from the sprint master during a sprint, but outside of sprints there would be a relaxed commitment - and everyone would be aware of that.
The other thing that a sprint is supposed to deliver is shippable or potentially shippable software. So, there should hopefully be a new working build as a result of each sprint.
So, is QTAsk going to be used to represent the various parts of the projects so meetings are minimized yet project management is kept up-to-date on the happenings within the various activities?
Carl, you might want to look at the Blog Chat group on AltME to see further discussion on this topic.
In reply to above:
Regarding "daily scrum" you might also note that the method specifies people working at the same location. We will need to virtualize the scrum method, but I'd bet we're not the first to do so.
Regarding my role: just a team member, meaning, design and implementation. I'll pick a scrum master (I'm the "executive producer"), and we'll find others to fill the other roles.
Regarding scrum master: There's already something happening here, and I'll be say more after next week, if all goes well.
Regarding sprints: yes, it makes for shippable releases ever couple weeks with improved functionality.
Regarding Qtask: difficult to say. See my note on R3 Chat.
Adrian, I'll take a look at the Blog Chat group, but my time is fairly limited to read each message.
Someone might want to look at fire scrum http://firescrum.com This appears to be a complete yet somewhat simplified version of the scrum methods.
Seems needs a fair bit of support:
Red5 flash server
1. Progress is being made. A100 Host-Kit released for Cyphre and Robert to try out. One or two more items needed before general release of it.
2. SCRUM method is roughly being followed using AltME groups and checklists. Pretty simple, but works.
Wow, look at the size of the firescrum team. More that 40 people, no wonder they wrote it. BTW, the screenshots (other than the first one) don't seem to display.
Post a Comment:
You can post a comment here. Keep it on-topic.