Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 9 hours 56 min ago

Mediacurrent: Mediacurrent launches PwC CareerAdvisor on Drupal 8

23 August 2017 - 12:56pm
PwC PArtners with Mediacurrent: A Mini Case Study 

In January 2015, PwC US announced the launch of its new CareerAdvisor tool. Aimed to help students discover their professional goals and set themselves up for career success, the CareerAdvisor site provides links to reference articles and videos and other resources with career advice. After visitors create an account, they can track their progress with an interactive checklist of action items for career success and add a list of personal ToDos.

Categories: Drupal

Lullabot: The Hidden Costs of Decoupling

23 August 2017 - 12:00pm

Decoupled Drupal has been well understood at a technical level for many years now. While the implementation details vary, most Drupal teams can handle working on decoupled projects. However, we’ve heard the following from many of our clients:

  1. We want a decoupled site. Why is this web project so expensive compared to sites I worked on in the past?
  2. Why do our decoupled projects seem so unpredictable?
  3. If we decide to invest in decoupled technologies, what can we expect in return?

Let’s dive into these questions.

Why Can Decoupled Sites Cost More?

Before getting too much into the details of decoupled versus full-stack, I like to ask stakeholders:

“What does your website need to do today that it didn’t 5 years ago?”

Often, the answer is quite a lot! Live video, authenticated traffic, multiple mobile apps, and additional advertising deals all add to more requirements, more code, and more complexity. In many cases, the costs that are unique to decoupling are quite small compared to the costs imposed by the real business requirements.

However, I have worked on some projects where the shift to a decoupled architecture is fundamentally a technology shift to enable future improvements, but the initial build is very similar to the existing site. In those cases, there are some very specific costs of decoupled architectures.

Decoupling means forgoing Drupal functionality

Many contributed modules provide pre-built functionality we rely on for Drupal site builds. For example, the Quickedit module enables in-place editing of content. In a decoupled architecture, prepare to rewrite this functionality. Website preview (or even authenticated viewing of content) has to be built into every front end, instead of using the features we get for free with Drupal. Need UI localization? Content translation? Get ready for some custom code. Drupal has solved a lot of problems over the course of its evolution, so you don’t have to—unless you decouple.

Decoupling is shorthand for Service Oriented Architectures

For many organizations, a decoupled website is their first foray into Service Oriented Architectures. Most full-stack Drupal sites are a single application, with constrained integration points. In contrast, a decoupled Drupal site is best conceived of as a “content service,” accessed by many disparate consumers.

I’ve found that the “black-boxing” of a decoupled Drupal site is a common stumbling block for organizations and a driver behind the increased costs of decoupling. To properly abstract a system requires up-front systems design and development that doesn’t always fit within the time and budget constraints of a web project. Instead, internal details end up being encoded into the APIs Drupal exposes, or visual design is reflected in data structures, making future upgrades and redesigns much more expensive. Writing good APIs is hard! To do it well, you need a team who is capable of handling the responsibility—and those developers are harder to find and cost more.

Scalable systems and network effects

Once your team dives into decoupling Drupal, they are going to want to build more than just a single Drupal site and a single JavaScript application. For example, lullabot.com actually consists of five systems in production:

  1. Drupal for content management
  2. A CouchDB application to serve content over an API
  3. A second CouchDB application to support internal content preview
  4. A React app for the site front end
  5. Disqus for commenting

Compared to the sites our clients need, lullabot.com is a simple site. In other words, as you build, expect to be building a web of systems, and not just a “decoupled” website. It’s possible to have a consumer request Drupal content directly, especially in Drupal 8, but expect your tech teams to push for smaller “micro” services as they get used to decoupling.

Building and testing a network of systems requires a lot of focus and discipline. For example, I’ve worked with APIs that expose internal traces of exceptions instead of returning something usable to API consumers. Writing that error handling code on the service is important, but takes time! Is your team going to have the bandwidth to focus on building a robust API, or are they going to be focusing on the front-end features your stakeholders prioritize?

