Scrum-based Project Management with Drupal - DIWD '09

Join Drupalize.Me to watch this video

Starting at just $35/month join Drupalize.Me and gain instant access to our entire video library.

Sign in Sign up
See something wrong with this video? Let us know.

Scrum-Based Project Management with Drupal - Diwd '09

0

Rob Purdie has acted as the project manager for many successful Drupal sites including Amnesty.com, Greenpeace.com, and Concern.net. He is currently overseeing the move of Economist.com to Drupal. Rob has also been key in popularizing the Scrum development methodology with Drupal. Come hear Rob talk about his techniques for ensuring Drupal success.

Additional answers and questions about this presentation. The answers are from Jerad Bitner, a Developer and Project Manager with Lullabot.

Hi there! I'm glad you enjoyed the talk. As a recently Certified Scrum Master and a member of scrum teams for the past couple of years, I can tell you that what typically happens on a Scrum project, and what is actually recommended by the masters, are not always the same thing. However, in the words of Mike Cohn, common sense trumps all! :) That being said, allow me to try to answer your questions based on my experience.

(1) Does scrum assume mature developers in terms of experience with technology since developers choose the tasks themselves from the sprint backlog, determine the time they are going to take on a task and are expected to be multi-functional?

Scrum typically assumes nothing about the members of a team. Each developer works at their own pace, and guestimates on tasks based on the available information at hand. If the information changes later, estimates and commitments can be adjusted on the fly. Of course, the more mature a developer is, the more accurate their estimates will probably be, but that is more of a determination in choosing your team, rather than an assumption made by the scrum framework.

(2) Whose responsibility is it to measure the efficiency in scrum teams [not the correctness of the task but is the amount of time taken per task is justified] and in what step in the framework is this considered?

It is the job of the Scrum Master to measure the efficiency of the of the team, typically by charting the velocity of the progress being made per Sprint. You can read more about gauging velocity with burndown charts here: http://www.scrum-breakfast.com/2008/08/towards-better-burn-down-chart.html

(3) Do we build project plans in scrum or are they completely called off in this framework?

A project plan becomes what we call a 'Product Backlog', which is basically a list of requirements for the system that are then prioritized by the 'Product Owner' and then broken down into tasks. Through this process you may not have an overall "this is how long our project is going to take", but through utilizing the burndown chart you have something which many find much more valuable, which is a more accurate telling of a project's progress. This may sound confusing, so I recommend reading a bit more here: http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms#1125

(4) Since this framework works best with organic development can projects that require proof of concept of require a prototype be considered Sprint '0"?

Sure! A Sprint can have whatever work within it that the team can agree upon and commit to, be that a particular feature, or a bare-bones prototype. The key goal of the scrum framework is not to define what is produced, but to help define the goals of a project and help accomplish those goals. Another key concept is that the team agrees to commit to a particular goal within a sprint. So if that goal is to come up with a prototype within the agreed upon sprint length, then that can certainly happen.

(5) Within this framework since functionality is being built as the project progresses, how can one manage overall schedule/cost creeps which is likely to happen particularly in fixed cost projects.

This is a tough one. Any sort of fixed cost project, no matter what approach you use can suffer from this. However, the scrum approach allows for constant re-evaluation of progress, requirements, and goals coupled with constant communication between the team members and the product owner. This leads to early indicators of these types of problems so that they can be dealt with sooner, and that there are no surprises for the client or the team. But with all projects, the magic is really in the contract, and Mike Cohn wrote an excellent article on writing contracts for agile development which you can read here: http://www.mountaingoatsoftware.com/articles/5-writing-contracts-for-agi...

(6) How can one manage pre-sales and project bidding in such projects since nothing (in terms of how much effort will be required) is known in advance. It is most likely that the original contract will be over shot. Are we saying that introducing scrum should do away with fixed bid contracts.

In the excellent article I mentioned above, Mike addresses some of these concerns quite nicely I think.

(7) Does this framework inherently assume the team is at its productive best both for the client and the company doing the development? Would it be correct to assume that sufficient levels of trust are expected from the client.

As I mentioned in your first question, scrum is more about working with what you got in a manner that benefits the team, and overall the project, rather than making assumptions about the team. As to the second part, yes, trust is a key factor in any relationship, and scrum tries to encourage this through the constant communication and levels of reporting a team's progress. There are certain responsibilities of a product owner/client that should be discussed before a project begins in order to ensure that trust is maintained throughout the project, and that they take this role seriously. Again I'll like to a great article that should help answer this question even better: http://www.mountaingoatsoftware.com/system/article/file/9/WantBetterSoft...

Thanks Jerad for sharing your thoughts and the links. On the link http://www.mountaingoatsoftware.com/articles/5-writing-contracts-for-agi is the entire team involved in the requirement gathering exercise or this process of capturing requirements as user stories and reaching an acceptable acceptance criteria for demoing and release is normally managed by the sales team - or the people defining the contract...perhaps a business analyst with domain expertise? Does this go into the proposal? Even though the presentation clearly shares on how the role of project manager changes in this framework , it would help if you can share your thoughts on this.

It doesn't always happen, but the whole team should be invited to this exercise. You'll find that when the team starts talking about the user stories, each individual is also thinking about the requirements for each one from their perspective, and each person may think of requirements that another person does not, which leads to a conversation between the team, and if more information is needed, with the client as well. These conversation bring up many of the different requirements and assumptions of the team members and what you end up with is more accurate estimates of what it takes to get a project completed because there are less assumptions involved.

You ask if these should go into the proposal. Well, a proposal and a contract are often times two different things. The user stories should go into the contract for sure, but it does seem like a lot of work to put into a proposal, especially if you do a lot of them. On the other hand, if you're putting this kind of work into a proposal, the client will feel more confident in the project and that you know what you're doing and so may be more likely to hire you for the contract. These are typical resource problems we all must weigh, and the only real solution I've found to this is to not do proposals, get your client to pay for a 'discovery' phase in which you come up with the requirements.

The key thing to keep in mind, is that in a "Scrum", any individual role (even sales) is less important than the whole team. What I mean, is that the sales should be able to rely on the rest of the team to help get a project; start to finish. By relying on a team to help define requirements up front, there is simply a better success rate than a sales guy throwing a project at a team and having a chance of the team thinking what the sales person agreed to is just not reasonable.

As I said, this doesn't always happen, but it is more ideal if it can. And there are plenty of sales reps out there who really understand their teams enough that they can get by without too many incorrect assumptions on behalf of their team. But if I were a sales guy, I'd certainly want my team backing me 100% for each and every proposal that went out my door.