Project Mgmt / Ops BoF - Denver Drupalcon (Part 1)

First of all I’d like to thank everyone who took the time to come out to the BoF. In case you missed it, we had a fabulous turn out of almost 40 people! Below is part one of our discussion because so much information was collected, we need two posts to capture it all. But first, a quick, shameless, plug of my previous blog post... I’m looking for YOUR help to get more PM content at Drupalcon. During the BoF I asked questions like: - “What are some assumptions that we run into with clients, developers, even PM’s?” - "What kinds of challenges are you facing that are unique to Drupal projects?" - "How are you solving those issues?" In Part 2 we'll share some lessons learned feedback from the group, coupled with my own notes that I hope will be useful to you. Feel free to comment below to add your own feedback, resources or any other information I may have missed :)

Risks & Assumptions

One of the first things we talked about was risk. Working with Drupal means that there are a lot of things you just can’t control. Modules do anything I want! Modules are not miniature magic wands. Just because there is a module for widget X, it doesn’t mean that it’s going to do everything that your specific project may require, in the way you require it. Drupal does that out of the box! This is along the same lines as the previous comment. Just because Drupal has a lot of functionality out of the box, you shouldn't assume that custom code isn't needed. It all depends on what you want to do. Drupal is "easy" to build The downside to Drupal’s amazing functionality is a complex infrastructure that requires experience. I've heard that Drupal’s achilles heel is its learning curve. The other misunderstood aspect of this assumption is that experienced professionals always know what to do, which is simply not true. Drupal is a moving target (thanks to millions of contributors), and it requires research and testing to get the best from it. Module owners will always fix my bugs, like *now* The modules, though usually maintained by their creators, are often managed in a volunteer fashion. This means that we can’t assume the maintainer can drop everything to fix your bug, when he or she may have other critical bugs or even other modules to work on. The admin will be easy to use The admin has made leaps and bounds since day one, but it’s not perfect yet. A lot of modules could really benefit from a UX’ers loving attention. I know from experience that UX is on the radar of D8 development leaders, but we can’t expect it to be perfect in this environment. This means you may need to account for extra time to finesse the admin.

Estimation

It’s been said by many that Drupal estimation is an Art, not a Science... and they’re right. Here are a few things that make estimating work for Drupal challenging according to our group: Adaptation effort You can’t be sure about the effort to adapt a feature until you get in there. Contribution in the community has guidelines, but nothing is written in stone. The developer in question cannot predict how the code will react when adapted. At times it can be a real Pandora’s Box! Implementation effort This problem is along the same lines of adaptation. Because Drupal has a lot of cogs working together, sometimes you can’t be entirely sure of how to implement something. Research is required, and above all, testing to be sure that integration of your code will go smoothly. Managing options on a fixed budget Here’s an interesting one. There’s more than one way to implement requirements in Drupal FTW! Yes. It’s true, and this is really where having a strong User Experience (UX) team is useful. The good ones will know what kind of interaction design is necessary, and interface with your development team to find out which modules get close for the expected budget. It’s not an easy job, and it can take some time!

Design (Both technically and visually)

Drupal flexibility Unfortunately I don’t have the example we discussed in my notes (sad trombone), but Drupal is humble. It doesn’t assume that it knows what you should or should not do. It lets you decide that... and sometimes it’ll allow you architect solutions that aren’t in line with best practices. But don't fret, experts will know how to avoid the temptation of hacks in my experience. Design limitations The dreaded CMS curse. It can be so tempting to wield blocks to their fullest capacity until all you’ve got is block-y sites! It can be difficult to break out of the mold, and sometimes hard to find budget to customize code simply for a more original look and feel. UI inconsistencies Contributions from a variety of developers leads to varying individual styles. It's unavoidable since there isn’t a team of UI and UXers reviewing modules and patches for coherent treatment of visual and interaction elements... YET! (Hint hint, maybe someone should do this?)

Agile Methodology

Challenge #1: Explaining to the client what IT IS and why they WANT IT! Not all clients know what this really means. Trying to convince someone who loves waterfall that Agile will be better for them is *quite* the undertaking. Agile lends itself especially well to Drupal development because of the unpredictable nature of all things Drupal. Planning an entire project out from the start would mean essentially doing all your research upfront, and well, project managers are not omniscient! We can’t predict everything that will happen on a project, so waterfall plans were made to be re-planned anyway. Challenge #2: Managing the priority of the backlog Your backlog’s priority is going to change. It’s dependent on the client, the project’s progress, the usage of budget, the schedule and a dozen other things that impact decision making! Management of this is critical to success. Challenge #3: Clients confusing RFP with final scope Relying on an RFP is *RARELY* clear enough to replace good user experience research. Unless your RFP has already gone through a well-researched process of user and interaction analysis, with Drupal research included, don’t count on your RFP as a reference for project scope. So many other things factor into what “scope” is, not just “I need a dohickey”. How will users find your dohickey? How will they use it? Does it integrate into anything else? Can they share the dohickey? Import into it? Export out of it? These things need to be *researched* for the reasons I listed above from our chat. If the RFP is the scope of the project, (read: fixed scope), then flexibility with regard to budget and schedule are musts. I won’t go on, but rather consider writing an entire blog on this topic alone ;)

Testing in Drupal

Module Interaction It’s really tough to predict how two modules will interact, so testing also becomes crucial to success! Planning tests for different modules however is another challenge all together... Test content I’m starting to sound like a broken record, but the BoF conversation confirmed that yet again, experience in Drupal helps you with test planning and especially when automated testing is involved. The more automated tests you’ve developed in different modules, the more you’ll get a sense for where they will go wrong. Test strategy There was a wide variety of techniques being used when it comes to testing strategies to employ, and why. We discussed all three, and each has its merits, but I’m pretty sure no global consensus was reached! I think the moral of the story is: use all three, but use them wisely. There was also a fair bit of discussion about automated testing that peaked my interest since my own team is doing it as well. Lesons Learned coming in Part II of this blog that will attempt to solve some of these problems, so stay tuned!