I’ve also seen decoupled systems end up requiring a ton of human intervention in day-to-day use. For example, I’ve worked with systems where not only is an API account created manually, but manual configuration is required on the API end to work properly. The API consumer is supposed to be abstracted from these details, but in the end, simple API calls are tightly coupled to the behind-the-scenes configuration. A manual set up might be OK for small numbers of clients, but try setting up 30 new clients at once, and a bottleneck forms around a few overworked developers.

Another common mistake is not to allow API consumers to test their integrations in “production.” Think about Amazon’s web services—even if your application is working from a QA instance, as far as Amazon is concerned there are only production API calls available. Forcing other teams to use your QA or sandbox instance means that they won’t be testing with production constraints, and they will have production-only bugs. It’s more difficult to think about clients creating test content in production—but if the API doesn’t have a good way to support that (such as with multiple accounts), then you’re missing a key set of functionality.

It’s also important to think about error conditions in a self-serve context. Any error returned by an API must make clear if the error is due to an error in the API, or the request made of the API. Server-side errors should be wired up to reporting and monitoring by the API team. I worked with one team where client-side errors triggered alerts and SMS notifications. This stopped the client-side QA team from doing any testing where users entered bad data beyond very specific cases. If the API had been built to validate inbound requests (instead of passing untrusted data through its whole application), this wouldn’t have been a problem.

There's a lot to think of when it comes to decoupled Drupal sites, but it’s the only way to build decoupled architectures that are scalable, and that lead to faster development. Otherwise, decoupling is going to be more expensive and slower, leaving your stakeholders unsatisfied.

Why are decoupled projects unpredictable?

When clients are struggling with decoupled projects, we’ve often found it’s not due to the technology at all. Instead, poor team structure and discipline lead to communication breakdowns that are compounded by decoupled architectures.

The team must be strong developers and testers

Building decoupled sites means teams have to be self-driving in terms of automated testing, documentation, and REST best practices. QA team members need to be familiar with testing outside of the browser if they are going to test APIs. If any of these components are missing, then sprints will start to become unpredictable. The riskiest scenario is where these best practices are known, but ignored due to stakeholders prioritizing “features.” Unlike one-off, full-stack architectures, there is little room to ignore these foundational techniques. If they’re ignored, expect the team to be more and more consumed by technical debt and hacking code instead of solving the actual difficult business problems of your project.

The organizational culture must prioritize reliable systems over human interactions

The real value in decoupled architectures comes not in the technology, but in the effects on how teams interact with each other. Ask yourself: when a new team wants to consume an API, where do they get their information? Is it primarily from project managers and lead developers, or documentation and code examples? Is your team focused on providing “exactly perfect” APIs for individual consumers, or a single reusable API? Are you beholden to a single knowledge holder?

This is often a struggle for teams, as it significantly redefines the role of project managers. Instead of knowing the who of different systems the organization provides, it refocuses on the what - documentation, SDKs, and examples. Contacting a person and scheduling a meeting becomes a last resort, not a first step. Remember, there’s no value in decoupling Drupal if you’ve just coupled yourself to a lead developer on another team.

Hosting complexity

One of the most common technological reasons driving a decoupled project is a desire to use nodejs, React, or other JavaScript technologies. Of course, this brings in an entire parallel stack of infrastructure that a team needs to support, including:

  • HTTP servers
  • Databases
  • Deployment scripts
  • Testing and automation tools
  • Caching and other performance tools
  • Monitoring
  • Local development for all of the above

On the Drupal side, we’ve seen many clients want to host with an application-specific host like Acquia or Pantheon, but neither of those support running JavaScript server-side. JavaScript-oriented hosts likewise don’t support PHP or Drupal well or at all. It can lead to some messy and fragile infrastructure setups.

All of this means that it’s very difficult for a team to estimate how long it will take to build out such an infrastructure, and maintenance after a launch can be unpredictable as well. Having strong DevOps expertise on hand (and not outsourced) is critical here.

