Feb 01 2018
Feb 01
February 1st, 2018

Paragraphs is a powerful Drupal module that makes gives editors more flexibility in how they design and layout the content of their pages. However, they are special in that they make no sense without a host entity. If we talk about Paragraphs, it goes without saying that they are to be attached to other entities.
In Drupal 8, individual migrations are built around an entity type. That means we implement a single migration for each entity type. Sometimes we draw relationships between the element being imported and an already imported one of a different type, but we never handle the migration of both simultaneously.
Migrating Paragraphs needs to be done in at least two steps: 1) migrating entities of type Paragraph, and 2) migrating entities referencing imported Paragraph entities.

Migration of Paragraph entities

You can migrate Paragraph entities in a way very similar to the way of migrating every other entity type into Drupal 8. However, a very important caveat is making sure to use the right destination plugin, provided by the Entity Reference Revisions module:

destination: plugin: ‘entity_reference_revisions:paragraph’ default_bundle: paragraph_type destination:plugin:entity_reference_revisions:paragraphdefault_bundle:paragraph_type

This is critical because you can be tempted to use something more common like entity:paragraph which would make sense given that Paragraphs are entities. However, you didn’t configure your Paragraph reference field as a conventional Entity Reference one, but as an Entity reference revisions field, so you need to use an appropriate plugin.

An example of the core of a migration of Paragraph entities:

source: plugin: url data_fetcher_plugin: http data_parser_plugin: json urls: 'feed.url/endpoint' ids: id: type: integer item_selector: '/elements' fields: - name: id label: Id selector: /element_id - name: content label: Content selector: /element_content process: field_paragraph_type_content/value: content destination: plugin: 'entity_reference_revisions:paragraph' default_bundle: paragraph_type migration_dependencies: { } plugin:urldata_fetcher_plugin:httpdata_parser_plugin:jsonurls:'feed.url/endpoint'    type:integeritem_selector:'/elements'    name:id    label:Id    selector:/element_id    name:content    label:Content    selector:/element_contentfield_paragraph_type_content/value:contentdestination:plugin:'entity_reference_revisions:paragraph'default_bundle:paragraph_typemigration_dependencies:{  }

To give some context, this assumes the feed being consumed has a root level with an elements array filled with content arrays with properties like element_id and element_content, and we want to convert those content arrays into Paragraphs of type paragraph_type in Drupal, with the field_paragraph_type_content field storing the text that came from the element_content property.

Migration of the host entity type

Having imported the Paragraph entities already, we then need to import the host entities, attaching the appropriate Paragraphs to each one’s field_paragraph_type_content field. Typically this is accomplished by using the migration_lookup process plugin (formerly migration).

Every time an entity is imported, a row is created in the mapping table for that migration, with both the ID the entity has in the external source and the internal one it got after being imported. This way the migration keeps a correlation between both states of the data, for updating and other purposes.

The migration_lookup plugin takes an ID from an external source and tries to find an internal entity whose ID is linked to the external one in the mapping table, returning its ID in that case. After that, the entity reference field will be populated with that ID, effectively establishing a link between the entities in the Drupal side.

In the example below, the migration_lookup returns entity IDs and creates references to other Drupal entities through the field_event_schools field:

field_event_schools: plugin: iterator source: event_school process: target_id: plugin: migration_lookup migration: schools source: school_id field_event_schools:  plugin:iterator  source:event_school  process:    target_id:      plugin:migration_lookup      migration:schools      source:school_id

However, while references to nodes or terms basically consist of the ID of the referenced entity, when using the entity_reference_revisions destination plugin (as we did to import the Paragraph entities), two IDs are stored per entity. One is the entity ID and the other is the entity revision ID. That means the return of the migration_lookup processor is not an integer, but an array of them.

process: field_paragraph_type_content: plugin: iterator source: elements process: temporary_ids: plugin: migration_lookup migration: paragraphs_migration source: element_id target_id: plugin: extract source: '@temporary_ids' index: - 0 target_revision_id: plugin: extract source: '@temporary_ids' index: - 1 field_paragraph_type_content:  plugin:iterator  source:elements  process:    temporary_ids:      plugin:migration_lookup      migration:paragraphs_migration      source:element_id    target_id:      plugin:extract      source:'@temporary_ids'      index:        -0    target_revision_id:      plugin:extract      source:'@temporary_ids'      index:        -1

What we do then is, instead of just returning an array (it wouldn’t work obviously), use the extract process plugin with it to get the integer IDs needed to create an effective reference.

Summary

In summary, it’s important to remember that migrating Paragraphs is a two-step process at minimum. First, you must migrate entities of type Paragraph. Then you must migrate entities referencing those imported Paragraph entities.

More on Drupal 8

Top 5 Reasons to Migrate Your Site to Drupal 8

Creating your Emulsify 2.0 Starter Kit with Drush

Web Chef Joel Travieso
Joel Travieso

Joel focuses on the backend and architecture of web projects seeking to constantly improve by considering the latest developments of the art.

Web Chef Dev Experts
Development

Blog posts about backend engineering, frontend code work, programming tricks and tips, systems architecture, apps, APIs, microservices, and the technical side of Four Kitchens.

Read more Development
Jan 31 2018
Jan 31

Illustration of person scratching head at fork in the road

This is the first part in a series on how not to ruin your life on your next Drupal project. Sound extreme? Well, if you’ve ever suffered the crushing defeat of working your tail off on a lengthy project only to sit there at the end after launch feeling like you just came out of the opening night of Star Wars: The Phantom Menace (ie: severely disappointed and a bit confused), then you know that it is indeed extreme. We spend a majority of our day at work and when it’s not rewarding or energy-giving, it’s a real drag.

So what is the formula? Well, a blog post isn’t going to solve all your problems - but - there are certainly key approaches that we have taken that have helped us avoid catastrophe time and time again. Translation? We’ve managed an extremely high customer satisfaction rate for over two decades. What’s been happening here seems to be working so we pay a lot of attention to what it is exactly that we are doing and assess why we think it’s working. If you want a high-level bird's-eye view, check out our process page. We are going to get a bit downer and dirtier here though.

Ultimately, we want you to go home to your family at the end of the day saying “GUESS WHAT I DID AT WORK TODAY EVERYONE!!” (like we do) instead of “Can we just order pizza and go to bed at 7?”.

 We’ve identified 3 essential components to kicking a project off right, the first of which will be covered in this post. They are the following:

  1. Aggressive and Invested Requirements Gathering
  2. Relentless Ideation
  3. Atomic Preparation

So let’s start with Aggressive and Invested Requirements Gathering. We spent a lot of time thinking about this and I realized it comes down to the adjectives. Everyone knows (mostly) about requirements gathering, but it’s a minefield of unasked questions, unanswered questions, misconceptions, forgetfulness, and chaos. The solution? Take ownership of this baby from the beginning and treat it like it’s your project - it’s your passion - and do what it takes to nail it down. Getting answers that make your life easier, despite your suspicions that the client is maybe not thinking it through, doesn’t help anyone. Take no shortcuts and care about everything.

“Take ownership of this baby from the beginning.”

Here are 3 specific goals:

Assess priorities (theirs and yours!)

Priorities are key because we can easily get hung up on things that ultimately aren’t that important. On the flip side, there are things that are tremendously important to one of the two parties, and hence, it must be important to both. So the client says I care most about X, then Y, then Z. In your head you’re thinking “Yikes, Z has a huge unknown element that I’d like to solve quickly to understand the implications.” So talk about it. Repeat their priorities back to them and state your own and find that happy middle ground where you can pursue the project in an efficient and effective way while also focusing on what matters. It sounds simple, but unspoken expectations or concerns are a plague in project management.

