devopsy.kinsta.cloud

Tag: distributed teams

  • The One Where All Hell Breaks Loose

    The One Where All Hell Breaks Loose

    Don’t you love a good story? This one is a DevOps story in a fictional enterprise. It’s the kind of story you’ve seen replayed countless times in large organizations. So settle in for a read.

    The backstory

    DChip Tech is a semiconductor company. They’re in the business of making chips for wearable computing since acquiring Enogo, a startup in France for simulated testing in wearable technology.

    Three months into the acquisition on a late Sunday night in France, the VP of Operations at Enogo considers his late evening ahead.

    Chandler is not a happy man despite his recent appointment as the VP of Operations. How can he be? How can a 40-person company in France give him so many sleepless nights? And tonight is no exception.

    DChip’s strategic momentum in the last months had everything to do with it. To leverage the cream of the crop engineering talent in wearable tech, DChip, the San Francisco Bay area chip giant invested in Enogo.

    • Now DChip wants Enogo systems fully integrated into its OpenStack datacenter to reduce infrastructure costs.
    • Although Enogo hosts on AWS, DChip doesn’t want to integrate AWS Europe into the corporate network. They want to keep the intellectual property in the US.
    • It falls on Chandler’s lap to integrate the systems of both the companies and reorganize IT, to speed up DChip releases from once every six months to the weekly push like at Enogo. Imagine all that.

    Tall order, he thinks wryly, gulping down another cup of coffee to keep him awake for the Monday morning US time leadership meeting.

    Where all the action happens

    He dials into the video conference warily, his head already starting to throb. First to appear on the screen, Phoebe, the CIO is looking none too happy either. Soon all the division heads appear on separate screens including the engineering and QA heads from Enogo.

    Dismissing the usual small talk, Phoebe launches right to the point. We have a firm deadline to move out of AWS cloud in three months. Yet, where do we stand now? Can someone explain why the delay in integrating the systems of both companies? Do you know how much this is slowing down our go-to-market strategy?

    Monica, the Chief Architect in charge of the Datacenter OpenStack cluster, says, “We’d love Enogo to move to OpenStack today. But it’s not fully stable.”

    As if to emphasize the point, Rachel the engineering manager whose team is building the wearable emulation test software adds, “We can’t wait for the OpenStack cluster to work. Our engineers need test environments like yesterday. That’s why using AWS makes sense.”

    The marketing and sales VPs quietly watch as everyone joins in the blame game.

    Not to be left out, Joey the Enogo QA Manager complains that he can’t deploy the image that contains the emulation software because OpenStack is corrupting it. “All the more reason to support AWS,” he quips.

    The ultimatum

    I’ve heard enough; Phoebe bellows over the din of the meeting. She turns slowly to glare at Chandler through the video camera. “Chandler, do you care to explain why we have an unforeseen $100,000 dollar expense this month? I want an explanation.”

    “It’s a case of a simple, human error; it can happen to anyone Phoebe,” Chandler tried calmly to explain. “One of the devs launched instances and forgot about it until we got the bill.”

    “Yea” piped up Janice, the VP of Finance. You’ve been paying the AWS bills out of your credit card, Chandler, and then billing the company after the fact,” she so helpfully points out.

    Chandler stands dumbfounded as Phoebe’s final words struck his heart: “I told you to shut down operations on AWS. I want to move to our datacenter on OpenStack. No more bills from AWS Chandler, you hear me?”

    Her words rang late into the night and the next day.

    To be continued…

    (What do you think will happen next? Watch this space for our next episode of the DevOps story. Any resemblance to these characters or events in real life is purely coincidental.)

  • 8 tips on how to best manage distributed teams

    8 tips on how to best manage distributed teams

    More and more organizations are using distributed testing teams yet many are hard pressed to know how to manage teams that may be separated by thousands of miles away or on another continent. Too often, companies think about offshore product development only as a means to cutting costs and accelerating time to market. Such an approach can produce poor results with your projects if you don’t take into account certain issues like cultural barriers, metrics and workflows.

    The smart strategy is to focus on the needs and skills of the team and to implement procedures that will help manage them better. Your standard bottom-line goals — cutting costs and accelerating time to market — will take care of themselves if you can follow these 8 tips for managing distributed teams.

    1. Know Your Team

    It’s important to address people correctly. People respond well when somebody knows how to spell and pronounce their name. To infuse a sense of team spirit, attach a face to the person who is communicating via email, phone or IM. Have a kick-off meeting for a project team, where each person introduces themselves with some basic personal information such as a hobby or interest, to help establish a ‘human-side’ to the offshore team. While meeting in person might not be a possibility, the liberal use of video conferencing can really improve the relationship with remote teams.

    2. Eliminate Language Barriers

    Working with remote teams on different continents/countries requires strong communication. It’s critical for the key contacts between teams to familiarize themselves with the pronunciation and grammatical styles of each other, while also ensuring that your team members obtains International English certifications, such as TOEFL. In addition, when possible, I recommend that the team leaders from the vendor side and client side visit each other’s offices to understand the culture of the companies and to instill a sense of partnership.

    3. Clearly Define Roles and Responsibilities

    To ensure that all members of the project team understand their expected tasks, it is vital to establish clear roles and corresponding responsibilities early on. Create a collaborative, pyramid-style team structure for the offshore team, so that the key people responsible for daily communication with the rest of the project team are identified, along with an obvious reporting hierarchy.

    4. Create Strong Communications

    The distance between remote teams working on the same project can be eliminated by use of communication tools such as IMs, VOIP-based phone calls, online meeting tools and other electronic mediums. However, communication is only as good as the information provided. All relevant documentation and domain knowledge must be continuously shared with all team members.

    5. Track Detailed Onshore/Offshore Planning and Tasks

    To ensure that your teams understand the assigned tasks and is progressing as expected, it is very important to have a milestone-driven WBS (Work Breakdown Structure) that identifies the effort associated with each task, and identifies the timeline of when the tasks need to be completed. This level of detail ensures that everyone is clear on their assignments, and that any delays (and corresponding affects) can be identified as early as possible, so that a mitigation plan can be implemented if need be. Team progress on assignments and activities should be followed up with daily, weekly and monthly reporting, leveraging defined templates where possible.

    6. Establish Process Workflows

    A clearly defined testing activity workflow should be established and reviewed with the offshore team, to ensure that all team activities are synchronized. Documenting a process workflow allows the team to streamline, validate and verify expected activities that could impact the project delivery timelines.

    7. Don’t Forget Metrics

    Offshore team deliverables and activities should be gauged with quantifiable metrics such as timeline delays, actual-to-estimated effort, QA-to-production defect ratios, and so on. Metrics should be established under at least three categories: timelines, productivity, and quality. These metrics should be established at the beginning of the project, and tracked either by release or on a monthly basis.

    8. Establish Roadmap for Refinements

    To ensure that the offshore team continues to increase its value to the project team, it is important to leverage the daily, weekly and monthly reports/metrics to identify areas of improvement/streamlining for testing processes and test strategies. These refinements should be prioritized and scheduled for implementation by the team, and tracked for progress along with other project deliverables.

    In summary

    Establishing and managing distributed teams is a complex challenge. Cultural differences, time zone variations and lack of face-to-face time contribute to the intricate nature of this model. In addition, some companies focus too much on cost-cutting objectives. To successfully manage distributed testing teams, a company needs to focus on people, processes and communications.

    About the Author

    dave-keil-QASymphony CEO_cropDavid Keil is CEO of QASymphony, a leading provider of test management platforms for agile development teams. He previously served as CEO at Digistrive and at Integrated Broadband Services. He holds an MBA from The Wharton School and a BS in Applied Mathematics and Economics from Brown University.