Decoupled often means “use a bunch of new nodejs / JavaScript frameworks”

While server-side JavaScript seems to be settling down towards maturity nicely, the JavaScript ecosystem for building websites is reinventing itself every six months. React of today is not the same React of 18 months ago, especially when you start considering some of the tertiary libraries that fill in the gaps you need to make a real application. That’s fine, especially if your project is expected to take less than 6 months! However, if your timeline is closer to 12-18 months, it can be frustrating to stakeholders to see rework of components they thought were “done,” simply because some library is no longer supported.

What’s important here is to remember that this instability isn’t due to decoupling—it’s due to front-end architecture decisions. There’s nothing that stops a team from building a decoupled front-end in PHP with Twig, as another Drupal site, or anything else.

If we invest in Decoupled Drupal, what’s the payoff?

It’s not all doom and decoupled gloom. I’ve recommended and enjoyed working on decoupled projects in the past, and I continue to recommend them in discoveries with clients. Before you start decoupling, you need to know what your goals are.

A JavaScript front end?

If your only goal is to decouple Drupal so you can build a completely JavaScript-driven website front end, then simply doing the work will give you what you want. Infrastructure and JavaScript framework churn are most common stumbling blocks and not much else. If your team makes mistakes in the content API, it’s not like you have dozens of apps relying on it. Decouple and be happy!

Faster development?

To have faster site development in a decoupled context, a team needs to have enough developers so they can be experts in an area. Sure, the best JavaScript developers can work with PHP and Drupal but are they the most efficient at it? If your team is small and a set of “full-stack” developers, decoupling is going to add abstraction that slows everything down. I’ve found teams need to have at least 3 full-time developers to get efficiency improvements from decoupling. If your team is this size or larger, you can significantly reduce the time to launch new features, assuming everyone understands and follows best development practices.

Multichannel publishing?

Many teams I’ve worked with have approached decoupled Drupal not so much to use fancy JavaScript tools, but to “push” the website front end to be equal to all other apps consuming the same content. This is especially important when your CMS is driving not just a website and a single app, but multiple apps such as set-top TV boxes, game consoles, and even apps developed completely externally.

With full-stack Drupal, it’s easy to create and show content that is impossible to view on mobile or set-tops apps. By decoupling the Drupal front end, and using the same APIs as every other app, it forces CMS teams to develop with an API-first mentality. It puts all consumers on an equal playing field, simplifying the development effort in adding a new app or platform. That, on it’s own, might be a win for your organization.

Scaling large teams?

Most large Drupal sites, even enterprise sites, have somewhere between 5-10 active developers at a time. What if your team has the budget to grow to 30 or 50 developers?

In that case, decoupled Drupal is almost the only solution to keep individuals working smoothly. However, decoupled Drupal isn’t enough. Your team will need to completely adopt an SOA approach to building software. Otherwise, you’ll end up paying developers to build a feature that takes them months instead of days.

Decoupling with your eyes open

The most successful decoupled projects are those where everyone is on board—developers, QA, editorial, and stakeholders. It’s the attitude towards decoupling that can really push teams to the next level of capability. Decoupling is a technical architecture that doesn’t work well when the business isn’t buying in as well. It’s worth thinking about your competitors too—because if they are tech companies, odds are they are already investing in their teams and systems to fully embrace decoupling.

Categories: Drupal

Drupalize.Me: New Free Series: Coding Standards

23 August 2017 - 5:49am
Categories: Drupal

InternetDevels: Spam protection with Drupal 8 modules

23 August 2017 - 5:14am

Spam causes huge inconvenience to Internet users and headaches for site owners. Spam is one of reasons why you don’t need a comment section on your web resource. However, allowing your site visitors to post comments and any other content means communication and feedback. Allowing them to express their opinions and share their ideas on your site has its good sides as well. So it would be not right to get rid of this option all together. Luckily, Drupal can offer you a solution — and not just one.

Read more
Categories: Drupal

