Cloud Platform
Managing Software Projects (Pliakas)
Chris Pliakas, the director of Content Services Engineering at Acquia, has been leading the Acquia Content Hub project since May, 2015. A certified ScrumMaster, Chris has been working at Acquia since 2010: as a technical consultant, solutions architect, scrum master, and engineering manager.
Acquia Content Hub, Chris' latest project, is a cloud-based content distribution and discovery service that enables customers to securely author, search, and share content throughout a complex network of sites and channels. Content Hub connects content bi- directionally, enabling enterprises to discover, reuse, and distribute content throughout their organization in a secure cloud environment.
The Content Hub team created software that lets authors and site owners reuse content from other sites, commerce platforms, and more. To facilitate sharing between all these different systems, Content Hub makes it possible to normalize content, and provides centralized tools to search and discover content within a network of sites. In addition, Content Hub can automatically keep content consistent across different sites (publish-subscribe), mitigating the risk of out of date information, all while respecting workflow rules on the local destination site.
Chris: There are two engineering teams dedicated to Content Hub. One is focused on the back end service and the other is focused on the Drupal integration. Each team consists of four engineers, and we share a Quality Engineer, UX Researcher, and UX designer across the product. Outside of engineering, we have product champions on the Solutions Architecture, Professional Services, Support, and Ready teams who are designated as Content Hub experts in their areas of focus.
Chris: It took approximately 9 months to get to GA. We developed the product and UX-tested it for 6 months, then we engaged with early customers for 3 months to validate our assumptions in the real world.
Chris: That's the hard part, because we actually started this product with a different use case in mind. Then about two months in, we switched use cases. That's the benefit of lean methodologies: you can spec it out and give a rough swag, but as you go along you are able to pivot quickly based on things you discover along the way. One thing I've learned in tech is that your assumptions are usually wrong, and that proved out here as well.
Despite the pivot we were confident in the general need for the product, so we set a timeline early on with the understanding that the goal posts would move in order to meet the target date.
Chris: The original idea was to build a system that allowed our customers to use Drupal as a back end content repository to push out experiences that are rendered by another system, be it Drupal or something else.
Chris: Exactly. There are a few use cases where you can use the strengths of Drupal to augment the capabilities of other systems that perform well in other areas. For example, the commerce ecosystem is incredibly complex, and many of our customers have adopted non-Drupal technologies to power their e-commerce capability. Although these systems integrate seamlessly with the commerce ecosystem, they are challenged in allowing marketers to quickly create, review, and publish content. The numbers supporting the need for content-driven commerce are staggering, so our customers have to figure this out now to stay ahead of the competition. Our Professional Services team helped a few of our customers achieve this vision with bespoke solutions, so we saw the opportunity first-hand.
At the same time we noticed a trend with our larger customers where they favored a lot of smaller, targeted sites over a few large properties. This can result in hundreds of sites, in some cases thousands, some of which are built with Drupal and others that are not. Although smaller sites allow our customers to innovate faster on the technology, it introduces the problem of content sprawl because content is siloed in the individual properties and difficult to extract and share.
In looking at these two use cases, the solution is architecturally similar despite the different goals. Based on information we learned after development had started, we switched our focus to the latter use case for the initial iteration of Content Hub and it will evolve to meet the former over time.
Chris: We started off fast, but it did start to slip away from us. Then we made some adjustments, and we were able to have a great product launch. With a lot of products, the days and weeks before a launch are pretty hectic. The developers are working through the night in order to meet the deadline. This is the first product launch that I've been a part of where both our private beta and GA launches just flowed. I'm not saying the team didn't put in extra hours towards the end, but there were no heroics, which is how you want it. The days following each launch were business-as-usual, and nobody was burnt out.
Chris: The key was making sure our process was tight. We adopted the Scrum methodology and rigorously followed its guidelines [more on this in Part 2]. We made sure that we put ourselves in a position to ship product every two weeks. We believe that if you build something that people can't use, you are no better off than if you didn't build anything at all. The key to making this happen is ensuring the work is small enough to fit within that two-week iteration, inclusive of building automated tests for whatever functionality is delivered.
If you try to tackle big things all at once, you can run into trouble. It feels like you are moving at light speed, then you lift your head up and see a completely different world around you. You either solved problems that your customers didn't have or missed the mark on what they expected. Regardless of your approach, this is inevitable. The choice you have is failing small so you can learn from it and recover, or failing big and landing in a hole you cannot dig out of.
Chris: The biggest lessons are related getting feedback as early and often as possible. Feedback is gold, do whatever you can to get more of it. However, you cannot do this at the expense of quality. Sometimes phrases like "move fast and break things" are adopted under the banner of Agile, but this is a misinterpretation of lean principles. What you release has to work, and you need to invest in the things that help you ship high-quality product increments more frequently whether those things are technology, process improvements, team restructuring, better coffee machines, whatever.
For example, one thing I wish we did differently was invest in our Service Delivery Platform sooner. This is the internal service that builds, tests, and deploys your application. Our SDP became stable around 2 - 3 months into development, if I had to do things over it would have been completely functional within 2 -3 weeks at the absolute latest. It is imperative to invest in the system that allows you to put a quality product in front of people quickly.
Chris: Yes, even now as we launch the product. Content Hub is stable but evolving, so we get a lot of feedback from customers. Making sure we are able to react quickly is vital to the product's success so that it meets future market demand, not just the market demand today.
Another lesson is that the team, the people who are actually building the product, are in the best position to tell you what state the software is in and how best to fix it. Empowering them to take ownership over what gets done is really important. That was a big shift for me. As a manager, sometimes you want to get your hands dirty and try to figure out some of the details. But it's much better to take a step back and make sure the team understands the goals. Your job is to remove anything that is blocking their progress. You must give the team complete ownership over how the work gets done. That's the fastest, most sustainable way to get a product out the door. It's hard to let go, but if you can do it, it yields a lot of rewards.
Chris: Yes, it's tough. Sometimes I can't help it, so I do a lot of side projects to scratch that itch and not disrupt the team. My background is engineering, so I can still understand a lot of the nitty-gritty stuff. But if there is something I know, instead of recommending or telling the team, I ask a lot of questions to try to get them to come to their own conclusions. I also learned that what I think I know might not be right. In fact, it usually isn't. There were many times when my assumptions were completely wrong, and through asking those questions, the team was able to inform my thinking.
In Part 2, Chris discusses the Scrum process, the benefits of working with an open source framework like Drupal, and what's next for the Content Hub project.
Cloud Platform