Determining constraints (time, money, features, personnel)

I still love the age-old project management triangle that says that for any given project, you can choose 1 of the 3 key priorities in a project: time, money or features. This means that you can’t simply dictate the budget and the schedule and also expect a very rigid set of requirements. The problem is that despite even stating this, there is a lot of pressure from the client to set the expectation on all three and that simply isn’t possible. So it’s critical early on to sort out what the real constraints are. Ok, you would like this to stay under $50k. Is that a hard cap or could you go over if you felt it was worth it? So you want this launched by January 1st. Is that more of a clean-sounding date or is this tied to a fiscal year, or some other real deadline? Ok, so you want features X, Y and Z. Which of those would be deal breakers to not have? This kind of questioning is very helpful because early on in the build phase, you can make intelligent decisions about how and when to collaborate with the client since you know the significance of obstacles or changes of directions that impact these things.

The last thing I’m throwing on top of this triangle is the concept of personnel. We’ve found that knowing who your stakeholders are, who your end users are, who your editors and admins are - early on - is critical. I’ve literally had meetings where we’re deep into requirements and then I meet the person who has veto power over everything and the thing goes sideways. We’ve learned as well that there is a repeating sales cycle when new stakeholders arrive because convincing the last three people doesn’t mean you’ve convinced the next three. I’ve also had times where a stakeholder makes some critical decisions, but then after talking to the people “on the ground”, I find that he was simply just wrong on some of the day-to-day operations. It’s good to talk to everyone, but also find out each person’s role in the big picture. Often times we’ve found ourselves advocating on behalf of lower level employees who often bring up important and practical issues that decision-makers are often overlooking. It’s a delicate balance, but if the system isn’t welcomed and adopted well by it’s primary users, the project will sink even if the ones writing the checks are getting what they think they want.

Reading between the lines

This is tied to the item above in a lot of ways, but stands on it’s own as an important point. When you’ve done this long enough, you learn that most of what is asked for by a potential client is not always really the point. Often there is a hidden goal or motivation that has led to the formation of a feature request. Even if that request perfectly solves the need, it’s still important to discover that need because it can affect the implementation and guide the specifics. For example, if a request is made to let users download an export of tracking data, but you dig and find out that actually they’re just using this tool to turnaround and upload it into a remote system and it’s a bit of a pain, maybe building a web service is better where their system can talk directly to ours and users can step out of the daily grind. 

Conclusion

So in summary - gathering requirements the same way you date someone you’re thinking of marrying. Care about it and pursue it as if it’s the most important thing you’ve got going with an end goal of a lifetime of happiness.

Up Next: Running a Drupal project the right way: Part 2 - Relentless Ideation 

Free offer, talk to a seasoned Drupal expert.

Jan 31 2018
Jan 31

Illustration of person scratching head at fork in the road

This is the first part in a series on how not to ruin your life on your next Drupal project. Sound extreme? Well, if you’ve ever suffered the crushing defeat of working your tail off on a lengthy project only to sit there at the end after launch feeling like you just came out of the opening night of Star Wars: The Phantom Menace (ie: severely disappointed and a bit confused), then you know that it is indeed extreme. We spend a majority of our day at work and when it’s not rewarding or energy-giving, it’s a real drag.

So what is the formula? Well, a blog post isn’t going to solve all your problems - but - there are certainly key approaches that we have taken that have helped us avoid catastrophe time and time again. Translation? We’ve managed an extremely high customer satisfaction rate for over two decades. What’s been happening here seems to be working so we pay a lot of attention to what it is exactly that we are doing and assess why we think it’s working. If you want a high-level bird's-eye view, check out our process page. We are going to get a bit downer and dirtier here though.

Ultimately, we want you to go home to your family at the end of the day saying “GUESS WHAT I DID AT WORK TODAY EVERYONE!!” (like we do) instead of “Can we just order pizza and go to bed at 7?”.

 We’ve identified 3 essential components to kicking a project off right, the first of which will be covered in this post. They are the following:

  1. Aggressive and Invested Requirements Gathering
  2. Relentless Ideation
  3. Atomic Preparation

So let’s start with Aggressive and Invested Requirements Gathering. We spent a lot of time thinking about this and I realized it comes down to the adjectives. Everyone knows (mostly) about requirements gathering, but it’s a minefield of unasked questions, unanswered questions, misconceptions, forgetfulness, and chaos. The solution? Take ownership of this baby from the beginning and treat it like it’s your project - it’s your passion - and do what it takes to nail it down. Getting answers that make your life easier, despite your suspicions that the client is maybe not thinking it through, doesn’t help anyone. Take no shortcuts and care about everything.

“Take ownership of this baby from the beginning.”

Here are 3 specific goals:

Assess priorities (theirs and yours!)

Priorities are key because we can easily get hung up on things that ultimately aren’t that important. On the flip side, there are things that are tremendously important to one of the two parties, and hence, it must be important to both. So the client says I care most about X, then Y, then Z. In your head you’re thinking “Yikes, Z has a huge unknown element that I’d like to solve quickly to understand the implications.” So talk about it. Repeat their priorities back to them and state your own and find that happy middle ground where you can pursue the project in an efficient and effective way while also focusing on what matters. It sounds simple, but unspoken expectations or concerns are a plague in project management.

Determining constraints (time, money, features, personnel)

I still love the age-old project management triangle that says that for any given project, you can choose 1 of the 3 key priorities in a project: time, money or features. This means that you can’t simply dictate the budget and the schedule and also expect a very rigid set of requirements. The problem is that despite even stating this, there is a lot of pressure from the client to set the expectation on all three and that simply isn’t possible. So it’s critical early on to sort out what the real constraints are. Ok, you would like this to stay under $50k. Is that a hard cap or could you go over if you felt it was worth it? So you want this launched by January 1st. Is that more of a clean-sounding date or is this tied to a fiscal year, or some other real deadline? Ok, so you want features X, Y and Z. Which of those would be deal breakers to not have? This kind of questioning is very helpful because early on in the build phase, you can make intelligent decisions about how and when to collaborate with the client since you know the significance of obstacles or changes of directions that impact these things.

The last thing I’m throwing on top of this triangle is the concept of personnel. We’ve found that knowing who your stakeholders are, who your end users are, who your editors and admins are - early on - is critical. I’ve literally had meetings where we’re deep into requirements and then I meet the person who has veto power over everything and the thing goes sideways. We’ve learned as well that there is a repeating sales cycle when new stakeholders arrive because convincing the last three people doesn’t mean you’ve convinced the next three. I’ve also had times where a stakeholder makes some critical decisions, but then after talking to the people “on the ground”, I find that he was simply just wrong on some of the day-to-day operations. It’s good to talk to everyone, but also find out each person’s role in the big picture. Often times we’ve found ourselves advocating on behalf of lower level employees who often bring up important and practical issues that decision-makers are often overlooking. It’s a delicate balance, but if the system isn’t welcomed and adopted well by it’s primary users, the project will sink even if the ones writing the checks are getting what they think they want.

Reading between the lines

This is tied to the item above in a lot of ways, but stands on it’s own as an important point. When you’ve done this long enough, you learn that most of what is asked for by a potential client is not always really the point. Often there is a hidden goal or motivation that has led to the formation of a feature request. Even if that request perfectly solves the need, it’s still important to discover that need because it can affect the implementation and guide the specifics. For example, if a request is made to let users download an export of tracking data, but you dig and find out that actually they’re just using this tool to turnaround and upload it into a remote system and it’s a bit of a pain, maybe building a web service is better where their system can talk directly to ours and users can step out of the daily grind. 