Abhishek Lal | GSoC Blog: Examples for Developer #12 Week of Coding

23 August 2017 - 2:17am
Examples for Developer #12 Week of Coding Abhishek Lal B Wed, 08/23/2017 - 14:47
Categories: Drupal

Amazee Labs: Tour de DrupAlps - Cycling the Alps to DrupalCon Vienna

23 August 2017 - 12:14am
Tour de DrupAlps - Cycling the Alps to DrupalCon Vienna

As per the extreme version of Tour de Drupal, my plan is to cycle from Switzerland to DrupalCon Vienna by crossing the Alps 6 times. The tour will take me over some of the most challenging Alp passes using my road cycle.

Josef Dabernig Wed, 08/23/2017 - 09:14

I’ll visit 5 different countries, including: Switzerland, Italy, Germany, Slovenia and Austria. Overcoming the Alps with the bicycle has been one of my long term dreams... Inspired by the sport achievements of my uncle, I am taking this challenge to see if I can make it from Switzerland to DrupalCon Vienna by taking some scenic and challenging detours over the Alps.

The final destination is DrupalCon Vienna which serves as the perfect goal because it’s my favorite conference and my hometown at the same time.

#DrupAlps in numbers

  • Days: 31
  • Distance: 2361 km
  • Total elevation gain: 57864 meters

Route

Here is how I planned out the route so far

Depending on weather and physical conditions, I will adapt the route along the way while riding.

Preparations

Over the last months, I have been riding various passes to get ready for the tour. Longer rides included St. Moritz - Splügenpass - Chur, Erstfeld - Oberalppass - Chur, and  Zurich - Vierwaldstättersee - Lucerne. In 2015, we cycled the Pyrenees as part of #TourDeDrupal Barcelona(1, 2, 3), early 2016 we cycled Sierra Nevada(1, 2) and later summer 2016 I cycled the biggest mountain of Austria on the Großglocknerstrasse.

Until now, I have no experience in cycling more than 3 consecutive days,  so I am really looking forward to seeing how it will go while being in the saddle for so many days in a row.

For DrupalCon Barcelona we cycled along the Pyrenees.

Amazee Extreme Challenge

“After three years of fulltime employment, our employees get one month off to free their mind and do something really extreme.”

I would like to thank Amazee for giving me this unique chance. Find out about what my colleagues are planning or have already accomplished at the Amazee Labs Extreme page.

DrupalCon Vienna

DrupalCon is the biggest Drupal conference, organized by the Drupal Association and will take place in Vienna from 26-29 September this year. I am especially looking forward to this one in my home town!

On Monday, there will be sprints, training sessions & summits organized by Drupal Austria.

Tuesday to Friday is packed with the official conference program and I am particularly excited about the site-building track, which I am a track chairing this year. Check out my blog post about what to expect from this week at DrupalCon.

Join Tour de Drupal

If you’d like to join my for the last few days of cycling, the last days are planned to be flat along the Danube river. For example, we plan to cycle from Linz to Krems on Saturday, 22nd of September. On Sunday, 23rd of September we go from Krems to Tulln where we will have a lunch break at the webshapers office. After that, we’ll cycle towards Vienna to arrive on Sunday afternoon.

Sign-up here and see my blog post for further details.

Follow me

Along the route, I will post regular updates about the ups and downs of the Tour de DrupAlps. To stay tuned, you can follow me here:

Categories: Drupal

Ben's SEO Blog: A Drupal SEO Expert and a Drupal Developer Hit the Mat

23 August 2017 - 12:01am

[Photo credits: Ben Finklea, Jan 2017. Photos captured from iPhone video shot at Texas Grappling Challenge Brazilian Jiu-Jitsu tournament in Cedar Park, Texas.]

My Drupal developer friends and I (like any friendship) don’t always see eye-to-eye. While we have much in common—we both want stylish, high-performing websites—in some areas our goals are different. This can create the appearance of conflict. However, after working through the issues (or hitting the mats, as they say in Brazilian Jiu-Jitsu), we can find common ground and mutual respect.

