Option Matrix has been working over last 2 years for an IT solutions firm in Denmark that provides portal solutions to sports clubs
Option Matrix uses an adaptation of scrum process for Drupal development. Scrum all boils down to release complete software in short cycles (sprints) and prioritizing using business value. Those features who return the highest return on investment get higher on the list.
The development team ideally consists of experienced programmers who work closely together with the client and have short daily scrum stand ups in which everybody involved tells the other what he did yesterday, what he will be doing tomorrow and if there are things which block his/her progress.
I think most current web development studios started out using a waterfall process for their projects: quoting fixed price and trying to specify every aspect of the entire project in a (huge) technical document, wireframes and designs.
The problem with this approach and (drupal) web development is that for larger, more complex projects the entire scope of the project is unclear. There often are a lot of uncertainties and dependencies for functionality down the road.
Using scrum a deadline is never further then 3 weeks away. And you can oversee things a lot better for such a time span.
Also, related to planning, the typical “scrum board” (see picture) may seem old fashioned in this digital age, but I find it to be very help full. Glance at it and you will have an immediate overview of the status of the current sprint.
Every sprint, a complete shippable product is released. Something that is finished and actually usable. This is probably one of the best things about scrum: iterative development. We use GIT as a version control system and developers push code to a test server. At the end of each sprint, a demo (and retrospective) is performed and the client can accept (or reject) the result on a acceptation environment.
We sometimes had projects where at the start of “our part” of the project – building it – the company who did the projects is already working on something else and not available for iterations. (or unwilling because they already got paid for what they delivered). In Scrum, ideally, the (UX) designers are part of the team and only design the stuff which is needed for every iteration
Designers tend to have poor knowledge of the inner workings of Drupal – but we are experts. And scrum allows us to easily share this knowledge to the designers. There are a lot of design patterns in Drupal, and designers shouldn’t have to reinvent the wheel if a good solution is already available.
The daily stand up is short and sweet. Everybody gets to tell what’s done and it helps keeping everybody on the same page. Thanks to this daily standup, nasty surprises at the end of a sprint are impossible. The whole process is super-transparent and if somebody has got a problem with something, others can quickly help out. Another benefit of this is everybody get to learn from each other
The client will know what to expect thanks to the sprint planning (poker planning) at the beginning of each sprint (which includes the client) and the demo’s, retrospective and many contact moments.
While scrum is great, some things are harder. One of the biggest hurdles is convincing the client to use scrum. For clients who are unfamiliar with scrum it may sound really scary if they are used to waterfall. Another issue is the transition from waterfall. You will need to spend resources to learn and implement scrum in your team. And not everyone might be easily convinced. Also, people tend to stick with old habits and scrum requires quite a new mindset. We prepared by all reading a (thin) book about scrum and having someone over with a lot of experience with scrum (thanks)