Conclusion

So in summary - gathering requirements the same way you date someone you’re thinking of marrying. Care about it and pursue it as if it’s the most important thing you’ve got going with an end goal of a lifetime of happiness.

Up Next: Running a Drupal project the right way: Part 2 - Relentless Ideation 

Free offer, talk to a seasoned Drupal expert.

Jun 30 2016
Jun 30

We’ve found that the best Drupal agency is the one with a highly functioning, happy team. To be fair, remote or distributed agencies are happier and more productive anyways and that’s based on remote work surveys. But we’re going a step further with the goal of becoming the best Drupal agency, specifically by ensuring our team is a happy one.

Our Goal: Be Best Drupal Agency

There are a few important factors, features of wellness, which help make the best Drupal agency. For us, these are our fantastic Life Coach (working full-time for our team members), peer-determined semi-annual raises, results-based productivity that’s not measured in hours, and much more. How we approach work-life balance, organizational culture, time, and money have changed the way we do everything. Most importantly, it works.

We take employee satisfaction to an extreme

We hired a Life Coach full-time for our team members. This unique move has helped forward our holistic approach to instill job satisfaction, side step burnout, and enable healthy professional growth. Team members can contact our life coach to work on career path objectives, stress management, personal goal setting, life changes, social challenges, and much more.

This internal resource may seem bizarre to some, but it’s an option with benefits that go beyond productive workdays. A life coach fosters satisfaction and helps banish workplace indifference.

We’ve got an excellent kudos system. Our HR system integrates with Slack, which lets us give publically and receive pats on the back throughout the day. We encourage many notes of appreciation, recognizing monthly those who give and receive the most. This enablement creates a healthy and congratulatory environment within our organization.

In a professional environment like this, concealed positive feedback doesn’t always do the job. We’re building a positive culture for our team, with an emphasis on goals, personal development, and satisfaction.

Often when logging into our Slack system, we find personalized messages from the CEO and COO encouraging us to reach out to our leaders and peers if there’s something on our minds. It’s a great way to promote openness and remind everyone, daily, what we value here.

Need to Grow Your Team? Learn How

We make it a point to survey team engagement and belonging. Quarterly surveys give our team members opportunities to bring forward their sentiments. While our open door policy is always in effect, these questionnaires allow us to ensure organizationally Axelerant is feeling good.

Monthly 1-on-1’s are about career growth. Making improvements and milestones are imperative, but you could say that career growth is paramount. Team members discuss with leaders their future so they can visualize the stepping stones.

Being a best Drupal agency is one which enables career growth and skill refinement, and having these every month—for everyone—applies a strategy.

In these meetings, we discuss training opportunities, the possibilities of educational reimbursement and career path changes. If a team member is interested in another vertical or department, we can nurture a transition or part-time involvement.

Our progressive policies are benefits. Team members are encouraged to take advantage of leave, travel, and tech policies whenever applicable. Inside Axelerant, you’ll find travel and technology budgets (Wi-fi reimbursement and device replacement); group health insurance; and a generous 35-days leave plus maternity, sabbatical, and paternity leave options.

Days off are shareable with other team members. And these are paid, of course.

We do work differently

There’s been quite a bit of talk recently about burnout in the Drupal community. Work-life balance has been at the heart of this conversation, and at the crux of work-life balance you’ll find company policy. Let’s face it. Overworking, a culture of perpetual overtime, and burnout have a lot—if not everything—to do with an agency’s approach to productivity. The best Drupal agency or firm will put this into perspective and do the right thing.

Download Drupal Staff Augmentation Case Study

We don’t clock in or out. We deliver quality work on time and budget, without timesheets. Productivity is about results via Key Performance Indicators, not punch cards. When you work hard, efficiently, and you’re connected with the team, you achieve these quality results.

Of course, our approach is detailed; we’ve adopted and refined agile frameworks which support our self-organized, self-managed teams.

Agile powers how we get things done. Our performance tracking and collaborative efforts align with this approach. There are much more reasons for our Drupal success in delivery, including our competence with automation.

We set our work schedules. This scheduling is expressive of deep trust and responsibility, and it’s a serious testament. If top Drupal agencies want to keep top performing team members happy, allowing time for daily activities (whether these involve family, social, or spiritual norms) is a great start.

Axelerant’s work-life balance is in the hands of each team member.

This doesn’t mean that our employees aren’t up early in the morning or late at night. What this means is while some may choose to be up before the sun (or long after it’s gone), it’s up to them. We encourage them to do what’s best for themselves.

These agile and scheduling characteristics help foster our team’s wellness, as both are focused on the needs of the individual. We’ve found that this doesn’t hinder project success, in fact, it helps to ensure it.

Rigidity doesn’t work, and our teams have proven that they can be trusted with accountability and independence.

We handle finances differently

We’re transparent. In Axelerant, employees can view salaries, raises, and other details about company spending. These aren’t coveted secrets; figures are talked about openly. In this way, every employee is kept in the loop and encouraged to ask questions about our internal affairs. We keep ourselves honest, and we don’t mind talking about money.

We’re passionate about our work and our livelihood. Some firms and agencies don’t like to speak about money. We’re not like this. Let’s be frank, financial conversations centered on our employee’s needs aren’t signs of a lack of passion or selfishness. At Axelerant, we encourage openness.

Download: Continuous Discovery White Paper (PDF)

Semi-annual raises are peer-determined. Each team receives a raised budget based on profits. Next, the allocation of this amount is by honest team-level discussions. We’ve found that this system in conjunction with 1-on-1s, metrics, and engagement survey enables team recognition and promotes project feats. While this isn’t wholly competitive, it does encourage personal growth.

We’re paid on-time, in monthly lump sums. This consistency works perfectly for our employees when it comes to putting away savings and meeting monthly budgeting needs. Whereas some agency employees need to wait for several weeks or a couple of months for addressing their school loans, rent, food, and other financial concerns, Axelerant employees are already done during the first week of every month.

Being remote sure helps

Remote teams have the opportunity to put their best face forward. This doesn’t mean telecommuters are fake or disingenuous. Digital practitioners, despite contrary opinions, have the ability to interact in ways face-to-face team members can’t. They can compose themselves and avoid reactive, knee-jerk responses.

We’re talking about the unproductive kinds of office culture, the kinds that can weigh heavy in the workplace. These things can produce, over time, an unhappy (and by extension an unproductive) team. Remote work avoids this and other unpleasantness that can come with the brick and mortar.

But what’s more important is our people are free to be around their friends and family without hesitation. Working from a home office or a cafe liberates the team—gives them freedom

Being global changes everything

Axelerant is a globally distributed team (France, Taiwan, India, Israel, Japan, Australia, United States, and more to come). Some of us are from the major cities; others live in small towns—why does this matter? Because we’ve built a close-knit international team and have attained a diversity some can only dream of.

We’re a melting pot. Our cultural differences create a unique environment that enriches us all. The unique perspectives and insights every team member brings to Axelerant make our team dynamic. Diversity is the workplace gives organizations of all kinds a real advantage.

The importance of having this universal, a global mindset in today’s market can’t be undervalued. We’re world travelers, with a deep appreciation for the new. This connectedness is positive energy that charges Axelerant’s brand: we’re multicultural movers and boundary pushers.

There are global events and retreats happening back-to-back. Our annual retreat officially brings us all together for epicness, but we often see one another at international cons, camps, and other local meetups. This sponsored travel takes many of us to places we wouldn’t be visiting otherwise, broadening our horizons, and exposing us to the world even more.

