The SCRUM approach with Drupal for rapid product prototyping
author By Nilanjana
Blog

The SCRUM approach with Drupal for rapid product prototyping

author By Nilanjana Jun 15, 2008
scrum-approach-drupal-rapid-product-prototyping
Submit guest post

After several months of conceptualising, discussing, wireframing, and delaying, we finally started development of a pet product for the Tourism industry. Today, early (Sunday) morning, I create a product Blog and completed five posts on the same. It's currently Private, and we will make it Public once we have the product in some decent shape. Meanwhile, I wanted to write this blog about how we are using SCRUM to final move our asses on this product.

With Jacob using the SCRUM approach to build this product, we agreed to write a some user stories defining  what the different roles - "Site Owner" (the company who buys this product from Srijan), "End-Customer" (end-user of the product), and "Srijan's Admin" - would be able to perform with the website. Having done that, the team discussed the goals of the project, and in this process the stories were breaking down further.

This has been a very stimulating exercise for me, as I was being asked to set "specific" "measurable" functional priorities for deliveries with Sprints of one week each.  The idea is that we would take only very few set of things to achieve till the next Sprint - which was to be the next week. Now, I had shared the PPT made by our Information Architect - Navin Pangti - with Jacob, but I myself was unsure if that is what we wanted from the product, as we had changed the concepts a lot during earlier discussions, and prepared a Tag based approach, and those changed concepts were applied in the travel portal we are building for a client on TYPO3.

However, the ideas we had mulled over and over, during the last months, had a few things which could be termed as "core of the application". Now, for the first time, I was prioritising the core functionalities of the application, to as much detail as I could visualise - and to be honest, I am pretty bad at being able to visualise.

After the first Sprint, during the session in the second week, the great part of this exercise was that I, as a customer (Project Stakeholder) I could now "see" (and use) how the "Site Owner" would be able to create the key desired functionality from the product. Even after having done an extensive HTML wireframing exercise earlier, the functionality required and the priorities of development, were not as clear to me as it was now. Setting priorities for the Second Sprint, was an exciting feeling. The first time this product, in almost an year, is becoming a reality.

Jacob actually suggested that we should now soon have some Visual Design in place to help the developers define the template layouts. My argument was that we have done an extensive exercise in Visual Designs and HTML wireframes, and still never had real clarity on how this product would be built and how it would bring the value, we so want it to deliver to travel companies - and that this approach without too many wireframes and designs, and simply working with out-of-the-box Drupal modules (as much as possible) was a better exercise.

Ofcourse, he had a point - that developers need to visualise where and how the desired content needs to be displayed. To be honest, I was being able to define all these priorities and core funtionalities, because, we had done a LOT of exercise in defining the core concepts on the White-board, in designs, and finally in well-designed HTML wireframes.

So, I guess, a dual approach of HTML Wireframes, and rapid prototyping using a CMS like Drupal seems to be a great way to build products - products that the promoters/sponsors also do not know enough about during the the early stages of development - when they are in a place toying with a very interesting idea, but have far too many gaps and no specific way the product could shape up. SCRUM, and the idea of writing and prioritising user stories, for each Sprint, week after week, and staying completely involved in the product with the development team, is seeming to be a great way to build products. For sure, however, it needs patient sponsors, who have complete faith in the skills and ethical business practices of the development team.

Discussion

Write to us

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms Of Service apply. By submitting this form, you agree to our Privacy Policy.

See how our uniquely collaborative work style, can help you redesign your business.

Contact us