In Drupal 8 SEO, I lay out a list of modules that should be installed on your Drupal website to enhance SEO. I wrote this book for marketers and provide the step-by-step details you need to increase Google ranking, website traffic... Read the full article: A Drupal SEO Expert and a Drupal Developer Hit the Mat

Categories: Drupal

Dries Buytaert: Reservoir, a simple way to decouple Drupal

22 August 2017 - 1:52pm

Decoupled Drupal seems to be taking the world by storm. I'm currently in Sydney, and everyone I talked to so far, including the attendees at the Sydney Drupal User Group, is looking into decoupled Drupal. Digital agencies are experimenting with it on more projects, and there is even a new Decoupled Dev Days conference dedicated to the topic.

Roughly eight months ago, we asked ourselves in Acquia's Office of the CTO whether we could create a "headless" version of Drupal, optimized for integration with a variety of applications, channels and touchpoints. Such a version could help us build bridges with other developer communities working with different frameworks and programming languages, and the JavaScript community in particular.

I've been too busy with the transition at Acquia to blog about it in real time, but a few months ago, we released Reservoir. It's a Drupal-based content repository with all the necessary web service APIs needed to build decoupled front-end applications, be it a React application, an Ember front end, a native application, an augmented reality application, a Java or .NET application, or something completely different. You can even front-end it with a PHP application, something I hope to experiment with on my blog.

API-first distributions for Drupal like Reservoir and Contenta are a relatively new phenomenon but seem to be taking off rapidly. It's no surprise because an API-first approach is critical in a world where you have to operate agnostically across any channel and any form factor. I'm convinced that an API-first approach will be a critical addition to Drupal's future and could see a distribution like Reservoir or Contenta evolve to become a third installation profile for Drupal core (not formally decided).

Decoupled Drupal for both editors and developers The welcome screen after installing Reservoir.

The reason decoupled Drupal is taking off is that organizations are now grappling with a multitude of channels, including mobile applications, single-page JavaScript applications, IoT applications, digital signage, and content driven by augmented and virtual reality. Increasingly, organizations need a single place to house content.

What you want is an easy but powerful way for your editorial team to create and manage content, including administering advanced content models, content versioning, integrating media assets, translations, and more. All of that should be made easy through a great UI without having to involve a developer. This, incidentally, is aligned with Drupal 8's roadmap, in which we are focused on media management, workflows, layouts, and usability improvements through our outside-in work.

At the same time, you want to enable your developers to easily deliver that content to different devices, channels, and platforms. This means that the content needs to be available through APIs. This, too, is aligned with Drupal 8's roadmap, where we are focused on web services capabilities. Through Drupal's web service APIs, developers can build freely in different front-end technologies, such as Angular, React, Ember, and Swift, as well as Java and .NET. For developers, accomplishing this without the maintenance burden of a full Drupal site or the complexity of configuring standard Drupal to be decoupled is key.

API-first distributions like Reservoir keep Drupal's workflows and editorial UI intact but emphasize Drupal's web service APIs to return control to your developers. But with flexible content modeling and custom fields added to the equation, they also give more control over how editors can curate, combine, and remix content for different channels.

Success is getting to developer productivity faster Reservoir includes side-by-side previews of content in HTML and JSON API output.

The goal of a content repository should be to make it simple for developers to consume your content, including digital assets and translations, through a set of web service APIs. Success means that a developer can programmatically access your content within minutes.

Reservoir tries to achieve this in four ways:

  1. Easy on-boarding. Reservoir provides a welcome tour with helpful guidance to create and edit content, map out new content models, manage access control, and most importantly, introspect the web service APIs you'll need to consume to serve your applications.
  2. JSON API standard. Reservoir makes use of JSON API, which is the specification used for many APIs in JSON and adopted by the Ember and Ruby on Rails communities. Using a common standard means you can on-board your developers faster.
  3. Great API documentation. Reservoir ships with great API documentation thanks to OpenAPI, formerly known as Swagger, which is a specification for describing an API. If you're not happy with the default documentation, you can bring your own approach by using Reservoir's OpenAPI export.
  4. Libraries, references, and SDKs. With the Waterwheel ecosystem, a series of libraries, references, and SDKs for popular languages like JavaScript and Swift, developers can skip learning the APIs and go straight to integrating Drupal content in their applications.