We’re an international, 24-hour powerhouse. We use time zones to our advantage. This provides a tremendous advantage to our clients and enables us to get ahead of other agencies. At any time, somebody from Axelerant, somewhere in the world, is working hard at getting the right thing done.

It’s simple, happy people work hard

Happy employees are more productive. and happy, skilled production is what makes up the best Drupal agency.  We’ve found that satisfied employees with proper work-life balance are the best, bottom line. If you don’t have happy people, you’ve got a revolving door, an impassionate workforce, and indifference.

Unhappy people are indifferent. Unhappiness can breed indifference, and indifference is what will sink any agency. The day your people become unhappy is another day closer to them becoming unconcerned and eventually inactive.

If you want the best Drupal agency, find wellness

Beyond an extensive portfolio, and efficient Drupal services, a top Drupal agency will display healthy indications of a flourishing culture. The culture comes from people. If you’re looking for the best talent, which is what every organization in need of a Drupal vendor is looking for, then look for happy talent. Empowered teams produce powerful work. When more decision makers start to get this, we’ll all be in a better place.

These are just a few oddities that make us great. If you’re looking to hire or work for the best Drupal agency, these are some of the details you should be considering.

This article was originally published in November, 2015. It has since been updated.

Jun 16 2016
Jun 16

Drupal staffing for your projects is a unique challenge. And if you’re looking to hire for a project, Drupal staff augmentation may make the most sense for your organization. Drupal migration projects, site builds, support and maintenance, DevOps consultations—these all fall under this umbrella service.

Looking for the right people?

Unlike a direct hire or a complete outsource, growing your Drupal staff from the inside but with an external agency is retractable, scalable, affordable, and smart.

So What Should You Consider First?

How about what you’re most afraid of.

Failure. If you’ve been in the business long enough you know, you should be considering the ramifications first. It can’t be overstated: if you don’t bring in the talent to do it right, you need the time (and the budget) to do it over.

Signing off on an insourcing deal without looking beyond the pitch, the branding, or a brief preliminary review is never a good idea. With concerns duly noted, it’s time to focus on value.

Your Organization Wants Value, Right?

Then focus on what your organization values.

A natural next step after defining concerns should be determining values. Drupal staffing means you’re choosing the best Drupal agency to be your extension—a valued partner.

Get your Drupal Partner Checklist.

This partnership has to be on respective terms, conditions, and most of all shared values. Discerning the similarities or irreconcilable differences is what’s important here.

Drupal Staffing Partner Basics: 9 Values

Every organization is different but when it comes to values, there’s sure to be overlap. What does your organization value when it comes to staffing? Here are suggestions to get you thinking:

1. Integrity. When it comes to selecting a Drupal agency, open source integrity should be at the top of your list. You should never  partner with an organization you would publicly and proudly endorse.

Spot for signs of integrity. When they’ve contributed code, are they supporting it? Are they responding to posts in the issue queue? These indicators will teach you about the potential hire or the Drupal staffing organization offering their services.

2. Global Stewardship. Remember that Drupal, as an advanced open source framework, is powered by international teams of enthusiasts. Drupal is the result of focused, globally driven interconnectivity.

Do they support global evangelism? International Drupal event hosting, sponsorship, sessions, or identifiable support is something your organization should value. Drupal isn’t local, it’s global. To teach and to learn OS at these events is a sign of due diligence. The culture that has sprung up around the open source community is one of sharing, of giving back.

 3. Thought Leadership. Drupal staff augmentation agencies should cherish and exude thought leadership just as much as your organization. These will likely be different areas of thought leadership—you’re in different industries—but the value is the same.

Look for innovation in unique projects. Thought leadership isn’t always that recognizable. While an agency can be respected for forward thinking, it may not be applauded.

Competitive rhetoric dominates most industries, so it’s best to look through agency contributions, portfolios, case studies, and convention session topics.

4. Serious Discipline. Levels of due diligence and focus aren’t things that can be taught easily, right? It’s something you learn to appreciate in yourself and other people. As far as values go, this one is essential.

What’re some indicators of this? Work environments that promote discipline. Remote offices and telecommuting practices speak an awful lot about a staff’s discipline. Without this value—more of a virtue—nothing would get done.

Need to Grow Your Team? Learn How

5. Real Savings. You want to make a deal, and you want the better half of it. If your prospective partner values savings, so will they. There’s nothing wrong with healthy negotiation. The alternative is scrambling for your business; a reckless disregard for the worth of their services. Your organization has likely turned down bad business before. A staff augmentation partner would do the same.

Your partner should understand this too. You’ll know if they share this value with you if they refuse blatant low balling. Desperation isn’t a sign of fiscal responsibility.

See if there are any big names, big projects—launching or re-launching one of the top websites in the US should count. You can bet these projects played well for the Drupal staffing agency financially.

6. Timely Results. The bottom line is this: you want results that are on time and budget. Without results oriented success, you’ve got nothing—literally. This should be significant to all of your staff members and even more so your augmented ones.

There are things to look for. Check to see if your prospect publicly mentions deadlines, agency self-organization, and DevOps practices. These are signs that the agency values timely, results oriented success.

Next, you’re going to have to go beyond this and look into their project management processes. Agile frameworks. This is what you should be looking for.

7. Reputation. Poor standing within respective communities isn’t a good sign for obvious reasons. And the reputation the prospect has based on staff member reviews should be just as valued.

If there are challenges to the provider’s reputation—or yours—this may be indicative of a lack of care to respond to allegations of mismanagement or a hostile work environment.

What do the employees say? If there has been public, verifiable negligence against current or former team members (look at recent Glassdoor reviews and responses), then pass them by.

Public disgruntlement is a serious red flag when it comes to Drupal staff augmentation specifically. You want your staff augmentation team to be well treated, and you don’t need a tarnished reputation for partnering with a problem agency.

8. Saleability. Drupal staffing partners should be scalable. As your organization grows or your needs change, your staffing partner has to be able to adapt to suit you.

Digital platform essentials constantly shift. New features, adjustments, or entire new pages or sites need to be constructed. And sometimes rapidly depending on your industry.

Can they easily ramp up? Don’t forget to evaluate their bandwidth. Consider whether or not this Drupal staffing partner has the numbers. If they can’t flex when needed, move on.

It’s a good idea to get the rates and requirements that pertain to last-minute service increases in the open from the start. Surprise or emergency fees should be discussed first. Otherwise, you risk being taken advantage of when you need accessible and affordable help the most.

9. Likeability. It’s true that surveys show that likability is a key part of getting hired. There are some who believe this doesn’t matter, and that quantified, qualified results are the only things that do.

When it comes to partnerships involving teams, this should matter a whole lot. You’re going to be collaborating, perhaps on a daily basis.

Ask yourself: do I want to work with these people? Don’t go basing everything on first impressions, but consider the whole picture.

Teams should exude a fun, playful atmosphere. What you want are staff members who take their work seriously without taking themselves too seriously.

Drupal staffing is like hiring.

Consider what you’re hiring process is like and what it’s meant to do. When onboarding staff, hiring managers are looking to discover if their values line up with the company.

While it’s probably not smart to build a team of only the like-minded, creating a team with shared values when it comes to production, your industry, and accomplishments makes sense. So it is with Drupal staffing agencies that offer augmentation.

Interested in Staff Augmentation?

This piece was originally published in November, 2015. It has since been updated.

Apr 28 2016
Apr 28

What do the best agile Drupal support teams, plasma laser systems,

and flocks of birds have in common? 

 They’re self-organizing. And you’ve got to see the big picture to get it. I’ll show you.

