Drupal and Agile Development

I came across a presentation by Dustin Currie from Level Ten Interactive in Dallas, Texas on the topic of Drupal Agency Processes. I’ve embeded the video and included my notes on his presentation.

Mr. Currie states that human interactions are the key challenges to Web development. These include stating expectations, determining what needs to be done, etc. It is this premise from which he advocates the use of Agile methodologies for Web development as well as fixed budget, retainer and hourly contracts over fixed-price contracts. He also discusses the role of site builder in their organization and their approach to Drupal development.

He begins his presentation by citing “There is No Silver Bullet” a paper written by Fred Brooks in 1986, which according to Wikipedia, distinguishes between accidental and essential complexity in software projects. Accidental complexity is a side effect of the development process, while essential complexity represents the complexity of the problem actually being solved. While “no silver bullet,” Brooks argues that the greatest gains in software will come from solving essential complexity issues.

Mr. Currie presents the movement from assembly to C programming language as a solution of accidental complexity. He also presents the idea of moving from plain PHP to the Drupal Framework, and the movement from the Drupal Framework to the use of Views/CCK/Panels as other examples of reducing accidental complexity. I took it that by solving accidental complexity by using Drupal, it leaves the developer to address the essential complexities of project.

Next, Mr. Currie discusses the idea of project estimates, and that nobody is good at estimation. He touched on the idea of best case, average case and worst case estimates and that the further you are in to a project, the more accurate your projections. However, his main case is that estimates are only estimates and that you should not hold yourself accountable to them. If you do, you are essentially gambling, which is not good for business.

According to Mr. Currie, fixed bid projects are “the Devil.” This is because the developer shoulders nearly unlimited risk with limited rewards. The developer and project owner are put at an adversarial relationship because their interest are not aligned. Also, there is the issue of “technical debt,” where a poor decision now (possibly a shortcut) costs a lot more in the future. Fixed budget, hourly or retainer contracts solve these issues, while also assuring profitability now, not after the project is over.

Next, Mr. Currie introduced the idea of Agile, which was developed by a gathering of software developers. It was the “only things a group of dudes could agree on.”

  • Individual Interactions over processes and tools
  • Working Software over comprehensive documentation
  • Customer Collaboration over contract negotiation
  • Respond to Change over following a plan.

Agile is a process that works on projects that have changing requirements, include senior developers, use frameworks, have a small team (under 20) and have tasks that can be reasonably estimated.

One of the Agile methods is known as Scrum. While it has lots of terminology, Scrum is not that rigid. Scrum provides for the following:

  • Transparency with the team as well as the “product owner”
  • Process for better estimation. His organization uses relative numbers rather than hours to estimate tasks
  • Team decision making
  • Ways to measure capacity and thus profitability

Mr. Currie then dove into talking about the reasons why they use and like Drupal. These included the ability to easily post pages, blogs, podcasts and other materials and the ability to collaboratively edit this content. They also use Drupal to drive site traffic and leads and recognize the framework as a platform for building Web applications. They like Drupal because it has a high level of functionality.

Mr Currie then discussed the idea of site building and the role of Ste Builders within his organization. One idea is that Drupal sites are essentially recipes that rely heavily on contributed modules. This means that anyone can learn to be a Site Builder and that everyone in his organization is a site builder.

Next, Mr Currie discussed the strategy of using Agile and fixed budgets. This includes putting high value goals first. The idea is to put a significant percentage of high value features to be completed first in a huge project. This makes clients happy and reduces client anxiety. It is a better approach than focusing just on the interesting or hard problems first.

However, with all of these strategies, there is still “no silver bullet” Site building is great, but it solves accidental complexity. Drupal alone doesn’t make a project successful. Individuals and interactions are more important than processes and tools.

Mr. Currie then describes his team’s Drupal Processes, these include:

  • An onion approach to theming. They start with naked css tags and work from there into regions.
  • CVS updating (version control)
  • Source control for themes, custom code and exports
  • Notes on non-exportable admin changes after migrating from development stage to live
  • Code review for proper API and Drupal coding standards
  • Permanently evolving processes
  • A learning culture
  • Entire company of Site Builders
  • Recipe first, code last.

Finally, Mr. Currie summed up his presentation with the following:

  • Flexible and team driven processes can make successful projects
  • Rework contractual agreements and take approach to minimize risk, set expectations and align goals with clients
  • Success of a project lies in human interaction, not technical complexity. This is inherently hard.
  • Scrum is a project management wrapper that works for them.

Overall, I found a lot of interesting ideas in Mr. Currie’s presentation. Of particular interest to me is the idea staying away from fixed-price bids in favor of using budgets and billing hourly or by retainer. Most of our contracts have been fixed-price, although we also work on retainer and hourly for some clients.

I think the key drivers for whether to work on fixed price versus hourly are the relative complexity of the project and how much you know about it. For small Web design projects, I am confident in giving fixed price bids because we have a lot of experience with these jobs and can be confident in our estimates. However, once we get into more complex projects, we can’t possibility anticipate every issue that will arise, particularly if it is in an area that we haven’t worked before. There is also the issue of “scope creep” when the expectations of the project drift from original assumptions.

With Drupal, there is another factor which Mr. Currie touched upon in his presentation. This factor is that Drupal often provides a certain level of functionality and polish “out of the box.” For example, you can add a functional blog to a Drupal site by simply enabling a module. The question is, how much extra work do you want to invest to make that blog look and function exactly the way you want. Not to mention, how can you estimate how long that is going to take. Perhaps it is better to refine a site incrementally, giving the power to the client to decide what is “good enough” versus the money they want to spend.

While I’ve heard about Agile and Scrum methods, I have yet to dive deep in these processes. I’ve been thinking about how to improve Inforest Communications project management methodologies, and like the idea of using iterative processes. I certainly agree with the notion of human interaction being instrumental for the success of a project.