Next steps for Reservoir API documentation auto-generated based on the content model built in Reservoir.

We have a lot of great plans for Reservoir moving forward. Reservoir has several items on its short-term roadmap, including GraphQL support. As an emerging industry standard for data queries, GraphQL is a query language I first highlighted in my 2015 Barcelona keynote; see my blog post on the future of decoupled Drupal for a quick demo video.

We also plan to expand API coverage by adding the ability to programmatically manipulate users, tags, and other crucial content elements. This means that developers will be able to build richer integrations.

While content such as articles, pages, and other custom content types can be consumed and manipulated via web services today, upstream in Drupal core, API support for things like Drupal's blocks, menus, and layouts is in the works. The ability to influence more of Drupal's internals from external applications will open the door to better custom editorial interfaces.

Conclusion

I'm excited about Reservoir, not just because of the promise API-first distributions hold for the Drupal community, but because it helps us reach developers of different stripes who just need a simple content back end, all the while keeping all of the content editing functionality that editorial teams take for granted.

We've put the Reservoir codebase on GitHub, where you can open an issue, create a pull request, or contribute to documentation. Reservoir only advances when you give us feedback, so please let us know what you think!

Special thanks to Preston So for contributions to this blog post and to Ted Bowman, Wim Leers, and Matt Grill for feedback during the writing process.

Categories: Drupal

DrupalEasy: How do I learn Drupal?  Let me count the ways.

22 August 2017 - 9:22am

Resources to learn Drupal are many and certainly vary in delivery, focus and quality. When you are trying to figure out the best way to train up, considerations like schedules, learning styles, and trainer reputations play pretty heavily. You also need to look at the program and compare it to what you already know, what you need to know, and what you should know to get into practice as quickly possible. One of the biggest obstacles is often finding, and then choosing the training program(s) that are right for you, and perhaps your team. But what if you didn’t have to choose?

Drupalize.Me and DrupalEasy are proud to announce that we are making it easier to get trained up in Drupal in a way that helps overcome challenges, meets needs, and addresses the different ways people learn. We are bundling our training programs and resources beginning with DrupalEasy’s Fall 2017 session of Drupal Career Online. The DCO will include access to all of the thousands of Drupalize.me tutorials during the 12-week course, and a deeply discounted subscription after graduation. Current Drupalize.Me subscribers will also receive a special Drupalize.Me tuition rate for this and any future sessions of the DCO.

Drupalize.Me’s Addison Berry came up with the partnership idea as a way to help the community grow by helping along the learning process of people who can more quickly become solid developers.  Addi says, “Any way we can make it easier, and better for people to get quality training to become developers is good for the community, and good for all of us.”  In addition to providing comprehensive Drupal training that focuses on best practices, Drupalize.Me and DrupalEasy share a love of building the Drupal talent base across the world.

Drupalize.Me provides a premium, membership-based training library of thousands of tutorials divided into specific pathways according to your learning goals.  It is trusted by users around the world, and backed by Lullabot, one of the top open source strategy, design, and development companies.

DrupalEasy has been offering instructor-led comprehensive Drupal career technical education (the first of its kind) programs since 2011, launching the 12-week, 132 hour Drupal Career Online program in 2015. The DCO ensures individuals and teams can rely on expert live instruction, office hours and mentorship, expansive learning resources, and a curriculum that thoughtfully stacks skills and emphasizes best practices to ensure graduates have the best possible foundation to become practicing Drupal developers.