agile drupal support

First off, I suppose should tell you that I’ve been studying self-organization as a scientific discipline for the last decade. It’s a good thing I like this stuff, right? During this 10 year journey I’ve jumped into various subjects: plasma laser systems, educational technology, robotics and computer simulations, Drupal project management, and of course: organizational dynamics.

What I found is that when you get the depths of each of these topics, it’s too easy to see the similarities. Each allows for a systemic view—the big picture.

Download: Continuous Discovery White Paper (PDF)

But before we get in too deep here, let’s cover some basics. A system is a collection of interacting components, each having its purpose. The what doesn’t matter; it’s about the how. It could be plasma particles in laser-plasma interactions, it could be a team working on a project, it could be functional groups interacting to form an organization, it could be a flock of birds flying together constantly maintaining distance. The list is endless.

What we’re talking about here are fixed systems. System that:

(A) Can produce the same outcomes in different ways in the same environment and different results in the same and different environments

(B) Can not only learn and adopt but also create

Agile Drupal support teams are great examples.

They are in effect flexible, scaleable systems that have to naturally adapt to function in a changing environment or perform within a constant environment. Agile facilitates evolution and adaption, meaning fully-agile Drupal teams can do this.

So how does this science work with agile Drupal teams?

Agility in Drupal project management is a simple way to look at project teams as self-organizing nonlinear systems. This system is a network of interacting autonomous entities, all working towards the project’s goal. Each team member is autonomous, and the goal is value-driven.

Download Drupal Staff Augmentation Case Study

As an example, Scrum which is an agile model with its three pillars of transparency is a framework that allows the teams to work towards the objective that makes the team most productive. Through this, team productivity is far more important than individual productivity. So while autonomy is taking place, collective achievement is the end-result.

The systemic view of agile teams also explains why clients are expected to be an active participant in the dynamics. The client is a component of the whole system which impacts the input flux, the project’s requirements, and output flux, the project’s releases, by defining priorities and needs.

Every kind of system needs a set of guiding rules.

Scrum, one kind of an agile technique framework for things like agile Drupal QA, is nothing but a set of rules that the project team as a system agrees to play by to meet their goals. Scrum isn’t a methodology—it’s a set of steps that have to be followed, like a manual.

The objective of any system is to improve continuously and emerge. Emergence here means achieving something that wouldn’t be possible independently. It takes an integrated team.

If we look at a project team, scrum does allow agile Drupal retrospectives as a tool or technique for continuous improvement. The main purpose of any environment where any system operates is to design interventions towards improved performance of the system.

Self-Organizing Drupal Support Teams?

So in this way, the best Drupal team can be a self-organizing system, and why not? The science does not limit the volume or size of the system. Perhaps a better word would be a self-organizing dynamic system, through constant retrospection and agility. You can bring stability to chaotic situations—or steep and changing demands or requirements—to meet a shared goal or organizational vision.

Today the discipline of System Dynamics is being used to model the software development life cycle, SDLC, processes we commonly use today. Or at least, that’s what we’re using successfully with our agile Drupal support teams. It works.

You can make this happen.

Applying agile and enabling self-organization might cause some growing pains at first. At Axelerant, we’re transitioning our content department to agile frameworks. It takes time. But for many organizations—perhaps yours?—the way teams go about creating things like dynamic software needs to change.

How?

Agencies with flexible Drupal services, centered on agile practices and self-organizing principals, can help bring this to you. Because enabling self-organization may not be an in-house option right now. But one thing is absolutely for certain—whether you partner with a team like ours of if you go about self-organizing yourself. Things will never be the same.

Want an agile Drupal support on your side?

This article was originally published on November 11, 2015. It has since been updated.

Karuna Batra

Karuna Batra

Karuna is Axelerant's Director of Delivery and a strategy team member. She focuses on evangelizing, institutionalizing, and auditing best practice processes via open source tools and appropriate governance structures for delivery based organizations. She's more importantly a loving aunt and Indian foothills trekker.

Aug 12 2015
Aug 12

In the first article in our series we talked about how styleguide-driven development (SDD) and decoupling both serve many of the same goals, and SDD can do so in a way that avoids the many challenges of decoupling.  Now we’ll get deeper into the details of SDD and how we use it to build a website.

This post will walk you through the process from planning to prototyping to developing, theming, and QAing the final product. 

First, plan the work

During a project’s discovery (planning) phase, we break the project down into bite-sized pieces; pieces small enough to build. Part of that includes isolating components. I’m not sure if components is yet a standard word, but it’s a logically and functionally independent piece of the page. One or more components will be placed into a region of the page.  A component can be a menu, a “block”, a “module”, a list, a field, etc..  Below is an example from a full-page comp, showing a single component that we called Image — with rollover.

Comp showing the isolated Image — with rollover component

This is a bit more complicated than it first appears because there’s a complex hover effect.

We’ll start by breaking this down into three user stories:

 

1. Admins see Image — with rollover components after creating them (prototype)

Acceptance Criteria

  • HTML/CSS prototype of component described in the development ticket should appear as comped (across multiple breakpoints).
  • If I hover over the component with my mouse (or tap on a touch device)
  • Then the teal overlay fades in
  • And the title and arrow slide up to the centre
  • And the summary slides into the component from the bottom

Technical notes

See .PSD for hover elements

2. Admins see Image — with rollover components after creating them (develop)

Acceptance Criteria

  • Given that I’m an admin on any customizable page
  • If I click Customize Page
  • And click the + icon to add a new component to the page
  • Then I can add the Image — with rollover component
  • from the Two Thirds width category
  • And I see fields for:
    • Title (built-in)
    • Image (Media browser, req’d)
    • Summary (long text, no WYSIWYG, max 200 chars, req’d)
    • Destination URL (link, URL only, req’d)
  • If I view a page with this component
  • Then I see it (with the markup described in the prototype).

Technical Notes

This should be a Fieldable Panels Pane

3. Admins see Image — with rollover components after creating them (theme)

Acceptance Criteria

Functionality described in the development ticket is styled to match the corresponding prototype and comp.

Why three user stories for one component?

This is ultimately part of how we’re able to resource our projects well in advance and keep things consistent through the life of the project. By splitting tickets this way, we can determine and plan for how many hours we need for each, e.g. Project X will run from Aug 1 – Oct 31. It’s estimated at 600 hours back-end work and 400 hours front-end work. We then go even deeper: Gertrude is working 15 hrs per week on project X and 10 hrs per week on project Y.

There’s a second benefit where this split allows us to do the prototype in an earlier iteration than the dev and theming. This means that right from the start of the project, while back-end developers are working on the foundation, front-end devs (we call them The FEDs) can be working on the first set of prototypes.

Prototype

After looking at the series of design comps (maybe some are “mobile” and some are “desktop”), there are generally three things we’re trying to accomplish when we get into the process of responsive prototyping within our living style guide. The goal here is to provide the cleanest model of how the component should be structured, and it will be used as a guide during actual development.

We advocate creating a prototype horse before just diving in and building one.

First, we try to determine how to build it with the absolute least markup possible. This means first looking at the component at the smallest possible width. We then add required markup only as necessary to fulfill the needs of the component’s layout as things change visually for increased browser widths. The same approach applies when writing Javascript for the prototype.

Second, we try to anticipate and prevent bloated CSS by using our own brand of DRY methodology (Don’t Repeat Yourself) in assigning class attributes to our markup. The idea is to create reusable classes that describe the component as a whole on its container markup, as well as grouping and identifying the inner parts of the component. We try to adhere to the naming conventions used in BEM methodology (Block, Element, Modifier) for writing scalable and modular styles, as demonstrated in the “flower” example by John Albin Wilkins. By doing this, we can really reduce the amount of long, overly specific CSS selectors (perhaps via Sass code nesting), which leads to faster compile times and leaner final CSS. Here’s an example of ideal rollover component prototype source code, as seen within this case study’s living styleguide:

