Building Bridges from Discovery to Launch

You did a Discovery but that doesn’t mean you have everything figured out. Once implementation starts, you’ll need a playbook to help bridge the gaps that inevitably arise throughout the project. We'll look at how Discovery phase activities and deliverables provide a foundation to build upon, and how to keep projects moving forward when you don't have all the answers up front.

21 things i learned with Twig & Drupal

A hands on Drupal8 Theming Twig extravaganza 

Theming in Drupal8 was a massive shift from phptemplate to twig, but its more than changing the syntax. We changed the way of thinking about Drupal theming. Drupal twig theming is easy to learn, powerful, flexible and overall as awesome as warm coffee on a rainy day. The downside is that all the things you learned in Drupal now have to be relearned - Yes it's by design.

Over the last 4 years we (the frontend drupaltwig group) we got one burning question from the Drupal community.

Managing Blue-Green Drupal Deployments

The promise of a blue-green deployment workflow is that you can more easily manage risk through high availability and a failover environment, but there are many moving parts to the process and it can seem daunting. We'll discuss the example blue-green workflows and how to integrate the process with Drupal deployments to reduce maintenance downtime, prevent the loss of data, and eliminate last minute surprises during the deployment.

Main topics:

Demystifying Decoupled Drupal

"Progressively Decoupled" and "Headless Drupal" are two terms that come up often when talking about approaches to make Drupal sites less page-centric, more dynamic, and part of a larger ecosystem. We'll discuss the benefits of decoupling Drupal and what it means for your content editors and your developers in the long term. Additionally, we will cover when and why you consider decoupling Drupal from other application layers.

Main topics:

Optimizing Your Code Development Workflow

If you are a solo developer, you might test on your local, merge to master, and then push to the live site (I'm not suggesting that workflow!). As your team grows and your project complexity increases, it makes sense to adjust your development workflow to handle working on lots of features in parallel, peer reviews, QA and automated testing, and keeping your "code publication pipeline" clear for emergencies.

There are many ways you can architect your workflow. We'll talk about:

Group an alternative to Organic Groups

In this session we'll explore the architecture and interface of Group, an entity based alternative to Organic Groups

Customized Software Project Management Workflows

Each project has its own workflow needs based on the the project's size and duration, the team's composition and experience, and the project management tools at hand. Whether you use Agile, Kanban, Waterfall, or some combination of these processes, it's important to have a PM workflow that suits your team and project.

In this session, we'll go over:

How Not to #Fail : Budget Goggles and The Time-Boxed Project"

The fact is: Most digital projects fail- either because the budget is overspent, time is exceeded, or user aren't happy. 
 Even though the project launched, the end result failed to achieve some of it objectives or ended up costing much more then expected.   

That doesn't need to be the case. By applying “budget goggles” and drilling down to a time-boxed list of features  we can creates a common language for all stakeholders , sets expectations early on and save the project from failing.  

Multiplier Effect: Case Studies in Distributions for Publishers

Join team members from Four Kitchens as they discuss the experience of migration and relaunch of the digital presence of two magazines: Successful Farming at and WOOD Magazine at

Built It, but Nobody Came: Avoiding Overengineering

Designing and building something that people need is completely different from implementing what they asked for. Engineers don't like to say no; helping is empowering and pride makes it difficult to back down. Product owners don't always have the context to understand how hard a feature is to implement and a throwaway request can add weeks to a project. We're all limited by our perspective, so the trick is to recognize what practically should be built. The goal isn't to say no, it should be to empower. Learn from our successes and mistakes!