The first session of Drupal Career Online that includes unfettered access to the Drupalize.Me’s tutorials in the Site Building, Theming and Development learning pathways begins October 2, with an application deadline of September 26th.  To learn more and get an idea of the DrupalEasy learning platform, sign up for one of two Taste of Drupal free information sessions in August and September or contact DrupalEasy.    



 

 

 

Categories: Drupal

Drupal Modules: The One Percent: Drupal Modules: The One Percent — Views Parity Row (video tutorial)

22 August 2017 - 7:55am
Drupal Modules: The One Percent — Views Parity Row (video tutorial) NonProfit Tue, 08/22/2017 - 09:55 Episode 32

Here is where we bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll look at Views Parity Row, a module which will allow the rows in your view to be rendered through different view modes.

Categories: Drupal

Agiledrop.com Blog: AGILEDROP: Web Accessibility in Drupal 8 – part 1

22 August 2017 - 12:19am
At AGILEDROP, we like to share our knowledge and experience with others. Our development director Bostjan Kovac did that at DrupalHeart Camp Zagreb with his session Web Accessibility in Drupal 8. We will look at this session and we will present it in two parts. This is the first part. The inspiration for his session (and of course this blog post) came from the fact that web accessibility was a demand when Bostjan worked on a couple of projects. He also went to one of the similar sessions on Drupal Camp in Vienna 2015 and decided to take a closer look at it. Today Drupal websites sites have… READ MORE
Categories: Drupal

PreviousNext: Scrum Masters are only effective when they are co-located with their teams

21 August 2017 - 9:18pm
Share:

Browsing through the interweb I happened across this bold statement a few weeks ago. A statement so bold, it inspired me to write a blog post in response.

by irma.kelly / 22 August 2017

Scrum Masters being co-located with their teams, sure it is the best and most favourable scenario for teams working on complex projects, but to go as far as to say that Scrum Masters are ONLY effective in this instance - nope. Sorry, I have to graciously disagree.

Obviously there are different challenges that come with facilitating Agile ceremonies and interacting with the team remotely as opposed to face-to-face. A completely different approach needs to be taken on my behalf to keep the team engine purring away.

Personally for me, the “different approach” I take with managing remote teams, as opposed to co-located teams is to ensure uber transparency and over-communication on my part in regards to the all of the work that the team currently have in-flight. On my part this includes:

  • Ensuring that work in flight includes “Acceptance Criteria” and a “Definition of Done” agreed to by both the team and the client. This ensures that both the client and the team have an agreed vision of the product we are building. More importantly, it removes the need to make assumptions about a solution on both sides

  • The use of an online and up-to-date Kanban board that both the client and the team can freely access

  • Complete honesty with the client and the team in regards to all aspects of the project. Especially during the trickier and stressful moments of project delivery. If something is starting to go pear shaped, call it out early - don’t hide it!​

There are a plethora of tools now available that help enable remote collaboration. I thought it might be worthwhile sharing some of the tools that the teams at PNX use to make remote collaboration simpler.

Slack / Go To Meetings / Google Hangouts

With a large percentage of our internal staff located across Australia, these are PNX’s go-to tools for remote collaboration. We utilise both GoToMeeting and Google Hangouts (depending on individual client preferences) as tools to enable our daily stand-ups with our clients. Daily stand-ups and the ability to quickly ask via a hangout or GoToMeeting has drastically reduced the amount of email correspondence between PNX and our clients. The result? A reduction in idle time, as questions can be answered relatively quickly instead of waiting for a reply via email.

Access to an online Kanban board

The ultimate in uber transparency. There is nothing more satisfying for an Agile Delivery Manager than to see tickets move to the right of the board. Likewise for our clients! Each ticket on the board details who the work is assigned to and the status of the task. At a glance, anyone with access to the project kanban board can see the status of work for a given sprint.

Google Sheets - My favourite go-to tool, when it comes to interactive Agile ceremonies