<div class="component image-rollover">
 <img class="image-rollover__image" src="https://placeimg.com/654/476/animals" />
 <div class="image-rollover__overlay">
   <h2 class="image-rollover__title">Living on campus<a class="arrow" href="#"></a></h2>
   <p class="image-rollover__content intro">Lorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent posuere tincidunt nisl et eleifend.</p>
 </div>
</div>

Lastly, sometimes we’ll fake things with CSS in the prototypes that will eventually be provided via backend functionality. For example, “responsive” images used in banner/hero image type components. In the prototype it’s usually good enough to use an image and stretch it fluidly, as big or small as it needs to be, using “width: 100%” and/or the common “max-width: 100%” approach. At some point that will be done using a proper solution, like Drupal’s image styles and the Picture or Client-side Adaptive Image modules.

Develop

The back-end developer’s job is to build the prototyped component in Drupal and hook it up to an admin interface for managing its content. Depending on the project and the context, it could be a fieldable panels pane (FPP), a CTools plugin, a BEAN, a block, a theme function, a field formatter, a View… there are all sorts of ways to accomplish the same thing, and picking the right one could be a blog post itself!

In our example, though, we’re working with an FPP, as specified in the technical notes of the ticket. Looking at the prototype, we determine which pieces need to be editable, and we build fields for those pieces. Here, we were able to use the Fields UI for this (but sometimes we’ll need a custom form).

More often than not, we write some hook_form_alter functions to make the admin experience as smooth as possible – things like conditional fields, or programmatic default values. This one is simple enough already, though. Thanks Drupal!

Fieldable Panels Pane: field configuration and content form

Now, we can input the data required for an instance of this component, and we can make a few samples to work with. Next, we need to override the default markup and get it close to the lean markup provided in the prototype. Since our FPP will be rendered in a panel pane, we implement hook_panels_pane_content_alter, hook_theme and a custom theme function:

/**
 * Themes an image with rollover FPP.
 */
function theme_edusa_media_image_rollover($variables) {
 $output[] = '<div class="image-rollover">';
 $output[] = render($variables['image']);
 $output[] = '<div class="image-rollover__overlay">';
 $output[] = '<h2 class="image-rollover__title">';
 $output[] = $variables['title'] . l('', $variables['url'], array('attributes' => array('class' => array('arrow'))));
 $output[] = '</h2>';
 $output[] = '<p class="image-rollover__content intro">';
 $output[] = $variables['summary'];
 $output[] = '</p>';
 $output[] = '</div>';
 $output[] = '</div>';

 return implode(PHP_EOL, $output);
}

Theme

It’s possible there’s not much left to do during the theming phase if the prototype markup could be faithfully reproduced during development without any snags. However, sometimes it’s easier to make a quick change to the prototype to accommodate something that would have otherwise taken a while to do on the back end. The theming phase serves as a moment for us to tie up any loose ends on the front end, including using the Fences module to set proper wrapper HTML elements (or removing them altogether) for any field content used in the component to match what was used in the initial prototype.

This is where we work in-browser with the fully developed version of the component, and fix any issues on the front-end due to how it appears when real-world variables come into play: the size of the viewport, the existence and length of content, or other edge case scenarios. Occasionally, we’ll need to go back to the style guide and adjust the prototype’s markup, CSS, or JS to keep it in sync with the completed, functional, and responsive version of the component. This is the frustrating part of the process, when the styleguide breaks for seemingly random reasons.  We’ve got some ideas for how to fix this problem.  We’ll explore these ideas in part 3 of this series.

At this point, we’ll do a little mini-QA session to check things against the current versions of our target browsers and a few popular mobile devices. This allows us to catch the majority of browser or device-based issues early while the component is still fresh, before a more thorough QA process at end of the iteration.

The Final Product

And here’s the component in action:
https://educationusa.state.gov/experience-studying-usa/experience-studying-usa

Finished Image — with rollover

The Only Thing You Can Count On Is Change

Regardless of whether you’re doing decoupled Drupal, or styleguide-driven development, you need to have interdependence between the front-end and back-end team. If there’s one thing that we can count on, it’s that partway through the project priorities will change. Maybe now that we see the site in action we realize that it needs to be reworked a bit; maybe someone forgot about feature X that is going to end up taking 25% of the project budget; maybe the client organization needs to pivot. Whatever the reason, we need to have a process that can account for change. And keeping the front-end and back-end teams in sync, neither getting too far ahead of the other, is crucial. If we have to start dropping features, our options become limited if we have many things half-built.

Conclusion

Style-guide driven development is not without its challenges (what is?), but we hope you have a good idea of what you’ll need to make it happen. In part three of this series we’ll explore how we might deal with the problems of styleguides getting out-of-sync with reality and styleguides that randomly break.

This article was a team collaboration by Amanda, Andy, Dave, Jack, Kim, Oliver, & Sarah.

You should also check out:

Jul 21 2015
Jul 21

What exactly are we trying to do here? And is there another way to do it?

Headless/decoupled Drupal has received a lot of buzz in the last year. But the rise of decoupled Drupal has also been met with due skepticism, as there are significant challenges. We’re not here to further that flame war; you can find the details elsewhere. In some specific cases, taking the decoupled approach can be worth the cost of dealing with those challenges. But in many — if not most — cases, that list of challenges trumps the novelty of decapitation.

At Advomatic, we’ve been exploring how to achieve the same goals of decoupling, while avoiding that hefty list of challenges.

The direction that we’ve been heading is to use styleguide-driven development (SDD).

First, what do people typically mean by decoupled/headless Drupal?

In this approach, Drupal is used only as a place for administrators to manage content. The Drupal site does not actually display the content (at least, not to anonymous visitors). Instead the Drupal site makes the content available via an API. That API is used by the public-facing website, which is typically powered by a JavaScript framework like Angular.js, Ember.js, or Backbone.js. This has many advantages, which we’ll discuss below, but this approach also comes with significant drawbacks, like problems with SEO and accessibility, lack of contextual tools for administrators, fad JS frameworks, trouble finding skilled developers, little role for the “site builder,” and more.

Let’s also define what we mean by styleguide-driven development.

We’ll go into more details in the next article in this series, but for now, when we talk about styleguides, we are talking about a set of fully functional, reusable elements and components, built and themed outside of Drupal, using idealized markup. This includes all generic HTML elements, (headers, lists, blockquotes, etc.), native Drupal components (pagers, menus, alerts, etc.), and site-specific components (carousels, listings, features, etc.)

So what are the goals of decoupling? And can SDD accomplish them just as well?

Recently our colleagues over at Lullabot published an article describing the underlying goals of the decoupled approach. Some items on their list are related to APIs. Styleguide-driven development does nothing for your APIs. If you know that one of the primary content delivery methods for your project will be through an API, maybe decoupled Drupal is for you. If you don’t need to have an API, or if the API is going to be a second-class citizen, then decoupling could be a case of YAGNI.

I would argue that one of the goals in the Lullabot article — abstraction and constraints reduce individual responsibilities while promoting content reuse — while an important topic, actually has nothing to do with decoupling. 

