As you know, we work with Drupal. But this post is not about a particular technology, it's about an approach to the way we design and build a solution for IofC “social network” needs.
Social networks are a process, not a product, and by nature are dependent on their users' requirements. The 'Waterfall' approach we have been working with since I joined the development team does not sit comfortably with building sites based on the Drupal framework. I realized this while starting to draft our use cases. 'Waterfall' is good for a project
, designed and developed from scratch - but that is not our situation. We already have a lot of basic functionality in Drupal. Additionally we want to use ready-to-go community modules as much as possible.
This begs some questions: how much effort should we put into describing our uses cases? Shall we describe use cases that are already in place in Drupal (so that our use case documentation is complete)? And finally, if we intend to use community modules, how can we describe uses cases when we don't yet know modules suit our needs best?
The inability to answer these questions led me to a conclusion. We should change our approach from 'Waterfall' to 'Agile'.
Most projects start off with a waterfall approach - a plan, turned into a wire-frame, which turns into milestones, which turns into a final product, which then gets fixed because it's broken. There is nothing wrong with this approach. It's merely more expensive, and actually carries a higher risk than the agile approach, but it's also extremely conducive to risk containment for organizations.
Often in waterfall, you end up with a set of requirements that don't allow the application to start functioning until almost the release date. This is because all of the elements of the project have to come together in order for every element of the system to start working together - though this is not always the case. But often, you'll find that features that were laid out in a milestone, say, milestone one, require a great deal of the functionality to be built before that milestone is achievable.
Shipping such an application as a complete application without following an Agile development model is extremely risky.
Drupal is a social networking platform: it's built around features, not pages. It speaks many Web 2.0 technologies natively, such as AJAX, RSS, JSON, etc. All of this is built into the platform.
Because of its Web 2.0 and native functionality, Drupal often maps extremely easily into agile projects. With agile, you're often working with features. Features are micro units of work, similar to something like a micro-milestone. Each feature has a list of dependencies, responsible development party, input from the business, upfront planning, and probably will require some knowledge about the best approach for implementing it with Drupal.
What is agile?
Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project. The primary focus of agile methodology is defined in the four main bullet points of the Agile manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Collaboration over contract negotiation
- Responding to change over following a plan
Agile is a platform designed to encompass change, and built with the expectation that features and requirements will change, based on user input, throughout the entire project. This is a fairly accurate assumption, and the reason we have agile is that waterfall projects tend to break, or increase drastically in cost as change occurs.
With agile software development methodologies, you start by building the minimum amount of features required to ship the first basic feature of your site or project. The moment you have the minimal amount of functionality working you have a home page that can ship. Because you have no need for milestones, you're able to build things in the most logical order. This means you're able to have a working application virtually continuously, and technologies that work with agile, continuous integration and test driven development, are designed to support this process.
Note that we have just eliminated the risk that you will not ship the software, and in many cases you have just started the project when you ship a working application.
The fundamental value proposition of agile methodologies is to shift the planning into an ongoing planning that's done on a day-to-day basis in a structured fashion.
So, what are our next steps ?
The next step is to go through all of those features and list them out. Then we identify and sort them by priority. This ensures that we are working on your most critical features first, the features that are required to launch our sites in the shortest time possible. Once we have determined the highest value features, we start with implementation. Even though it looks simple, we now have a very clear idea of exactly what we want the project to look like, a very clear idea of what each be delivered first.
That's it.