The most common question I’m asked about working with remote teams is “how do you facilitate an Agile ceremony like a Retrospective with a remote team?” My favourite go-to tool for this is Google Sheets. Before each retro, I spend a half hour putting the retro board together on a Sheet. I try and mix it up every retro as well, using different Retro techniques to keep things interesting.  I mark defined spaces on the sheet where comments are to go, and I share the sheet with the team. Facilitating the Retrospective via a video conference (if possible), I timebox the retro using a timer app shared on my desktop. The team then fill in the Google Sheet in real time. The virtual equivalent of walking up to a physical board, and placing a post-it up there! I have replaced all of the original text captured during the retro with lorem ipsum text. What's said in retro - stays in retro! We had a little fun with the below retro as you can see!

For sensitive conversations - A video conference (or the phone)

The tools above are handy for enabling remote collaboration but for sensitive conversations with a colleague or client in a remote location, a video conference (where you can see each other) is a must. Sensitive conversations are fraught with danger via chat or email and a neutral tone is difficult to convey when we’re in the thick of things. If a video conference is not possible, though, simply pick up the phone.

I’d love to hear about some of the tools you use with your team to enable remote working. What are your recommended tools of choice?

Tagged Remote Working

Posted by irma.kelly
Agile Delivery Manager

Dated 22 August 2017

Add new comment
Categories: Drupal

Chapter Three: How to Prevent Duplicate Terms During a Drupal 8 Migration

21 August 2017 - 8:26pm

In this post I will show a custom process plugin that I created to migrate taxonomy terms. The plugin handles the creation of new terms and prevents duplicates.

Below is a portion of the migration template. In the example, I am migrating new terms into keywords vocabulary via field_keywords field.

field_keywords: - plugin: existing_term # Destination (Drupal) vocabulary name vocabulary: keywords # Source query should return term name source: term_name - plugin: skip_on_empty method: row

This is the source code for the process plugin.

Categories: Drupal

Acquia Developer Center Blog: GovHack 2017: Interacting with Government Data

21 August 2017 - 8:26am

GovHack is an annual hackathon that runs in Australia and New Zealand, where participants have 46 hours to create innovative new products using the open data published by government bodies. It started in 2007 with a single event held in Canberra, and has now grown to more than 40 locations and 3,000 participants.

Acquia was thrilled to provide support to GovHack for a 2nd year in 2017.

Tags: acquia drupal planet
Categories: Drupal

Chromatic: How To: Link to Dynamic Routes in Drupal 8

21 August 2017 - 6:45am

Properly linking to pages with dynamic routes can be tricky. Here's how to do it properly.

Categories: Drupal

DrupalCon News: DrupalCon Takeaways - Chris Shattuck

21 August 2017 - 2:26am

This week, I spoke with Chris Shattuck (chrisshattuck), who has been part of the Drupal community for 10 years, and has attended 7 DrupalCons.

Categories: Drupal

Nuvole: Stable release for Config Split and Config Filter

21 August 2017 - 1:39am
Celebrating the 8.x-1.0 release of our configuration management helper modules.

One year ago we released the first public version of Config Split with the goal to simplify working with Drupal cores configuration management. The main motivation was to find a solution for having development modules in local environments and avoiding to deploy their configuration. To achieve this in the cleanest way possible we decided to interact with Drupal only during the configuration import and export operations by altering what is read from and written to the \Drupal\Core\Config\StorageInterface.

We quickly realized that this is a powerful way to interact with how Drupal sees the configuration to import and so we split off the code that does the heavy lifting into its own module and now Config Ignore and Config Role Split use the same mechanism to do their thing.

Config Split now has documentation pages you are welcome to contribute to and there will be a session at DrupalCon in Vienna in which I will show how it can be used to manage a sites configuration in interesting ways.

If you were an early adopter (pre beta3) but have not updated to a recent version, you will need to install Config Filter first or patch core. The workaround and legacy code has now been removed and the current code is going to be backwards compatible in the future. So if you use the APC class loader, make sure to clear the apc/apcu cache or you might get an error after updating.

Tags: Drupal 8Drupal PlanetDrupalConConfiguration Management
Categories: Drupal

Pages