I’m adding another of my own, so that leaves us with this list of goals and how decoupling and SDD address each:

  • Less reliance on Drupal specialists  

    Drupal has long been a market where it is difficult to attract top talent;  many people are already happy where they are. Because styleguides are built using the more broadly used tools of HTML/JavaScript/SASS (and maybe a styleguide tool like KSS), we can leverage the skills of a broader variety of web professionals.  In contrast, headless/decoupled Drupal only replaces Drupal specialists with specialists of another type.

  • More self-contained upgrades

    Want to upgrade to Drupal 8 without a redesign, and only a minimal theme upgrade?  Want to revamp the look and feel with minimal changes to the back end? That’s now easier with both decoupling or styleguide-driven-development. Because the front end and back end are less tightly coupled, you can make a major overhaul to one with less impact on the other (compared to if both are a single system). We should note that at this point this is entirely theoretical. The movement is still too new¹ to see many (any?) examples of this in practice.  I anticipate that in reality stakeholders will almost always want to make changes to both at the same time.

  • Allowing front-end and back-end teams to work simultaneously 

    This is where both decoupling and styleguide-driven development really shine.  In the olden days the back-end team would start building the website while the front-end team would be sitting on their hands waiting until there was something to work with.  Similarly at the end of a project the back-end team would finish up while the front-end team frantically pulled all-nighters to fix all the cross-browser bugs. In our next article of this series we’ll delve deeper into how a parallel workflow with styleguide-driven-development can look.

Ultimately, we believe that the styleguide-driven approach has the potential to meet the same goals as decoupled/headless CMS development, but it does so in a way that bypasses many of the challenges.  In the next post in this series we’ll get into the details of what exactly this looks like for a typical project.

In closing, let’s back up for a second and talk about how we should go about making decisions about which tools to use when building websites. 

“Right tool for the job” – another abused one. The intention here is reasonable: who wants to use a tool that isn’t appropriate? But a rare perspective is that this can be detrimental when taken to the extreme. A carpenter doesn’t arm himself with every variation and size of hammer that is available, even though he may encounter hammering tasks that could be ideally handled by each one. Why? Because lugging around (and maintaining) a gazillion hammers incurs a cost. As such, decisions on this axis have trade-offs.
John Allspaw

It’s both too expensive to try and build everything with the same tool, or to learn a new tool for every project.  At the same time, some tools only work for a very narrow use-case, while some tools can be used for a broad range.  Are we hitting the limits of what we can do with small chunks of HTML, CSS, and (minimal) JS?  How far can we take the styleguide approach?  We see the future looking very bright, both in terms of where the web community at large is headed with ideas like Web Components, and at Advomatic we have some ideas for how we can make components more reusable across Drupal projects (look for a future series of articles on this topic).

1. The idea of a decoupled website had some degree of popularity way back in the late 90s, but the flavour that we see now is different enough that it’s difficult to draw many meaningful comparisons.

Thanks to Amanda, Jack, Oliver, and Kim for collaborating with me on this.

Other posts you should check out

Dec 21 2013
Dec 21

The #DrupalPicchu sessions have been published, and I will be making the Drupal Lean Process presentation in Cusco. In preparation, the lit-drupal-lean project is in full swing right here on GitHub. Here's a short-list of what has been achieved so far:

  • Some of the most important docs and guides and templates have been gleaned over to the wiki. That includes material on MVP Planning, structured (hypotheses-driven) user stories, collaborative design and style and code guides, scaffolding and a host of templates to people your issue queue.
  • The codebase in branch master already includes a complete distro starter set, which will then grow via the addition of features, some of which will be base features and will be turned on by the install profile, and some of them will be optional and simply present.

The goal over the next thirty days is that the sample app, lit-drupal-lean, will constitute an easily GitHub clonable drupal + best of breed modules starter kit with built in lean process.

That process will evolve and grow, and will form the basis of a book I wish to publish or self-publish early next year, which will in turn serve as the basis for my current mentoring endeavors for organizations and companies in the process. In the process of forming their own standing teams.

So, star me on GitHub, please! That's where I'm spending most of my time.

Bookmark/Search this post with

Dec 03 2013
Dec 03

Table of contents

[Skip to any section because you can]

Introduction

I have been working in software development a long time. Early on I recognized the need for Process as a way of re-using best practices for teamwork. At that time, Process implied for most of us the Waterfall model, which divides a development project into discipline based phases, each to be visited once in turn, in a kind of cascade: Requirements; capture the requirements, do the Design, Implementation, Verification and Validation, Deploy, then shift into Maintenance mode. Most people still follow that model implicitly, it has stayed in the everyday consciousness of process, much like Newton's laws instead of the Theory of Relativity, much like the theory of Creationism over the scientific Theory of Evolution kicked off by Charles Darwin. Yep, Waterfall often creeps in even when people say and even when people think they are using Agile. Of course, project difficulties and even failures based on the extremely high propensity (40% minimum) for requirements to change within the life-cycle of a project highlighted the dire need for at least an Iterative and Incremental model. And when that became too top-heavy, at least in its wonderful, eye-opening but hard to tailor and work with Rational Unified Process, I moved on to a kind of personal synthesis of CMMI (love that continuous improvement and organization wide adoption!) and Agile and Scrum approaches. More recently I have loved the simpler work in process and visual approach of the Kanban as a lean variety of Agile:

“Some Agile methods take a more flexible approach to time than Scrum does. (For example, Kanban does away with the notion of a two-week batch of work and places the emphasis on single-piece flow.) But you can still make time within a Scrum sprint in which creative activities can take place.” Gothelf, Jeff (2013-02-22). Lean UX: Applying Lean Principles to Improve User Experience. O'Reilly Media.

Following in the footsteps of C and Unix programming, C++, Enterprise Java and light-stepped Spring Framework Java, as well as Ruby on Rails, I found myself more as process engineer, architect and mentor in the web application world, rather than mainly programmer, and adopting the Drupal framework and community as my workplace. So I wanted to bring all my prior experience in process and architecture to Drupal and to its community. So I did, with the publication of Leveraging Drupal. Steeped in the Agile moment when it was published in 2009, the first chapter outlined and the whole book implemented in a number of projects, most clearly in Chapter 11: Full Swing Agile Approach to Drupal Development, a process for Drupal incorporating the best practices I had made my own throughout my career.

That was then, this is now, with, as Karen McGrane explains (Responsive Design Won't Fix Your Content Problem), responsive web design only scratching the surface of how content needs to be structured and based on a clear strategy for today's multi-device world of consumption. And with all of this heavily impacting the kind of process on which web app dev teams need to base themselves, it's time for a new process to emerge, and for a new book to be written. The process must take from Agile, from the application of lean startup process (web app dev as product dev of real value based on real needs), and from the need for the team to work on the same visible work in process together, without waterfallish handoffs and with maximum permanent client feedback; and the process must allow itself to be heavily impacted by the need for modern web apps to be responsive, adaptive and based on structured content. For each app is a back-end based API with multiple clients on multiple devices. And each app (and even each distributed component within the app) must have the most adequate framework as its vehicle. So Lean Process is the best process for Drupal based web apps, but at the same time, must emancipate itself from Drupal per se. People are facing today's challenges on many fronts, and the process will work at its best with Drupal, but also with Backdrop, other CMS's, and many other stacks all of us are flocking to.

Initial vision for Lean Process artifact workflow; but there are no handoffs here: what used to be scrums are all-eyes interdisciplinary motorized work applied to a common theme everyone is working on together.

Drupal Lean Process and Machu Picchu

Drupal Lean Process is Web App Lean Process, and is emerging as it puts a number of projects concretely under its belt. Today very few are starting from scratch, so we must focus on migrations needed right now, be it Drupal 6 to Drupal 7, Drupal 6 to Backdrop CMS, or from Drupal to other stacks. And it must be a repeatable process; that is, if it is used to migrate from Drupal 6 to Backdrop CMS, it may, in large part, be re-used for alternative future migrations to stacks which may not have come into being as of this writing, but which will capture hearts, minds and communities in the future.

The first public airing of Drupal Lean Process will be at DrupalPicchu, where I will head up an AWebFactory workshop (bi-lingual, English and Spanish) “Conquering an agile process for Drupal, driven by user experience enhancements, with tools” (link coming as soon as sessions are published), that is, on Drupal Lean Process.

Many will come to DrupalPicchu. Many may not. So I have decided to base the workshop on a concrete project, housed in a public GitHub repo, being kicked off as we speak.

Lit Drupal Lean

Lit Drupal Lean is both the process and the project. Characteristic of Lean Process projects is, just that, they incorporate a reusable process, with workflows and templates and artifacts, and, oh yes, the executable, deployable code, all as a work in progress, erm, in process.

This particular web app centers on the need writers, workshop leaders and publishers have for a community of literary workshops. The project is being kicked off right now, if you watch it you may witness its growth, as it acquires the form it will take during the free workshop January 20-24, 2014 (we might get enthusiastic and start it a day before the conference itself).

Again, here is the link for the public GitHub repo: https://github.com/victorkane/lit-drupal-lean with entry point at the issues page, not the wiki. The Kickoff Milestone tasks already explain a lot about the process.

It had better be self-explanatory (the use of GitHub Issues 2, as well as the automatic reference rich GitHub Flavored Markdown and Task Lists, are prominent tools adopted for Lit Drupal Lean).

Drupal Lean Process Book

The book will be self-published this time I think. I will welcome donations of course, but my income is derived mainly from the mentoring services I offer, so the advantage will be that the book will be kept up-to-date, with versioned downloadable tags in the repo for the usual formats. I'm going to take a stab at Markdown → Static Site → ePub and other portable formats (a project in itself :) , and it will be in a public repo). At some point, popular versions may be self-published in the usual sense if deemed useful, but the main objective will be to centralize and openly update the process.

Eclipse (Kepler) IDE and Project Management tool

Tools come and go, vary on a per-project basis. But bringing a number of recent articles together, let me share how I am using Eclipse as both an IDE for coding and DVCS, and a powerful (if novel and as yet not totally complete) project management tool.

Remote Perspective with Terminal for Git command-line management.

I could have used the incredible Git Repository Exploring perspective I wrote about recently, and managed version control with the Git visual interface, instead of the command-line as an added option, working directly on a local working copy of the code, while still accessing GitHub issues for project management. Increasingly however, I work on a server, so I prefer the Remote perspective as a starting point. Notice the use of the Markdown Editor plugin associated with *.md files, which comes with a Markdown HTML Preview view.

Remote Perspective showing Task Issues Repositories and Task List Views

I really enjoy the Task Issues Repositories and Task List Views, and have simply added them to the basic Remote perspective. In the former I specify a GitHub repo and an initial query (as I outlined in a previous post), and in the Task List Views, I can work with individual issues, synchronizing them from and to the Issues section of the project, specifying Milestones, specifying and even creating labels, assigning tasks to collaborators, cloning issues from template issues (for often used artifacts), etc. Again, it had better be self-explanatory.

Recent related articles:

Bookmark/Search this post with

Mar 14 2012
Mar 14

Last night at the main LA Drupal meet-up I had the opportunity of talking about how we do things at ActiveLAMP, and some of the processes we follow. The LA Drupal organizers created a new session slot in the monthly meet-up called "Shop Talk". The idea is to bring someone in from a local shop in the area to come share about how the Drupal shop they work for runs, and share some processes that might benefit others in the community. It was a very TED talk type of vibe, as you only get 20 minutes to talk about your shop and present your ideas, but none the less I think I captured (at a very high level) how we approach and manage code, tasks, drupal, and deployment at ActiveLAMP.

Unfortunately, due to technical difficulty, the recording that we took from the presentation did not save properly on the flash drive that was plugged into my computer, but hopefully the slides are still helpful by itself.


Dec 17 2011
Dec 17

The last few days have pretty much been nose down to the grindstone coding like crazy for the development team. Days 5-9 were pretty much the same with a few exceptions.

Day 7
On this day the Epics and High Level User Stories were delivered and these helped define user stories that needed design artifacts. The project team started sifting through the stories to identify any pitfalls or problems. As the Technical Product Architect, I start to think really hard about approaches that we might be able take when we get down to the Drupal part of the implementation. Are there any contributed modules that might fit the bill? Sitting down with various Product Managers we began detailing how the product vision would technically be handled.

Day 9
Largely the user stories were delivered. As a team we really started doing a great job of reviewing individual stories. Certain members of the development team had their features code complete which opened them up to help review the stories that were being delivered. We started looking at wireframes.

During these two days, the Executive Committee were helping continue form priorities for the next Timebox.

Day 10
Today was a transition day. If you look at the first post in this series, you'll see that the days turned from blue to yellow today. This represents a handoff of the environment to the QA department to start reviewing code that has been completed and pushed to the staging environment. This transition is also the first day that the development team throws themselves largely into helping review stories and wireframes. It is early enough in testing that there are few defects being sent back for rework.

First draft comps for the next timebox are also due. In our case, wou can watch the box.net directory synch as comp after comp are dropped making them available for the team to review. I've noticed that the transition day tends to be heavy on meetings. A sampling for example, today, had:

  • Three Scrums
  • One Scrum of Scrums
  • Part 1 of a Config Dry Run for a new set of features
  • Ideation for a new project that will lead to User Stories
  • A ticket system transition meeting
  • A reports meeting

The next three timebox days will finalise our user stories for the next time box with both the development and product groups. We will continue testing and reworks.

Bookmark/Search this post with:

Dec 09 2011
Dec 09

Day 4 of a Drupal Timebox
Yesterday was the first day that the Examiner.com development team was really coding. That became conversations in IRC and the beginning of features being sent to code and theme reviewers. The spreadsheet that we keep our user stories in is starting to move yellow stories to green and the salmon stories are being turned yellow (white is uncommitted stories, grey is deferred, yellow are committed to being developed, salmon need more information, and green are ready for manual QA). This is the time when the developers really get their heads down and are working hard to complete the stories they have allotted in the time period available and work on the bug backlog.

The morning began with our regular scrums - three teams, three scrums, three sets of projects. This post doesn't need to rehash our morning scrums.

The day was peppered with meetings including a review of current Infrastructure needs and ideation of new Ad targeting techniques with a Product manager. It included working through planning a business trip to work with another company on an Examiner project. We're also still working through retrospective improvements from the previous timebox.

The Backlog Mambo
We embrace the idea that the current work we're developing should be predictable. The current timebox development should be pretty much set in stone. There are times with opportunities or threats are so great that we need to suffer the challenges of context switching. This should be rare. Anything after current development should be negotiable. That is what a large chunk of today was all about.

Yesterday, the Product team brought to the Project Managers a prioritized backlog for the next timebox. This list was a first pass based on Executive Committee directives. The Executive Committee convened today with the Product Team, and representatives from Business Intelligence and Development. The top items in the list were discussed and adjusted. Scope was shifted and priorities were moved. There were requests to fatten out some additional initiatives. The next two weeks will have the Product team focused on developing user stories in conjunction with development and Creative working with themers on wireframes and comps.

The dance continues.

Bookmark/Search this post with:

Jan 05 2011
Jan 05
Drupal 7 has launched today. Take a look. Many thanks to everyone who participated in this project.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web