For decades, global software development followed a simple logic: find the best talent at the lowest cost, no matter where in the world it lives. Time zones were managed, cultural gaps were bridged, and the software kept shipping. But as the global order shifts, that formula is being challenged, and so is the assumption that software delivery is immune to geopolitics.
In 2022, many companies with teams in Ukraine saw their operations halted overnight. U.S. export controls are increasingly restricting access to critical cloud and AI infrastructure in China. Attacks on undersea cables have exposed vulnerabilities in global internet connectivity. And more countries are tightening control over data, digital talent, and software supply chains.
In 2025, the conversation around globalization has intensified. Recent point to a growing consensus among economists and business leaders: the era of hyper-globalized trade and supply chains is being restructured. Rising tariffs, geopolitical realignment, and regional trade blocs are accelerating a shift toward localization and strategic decoupling.
What do these events have in common? They signal the arrival of a new era, one where global integration is no longer a given, and where resilience in software development must be earned, not assumed.
The Shift: From Globalization to Fragmentation
We are not witnessing the end of globalization, but rather its transformation. The model of deep, frictionless global integration that defined much of the past three decades is giving way to a more fragmented, controlled, and regional system. Instead of chasing the lowest cost globally, many companies are prioritizing stability, alignment, and resilience within trusted regions.
This shift is reflected in the rhetoric and actions of governments and business leaders alike. As international institutions weaken and trade tensions rise, companies are being pushed to reevaluate the vulnerabilities built into their global operations. Strategic decoupling, whether intentional or reactive, is now part of mainstream decision-making for many organizations.
Key drivers of this shift include:
Geopolitical tensions and the formation of new regional blocs, as countries seek to reduce dependence on politically unstable or adversarial trading partners Economic nationalism and policies favoring domestic or allied suppliers, including tariffs, reshoring incentives, and export restrictions.
Cybersecurity risks heightened by nation-state actors, infrastructure sabotage, and the weaponization of digital supply chains Regulatory pressure around data localization, intellectual property protections, and labor compliance, which can vary widely across jurisdictions
In this environment, global operations are being restructured not simply for efficiency or cost savings, but for strategic resilience, a foundational requirement for long-term continuity and competitiveness.
Why Software Development Is Affected
While physical supply chains have received much of the attention in discussions about de-globalization, distributed software development is also highly susceptible to geopolitical disruptions, often in ways that are less visible but equally consequential.
A conflict, regulatory crackdown, or even targeted sabotage, such as damage to undersea fiber optic cables or critical digital infrastructure, can cut off access to talent or tooling, particularly if a development hub becomes inaccessible or politically unstable overnight. These infrastructure vulnerabilities add an additional layer of risk, as companies often depend on a handful of chokepoints for their global communications and cloud-based tools.
Sanctions can interrupt payment channels or cloud service agreements, stranding teams mid-project or forcing abrupt transitions to alternative infrastructure.
Engineering teams working across conflicting legal frameworks may face compliance or IP protection risks, as differing data residency laws or intellectual property rights create exposure.
Developers may lose access to global platforms like GitHub, Docker Hub, or AWS services, or be forced to rely on unstable VPNs or workarounds that slow productivity and introduce security risks.
Political unrest or changes in labor law may create sudden hiring or retention challenges, undermining team continuity and morale. Increased scrutiny from investors and enterprise clients means companies must now prove the operational resilience of their distributed teams as part of vendor risk evaluations.
These risks may not be visible on a Jira board or in a sprint retrospective, but they are real, and they can derail product timelines, introduce hidden costs, compromise data integrity, or weaken overall software quality if not proactively identified and managed.
To adapt, technology leaders are shifting their sourcing mindset from cost-driven to risk-aware. That doesn’t mean abandoning global talent, but it does mean being far more intentional about where, how, and with whom your engineering work is delivered.
This shift involves a more holistic view of software talent sourcing, one that accounts for not just operational capabilities, but geopolitical alignment, digital infrastructure stability, and long-term viability. It also recognizes that sourcing strategies are no longer static. In a volatile world, resilience demands agility and the ability to reconfigure delivery models when needed.
Here’s what that shift looks like:
Evaluating not just the capabilities of a vendor and their people, but their geographic and geopolitical profile, including political stability, trade relations, and cybersecurity maturity. Avoiding overconcentration of critical functions in one region or firm by building geographic diversity into your engineering footprint.
Prioritizing alignment with stable, accessible, and politically compatible locations that reduce legal, regulatory, and operational friction.
Building optionality into team structures, with flexible paths to rebalance, scale, or transition work depending on emerging risks or strategic shifts.
Partnering with vendors that demonstrate transparency, robust identity verification practices, and ethical hiring standards to avoid risks such as misrepresentation or fraud.
Incorporating resilience metrics into vendor evaluations, ensuring your outsourcing partners have contingency plans and recovery protocols in place.
The goal is not to eliminate risk altogether, an impossible task, but to anticipate, distribute, and manage risk in a way that protects both continuity and innovation.
Nearshoring: A Strategic Middle Path
In this context of economic and geopolitical uncertainty, nearshore outsourcing becomes even more strategic. Nearshoring offers a hedge against geopolitical disruption by keeping operations closer to home and within more stable economic zones. At the same time, it enables companies to achieve cost efficiencies and tap into scalable talent pools, without incurring the long-term liabilities and rigidity of direct, in-house hiring. This combination is particularly valuable in uncertain times, offering companies the ability to stay agile, control labor costs, and accelerate execution while minimizing exposure.
For U.S.-based companies, nearshoring, particularly to Mexico and Latin America, is a compelling alternative. In addition to cost and productivity efficiencies, it offers a blend of:
Political Stability and Predictability: Mexico and key Latin American countries offer relatively stable political environments, reducing the risk of disruptive events compared to more volatile outsourcing regions. Robust Regulatory and Legal
Frameworks: The USMCA agreement ensures clear and consistent regulatory frameworks between the US and Mexico, offering predictable rules for data protection, intellectual property rights, labor laws, and cross-border commerce.
Aligned Economic Interests and Strong Diplomatic Relations: Mexico and the United States share tightly integrated economies. These economic ties minimize the risks of disruptive trade sanctions, tariffs, or restrictive economic policies that have impacted other regions.
Robust Bilateral Security Cooperation: Mexico coordinates closely with the U.S. on security, intelligence, and regional stability, helping reduce geopolitical risks in the region.
Reduced Infrastructure Vulnerabilities: Proximity reduces reliance on vulnerable undersea cables. Mexico has robust, direct connections to U.S. networks, lowering the risk of major connectivity disruptions.
Lower Cybersecurity Threat Exposure: Politically aligned countries tend to pose fewer cybersecurity risks. Nearshoring within North America under USMCA offers greater transparency and lowers the chance of state-backed cyber threats.
Talent Integrity and Verification: Mexico and most major countries in Latin America have mature educational systems, established professional standards, and extensive verification infrastructures. This helps minimize risks related to talent fraud, misrepresentation, and credential falsification common in less regulated outsourcing markets.
Ease of Geographical Diversification and Redundancy: Many nearshore vendors maintain multiple operational centers across Mexico and other countries in Latin America. This geographical diversity enables seamless continuity and rapid failover in case of localized disruptions, further enhancing resilience.
Ease of travel and face-to-face collaboration, enabling in-person visits with minimal logistical risk compared to long-haul or politically sensitive destinations, especially valuable for relationship building, onboarding, and team alignment.
Closer proximity to key stakeholders and decision-makers, which enables more responsive collaboration and deeper alignment between technical execution and business priorities.
This model doesn’t just mitigate risk, it often accelerates productivity and integration, thanks to smoother communication, greater cultural fit, improved responsiveness, and a more resilient and adaptable operational setup.
The Bottom Line: Global Isn’t Dead, It’s Evolving
Global software development isn’t going away, but the rules are changing. The companies that thrive in this new era will be those that treat resilience as a priority, not an afterthought. In this environment, companies must evolve from reactive adaptation to proactive strategy, embedding resilience into their sourcing, operations, and partnerships.
That means regularly auditing your current engineering footprint not just for efficiency, but for exposure and fragility. It means rethinking where your teams are located, how easily they can collaborate, and what contingencies exist for business continuity if disruption occurs.
And perhaps most importantly, it means partnering with organizations that understand how to build reliable, distributed capabilities in an increasingly unpredictable world, partners who offer not only talent, but infrastructure, cultural alignment, transparency, and adaptability.
In this next chapter of global software development, success will go to those who treat resilience as a strategic asset, not an operational afterthought.
Introduction: Why Side Projects Still Matter in Modern Engineering
Across the software industry, leaders often talk about frameworks, delivery velocity, and architecture. Yet one of the most powerful indicators of engineering maturity is something far simpler, something that rarely appears in dashboards or performance reviews, and something that still separates great engineers from average ones. It is the ability to build things outside work, driven only by curiosity, experimentation, and genuine interest.
For many developers, software is both a profession and a playground. The workday revolves around sprint planning, backlog refinement, and delivering features under pressure. But outside of those constraints, there is an entirely different space where creativity unfolds. Side projects give engineers room to explore new technologies, test ideas without bureaucracy, sharpen their skills, and learn in a way that cannot be replicated inside a production environment.
Some people contribute to open-source projects. Others tinker with automation scripts or dive into new languages. And some take on challenges that stretch far beyond their comfort zone. This is where today’s story comes in.
In this Scio Spotlight, we talk with Pedro Ramírez, Chief Architect at Scio, about a side project that required equal parts discipline, curiosity, and pure passion. Years ago, Pedro set out to build something he had never built before. Not an API. Not a web interface. Not a business application. A full videogame, designed, coded, optimized, published, and shipped to real users.
The project became FlyFlyFly, an endless runner released on mobile and still available on the Microsoft Store today. The result was more than a finished product. It became a source of learning, a bridge between craft and creativity, and even an unexpected advantage later in his career.
This is the story of what he built, what it taught him, and why leaders should care about what their engineers build when no one is telling them to.
Side projects uncover instincts no dashboard can measure—curiosity, experimentation, and the drive to understand how things work.
Section 1: When Curiosity Turns Into Craft, and Craft Turns Into Growth
One of the most common misconceptions in engineering leadership is the idea that side projects are distractions. In reality, the opposite is often true. Engineers who experiment outside their paid responsibilities bring sharper instincts, broader perspectives, and more resilient problem-solving skills into their daily work. For Pedro, this happened almost by accident.
“Like many people, I assumed building a small mobile game would be straightforward,” he recalls. “You have game engines, libraries, and enough tutorials online to fill a lifetime. It sounded simple in theory.”
It didn’t take long for reality to adjust those expectations.
FlyFlyFly seemed small enough to build quickly. But the moment Pedro began prototyping, he realized how different game development is from the typical enterprise or product work most software engineers do. Optimization matters in ways that corporate systems never demand. Memory usage becomes critical. Framerate consistency becomes non-negotiable. Visual assets, performance tuning, collision detection, user input handling, and device compatibility all become part of the same equation.
“You suddenly discover how little room you have,” Pedro says. “You try to run something on a slightly older device, and it forces you to rethink the entire way you’re handling resources. You end up debugging physics behavior one minute and reworking asset compression the next.”
This level of constraint is rarely present in everyday engineering roles, which is precisely what makes the experience invaluable. It forces engineers to think beyond abstractions, beyond frameworks, and beyond library convenience. It demands an understanding of how systems behave when everything needs to run smoothly and consistently under real, user-facing pressure.
Side projects like this sharpen instincts. Pedro didn’t simply build a game, he built an operating environment for himself where learning was unavoidable. And in the process, he developed a deeper sense of how software behaves in the wild.
Curiosity becomes craft when engineers push into unfamiliar territory—and that growth shows up in real projects.
Section 2: The Unexpected Complexity Behind Building a Game From Scratch
Game development is a surprisingly multidimensional craft. Even small games require a blend of systems thinking, creative design, and user experience intuition. For an engineer accustomed to building business software, it can feel like stepping into an entirely different discipline.
“You’re not just writing code,” Pedro explains. “You’re designing the interface, creating graphics, deciding how the character moves, balancing speed, difficulty, and even color choices. You become a full team of specialists inside one person.”
Along the way, he discovered aspects of development that traditional roles rarely expose. Resource management, for example, became one of the biggest challenges. With limited memory and varying device capabilities, every asset had to be optimized and every decision measured.
Another challenge was balancing gameplay. This required experimentation, iteration, and a willingness to rebuild entire components when a mechanic felt too slow, too difficult, or simply not fun. Pedro also had to learn how to market the game, prepare it for digital storefronts, and handle support once it launched.
This led to one of the most surprising lessons of the entire journey. While working at Amazon at the time, he realized that his employment contract raised concerns about intellectual property ownership. “It technically made the game their property,” he says. “It created a conflict that made it difficult to maintain or grow the game later.”
It was an unexpected but meaningful education in the importance of understanding IP agreements, licensing, and ownership terms, something many engineers overlook until it becomes a problem.
All of this made FlyFlyFly more than a hobby. It was a masterclass in end-to-end product development. Pedro walked through every stage, from ideation to launch, while learning skills that would later prove useful in real client engagements and leadership roles.
For engineering leaders, this is an important reminder. The most valuable learning often comes from unstructured, voluntary work. Engineers who push themselves through unfamiliar territory develop adaptability, versatility, and decision-making skills that are hard to teach in a classroom or through corporate training.
Game development exposes constraints most engineers never face—turning a side project into a full-scale learning engine.
Section 3: When Passion Projects Influence Real Work and Real Opportunities
Years after launching FlyFlyFly, an interesting opportunity appeared at Scio. A client was exploring the development of an RPG-style game similar to classic turn-based titles like Final Fantasy. They needed a technical lead who understood game mechanics, constraints, and the demands of building an experience rather than a business workflow.
Pedro fit that profile immediately.
“I was put in charge of the project because of my experience with FlyFlyFly,” he says. “Even though our client paused development later for budget reasons, the work we did and the trust they placed in us was a direct outcome of that personal project.”
It’s a perfect example of how passion-driven work can influence professional opportunities in unexpected ways. Side projects demonstrate initiative. They reveal a person’s curiosity, drive, and willingness to explore. They also show how an engineer behaves when there is no roadmap, no product manager, and no established process guiding the way.
This is why many leaders value them. They expose intrinsic motivation.
Side projects also shape long-term leadership potential. Pedro’s experience gave him a first-hand look at navigating ambiguity, solving unstructured problems, and making decisions without a safety net. These are the same qualities that help teams move through complex transitions and high-stakes architectural decisions.
For companies evaluating nearshore partners or expanding engineering teams, this is a meaningful reminder: experience is not just measured in years. It is measured in how people use their time, how they push themselves, and how they build when no one is assigning the work.
Passion projects reveal patterns that traditional résumés rarely show. At Scio, these patterns often turn into leadership opportunities because they indicate the kind of engineer who learns continuously, adapts quickly, and sees beyond immediate deliverables.
Comparison Module: What Side Projects Build That Day Jobs Rarely Do
Capability
Built in the Day Job
Strengthened Through Side Projects
Ownership mindset
Sometimes
Always
Multidisciplinary learning
Limited
Required
Experimentation freedom
Often constrained
Unlimited
Resource optimization
Only when needed
Constant
User experience intuition
Varies by role
Essential
Ability to self-direct
Depends on structure
Core skill
Passion-driven work reveals initiative and adaptability—traits that often open doors to leadership and high-trust technical roles.
Section 4: The Human Side of Building Something for Yourself
Beyond the professional value, there is a deeply human side to building something outside work. When engineers create something purely for fun, they reconnect with the part of themselves that first led them into the industry. The sense of discovery. The desire to understand how things work. The excitement of solving a problem on your own terms.
For Pedro, this aspect became even more meaningful because he shared the experience with his son. “We figured out the mechanics together,” he says. “It was fun not only as a developer, but as a dad.”
This matters more than most leaders realize. Software development has always been a mix of logic and imagination. Passion fuels both. Engineers who maintain that spark stay curious longer, resist burnout more effectively, and handle ambiguity with greater patience.
Passion does not replace hard work, but it lifts it. As Pedro explains, “When you enjoy the work, the hard parts feel different. You still deal with challenges, but they don’t drain you the same way.”
This distinction is crucial, especially in technical leadership. Passion generates endurance. Endurance supports mastery. Mastery accelerates growth and increases the quality of decisions engineers make under pressure.
Projects like FlyFlyFly become long-term confidence builders. They remind engineers that they can create, solve, and learn even in unfamiliar territory. That mindset strengthens entire teams, especially in organizations where innovation, experimentation, and continuous learning define success.
Conclusion: A Story About a Game, or a Story About Growth?
FlyFlyFly is still available in the Microsoft Store. But the real story lives in the journey of building it, not just the outcome. Pedro learned how to navigate new disciplines. He improved his technical instincts. He gained exposure to product thinking. He discovered unexpected IP challenges. He opened doors to new opportunities at Scio. And he reconnected with the creative spark that drives so many engineers into the field.
Every engineering leader knows that great teams are built from people who care about their craft. Side projects help nurture that care. They create environments where engineers push themselves, experiment without fear, and grow in ways formal training rarely achieves.
At Scio, we see these qualities often. Our teams combine strong fundamentals with curiosity, creativity, and a constant drive to learn. It is part of what makes nearshore collaboration so effective when the partner is aligned with your culture, expectations, and technical depth.
If you’re looking for engineering teams that bring this mindset into your organization, Scio is here to help.
FAQ
Yes. Side projects push engineers into unfamiliar territory where they must self-direct, experiment, and troubleshoot new kinds of problems. This sharpens instincts and often accelerates professional growth.
Not necessarily. But leaders can create psychological space for engineers to explore ideas. This often leads to innovation, better retention, and more engaged teams.
Absolutely. Teams with curiosity-driven engineers tend to adapt faster, communicate more effectively, and bring stronger problem-solving skills to client work.
This is where clarity matters. Engineers should understand their employment contracts and IP clauses before publishing or commercializing personal work.
It’s easy to see the idea of success as a default goal, something everyone should be looking for in any endeavor they start. And while it’s true that always looking for a specific destination is part of our nature, what does success mean? Because when we talk about success, it’s easy to forget that it never looks the same for everyone.
Truth is, success comes from a very personal place for most people, where our experiences and expectations shape the way we work and collaborate, and the specific things we choose to focus on. That’s why at Scio we believe that a good organization leaves enough space to let every collaborator reach success on their terms. So what is a success, then? As we were curious about what drives each of our developers and engineers, we sent a survey to all the Scioneers to ask this very important question: what does success look like to you?
The importance of balance
“Success is feeling in control of my personal life”, states one of the responses we got. “Being able to feel like I’m doing something valuable, having the strength and motivation to continue doing the things I love, and also being happy with the ones around me.” This image of success, for example, points out the important balance between work and personal life, one of the core values of Scio regarding their collaborators. We consider this is an important topic because developing software is as much of a creative endeavor as a technical one, and having people who keep healthy boundaries is crucial to always arrive at the best outcomes. To this end, fostering a good culture of collaboration and camaraderie is the best approach to ensure that a project is completed successfully, as it can also mean that your work doesn’t go unnoticed. “I like that Scio’s culture promotes the gesture of congratulating the team, both individually and as a whole”, says another of the answers we got. “I like the post-mortem charts we have about our successful projects, where they make sure all the team knows we are aware of their achievements. We even have social meetings to celebrate successful goals, which I think it’s a good idea. So let’s continue promoting the gesture of congratulating our teams for their achievements.” This is one of the examples of the ways Scio tries to maintain mutual support in everything we do, and something as simple as notifying everyone that a team has achieved a goal, or having a group call to just chat and relax, goes a long way toward it.
Success beyond the office
However, for some, success transcends the workplace and instead focuses on how it affects a collaborator’s everyday life. “Having my own home, seeing my kids happy, and maybe even running a marathon in another country is success” was one of the answers we got, as well as “Feeling full, and having yourself, your family, your significant other, your mind, your work, and your world in balance” and “Being able to do what I like in life and enjoy every second.”
This topic keeps coming out because a clear balance between work and personal life has been increasingly desired among both developers and companies starting to embrace the advantages of remote work and hybrid collaboration models, so making sure a healthy equilibrium exists is one of our core values here at Scio. “Feeling happy and comfortable with where you are”, another one of our responses, sums it up very well.
We understand that, due to the nature of software development, sometimes keeping this balance is tricky, even if Nearshore companies like Scio offer plenty of flexibility and options to work, so taking the steps to ensure that our collaborators can define success beyond the needs of a project goes a long way.
This also ties with another concept that many developers find attractive in any workplace: the chance to learn and grow as they work, which seemed to be a focal point in many of the answers we received. “Meeting the objectives and goals, keep the things I learned, as well as learning from the mistakes to improve”, and “Creating something of value that has a positive impact on the people you care about” get to the point of it, as a successful person might also be one that learns, grows and creates useful things from the work they do.
“Looks like having a clean conscience, lots of self-caring, not reserving everything to myself, feeling useful, achieving a wisdom state” was an unexpected answer. A lot of people can see success in purely personal terms (i.e. “how I feel about this thing I did?), so creating an environment where collaboration and personal growth are on the same frequency tends to deliver the best outcomes.
The success of living well
And last, it’s not a secret that many go into software development because it’s a very in-demand field with lots of organizations to choose from to collaborate with, and compensation is always important for anyone looking to join an organization that shares their values. “For me, is to be financially stable enough to give my family a better life, while also being happy in your job and what you like. To be successful is also to be recognized in your work and know that you are an important part of your company”, reads one of the answers, highlighting success as having the means to support your loved ones while also working on something you feel passionate about.
“For me, success is when your lifestyle and quality of life improves significantly and money isn’t an issue at all”, continues another of the responses. “While also achieving your personal and professional goals, feeling full and happy. Then you have a balance of these ‘pillars’ and yet you are further away from where you started.”
As we reveal more responses, we can start to see that “success” is, at the end of it, directing your life in the way you want to, down to every detail, as this answer manages to explain beautifully: “For me, success has many shapes. From small achievements to the greatest goals, success can happen anywhere, in any place, both in our personal and professional lives, in the financial sense, or even with the people around you”, trying to get across how success is present in our daily lives.
“Even in defeat, we can see success in learning something, feeling good about it, making ourselves proud, and gaining more knowledge in return. If we see it like this, anything we achieve is a success.”
So what do you think? How do you personally define success and how does it get reflected in your personal life? Is it something concrete you work towards every day, or a state of life you want to achieve? Because no matter what your definition of success is, at Scio, we are willing to lend you a hand and achieve your best possible outcome.
If you search on the Internet for «agile project initiation» you are going to find a LOT of templates. People want structure and easy answers, so of course, these simple answers rise to the top of every search. Many (if not most) of the templates offered are pared-down formats from the Project Management Book of Knowledge (PMBOK) Project Initiation Documents (PID). There is nothing basically wrong with the idea of using templates or most of the templates offered, except – they tend to become prescriptive when they should be taken as guidance.
Working software over comprehensive documentation,»
With that in mind, we should ask – why do we document agile projects? Often, the answer is – because it is required (by someone) when in reality the answer should be – to communicate. But again, that simple answer fails to guide us to the necessary outcome:
Documentation should be a natural part of agile project initiation, but not the goal. It should proceed from on-going discussions between stakeholders, the product owner and the development team that is developed in Sprint 0, but it must not end there. The conversations and the documentation of outcomes must continue through the lifecycle of the project and the product.
Initial documentation is just a strawman
Documents gathered from product owners and key stakeholders are starting points, not final documents. Documents developed by a designated team member to fill out a template are strawmen to be examined, discussed, questioned, and used as a base for the ongoing development of understanding within the entire project team.
Living documentation formats should be preferred over static. In smaller projects, it may not be necessary to manage documentation formally, but in most cases using the same concepts as those used for source code management is a valid guideline. Properly maintained, living documentation answers the questions, «when was this decision made? by whom?» and gives a revision history that tells the story when necessary, but only makes it apparent when needed. It needs to include simple artifacts of these discussions – photographs of whiteboards, screenshots of modified mockups, etc. – in preference to notes developed after the fact and out of the sight of the team.
During Sprint 0, the aim must be to develop enough trust among the project team members to allow questions and dialog to form the base for a common understanding of those items that are included in most PID templates. If initial documentation is «handed down from on high» to team members without open, trusting discussion – it cannot be internalized by the team and it will not respond to the inevitable changes that will come as discovery and learning continue throughout the project. Agile software development embraces change by allowing the project team to recognize the inconsistencies and discoveries that will come out during development, surface them and deal with their impact through discussion and collaborative negotiation.
And before we get too far away from it – there are some really strong ideas in the Agile Modeling page on Agile/Lean Documentation. Honestly, though, there is a lot of information in that reference that should really be digested as a part of understanding agile, not as a guideline for a new project. For that purpose, this short piece is a better resource. But, if the outcome of project initiation is not a bunch of filled out PID templates that we can all take back to our cubicles and file away – What is it?
Agile Project Initiation is All About Communication
With the ideas we have mentioned in mind, we have to acknowledge that open, trusting, collaborative communication does not happen automatically in an agile project team. There are natural stages that every group will go through before they can have the kind open discussion needed without fearing it will harm relationships and respect. Discussions need to be wider than the project infrastructure, technology, and user stories, without the feeling an individual is stepping over the boundaries by asking about non-functional issues. We might need to know:
Does the culture and background of key user profiles matter to the software development team?
Does the role of key subject matter experts (SMEs) in product development for an organization make a difference to who needs to be included in discussions?
Are we using a Lean Product Development model with the inclusion of stakeholder users as part of Minimum Viable Product (MVP) development?
If we are working in a DevOps implementation, how does that change our standard production procedures?
There are all sorts of questions that are not (and cannot be) included in standard PID templates but could be critical to a specific project. If we don’t discuss our viewpoints and ask questions, we run the risk of assuming we have a common understanding and making decisions based on those assumptions. Every project, every team, every organization is different. In the best case, we can open ourselves up to collaborative discussion by getting the team together, face-to-face during project initiation, for dialog and team building using team games and facilitation with a bias to being productive, explorative, and fun. Using these techniques, we can strengthen the bonds and shared risks necessary to maintain a successful project throughout its lifecycle.
In cases where face-to-face project initiation is not possible (hopefully more rare than the rule), much can be accomplished with video/voice meetings if they are relatively short and like agile documentation, structured just enough to ensure the meetings reach necessary outcomes and allow for continued direct discussions among stakeholders in the team when needed. There is nothing much worse than sitting in a meeting where a long, passionate discussion between two team members seems to be sucking all the air out of the room – and the meeting outcomes are lost.
This piece is relatively short and again, more of a guideline than a prescription for agile project initiation, as it should be if we are to «eat our own dog food.» Bottom line:
Don’t be afraid to pull out a template when you start your next project, or when you look at it – crumple it up and throw it away so you can start your own list based on what you know and don’t know.
What you think you know or don’t know are assumptions and should be treated as such both during project initiation and throughout the project. Only a discussion with open questions between team members can validate ideas and give us a basis for moving forward. And the assumption that is understood as valid today may not be completely correct at another time.
Documentation must be limited to what is necessary when it is necessary and maintained throughout the project as living knowledge. Agile documentation should not be the domain of one person or one role. It must be available and dynamic – allowing everyone on the team to contribute when necessary – in a wiki-style rather than as a bunch of locked Word documents.
Agile project initiation should focus on both the productive side – bringing together the information needed to organize the project, initialize environments, and the functional user stories needed, as well as the people/team side – developing the understanding, trust, and communication necessary to work collaboratively throughout the project. Ignoring either side is perilous. Assuming the job is done at the end of Sprint 0 is fatal.
Scio is a vendor of agile, nearshore services for software development projects with our customer base in North America. We can provide project-based or dedicated teams as required for each situation. We would be glad to discuss how our broad base of experience and skills could help you be successful with your next project. Contact us for more information.
As a provider of nearshore successful software development services, Scio has a proprietary interest in assuring the success of our customers’ outsourcing projects. But of course, in that respect, we’re no different than any service provider. So, it could easily be said that this article and more that will follow on this critical subject have a built-in bias we can’t ignore. We want you to understand our experience, our business model, and how it shapes our approach to providing outsourced services. We hope that understanding will lead you to explore working with us and to hire our team. So yes, this is an exercise in self-interest…. But that said, we also have an interest in promoting improvement in our industry and the knowledge of critical success factors (CSFs) for the outsourcing of software development. This certainly isn’t a new subject – both the buyers and the sellers of outsourcing services have been trading tips, CSFs, and white papers on the subject for years. A quick Google search will turn up thousands of papers from professional societies, trade journals, buyers and suppliers in the field. But it is a sufficiently rich subject, with ongoing learning and improvement, to continue the conversation among participants. Do we have important information to add? We believe we do and we’re willing to expose our knowledge and experience so you can judge for yourself. To begin the discussion, let’s set a few common terms in context:
Outsourcing is a broad subject and different industries approach it from different angles. In basic terms, we’re only discussing the outsourcing of software development, but many of the lessons learned in outsourcing across other industries do apply. The term comes from tying together the words used to describe «outside resourcing» – bringing resources from outside a company to meet business needs. With that in mind, outsourcing can describe the contract of work to a provider in the same building, city or country, just as well as it can describe the outsourcing of work to a provider in a different country or a different continent.
Information Technology (IT) Outsourcing is generally considered to be a subsector of Business Process Outsourcing (BPO) that involves operation, management and maintenance of IT services and infrastructure within an organization. Although technical skills are necessary to maintain aspects of IT operations, generall software development is not the primary driver of IT outsourcing contracts.
Offshore or Offshoring is a term that, like outsourcing, has many meanings specific to the industry where it is used. For our purposes, it means the use of service providers with working hours that have very little or no overlap with their clients. Generally, these providers are on different continents with completely opposite work periods. A great deal of successful software development outsourcing is done by offshore providers so it is not intended to have a negative connotation. But, in many software development projects, communication and collaboration are key and in that respect, using offshore services requires special adaptations that both the client and the provider must be aware of and enforce.
Nearshore or Nearshoring in our context refers to the contracting of work to providers in a different country that shares significant working hours overlap and often shares a border, region or continent. Scio is a nearshore provider of software development services to North American clients. Our services leverage the benefits of a nearshore relationship with our clients so the situations where we work best tend to exploit those advantages. Successful software development outsourcing relies to a large degree on the relationship between the client and the service provider and the requirements of the work itself. Some software development can leverage nearshore advantages better than others. Some providers have adopted practices that lower the risks inherent in software development outsourcing, regardless of their physical proximity to their client teams. Regardless, understanding the differences between offshoring and nearshoring of software development projects is an important subject for all participants in the industry. There is no «one size fits all» as evidenced by the growth of both nearshore and offshore development centers within large outsourcing consultancies.
Agile Software Development is a methodology that is widely used across the software development industry. It is based on the idea that software development projects should be composed of short, iterative cycles producing valuable software incrementally while allowing for the evolution of the results based on constant consultation and interaction with the client and user base. The methodology itself is constantly improving and allows for adaptation to many situations. Because of this flexibility, the agile practices adopted for one project or practiced by a development team will vary, but overall the basic principles as they apply to client and team interactions and software quality during a project are expected to remain.
Scrum Software Development is an extension of the agile framework for software development down to the team level. It includes descriptions of roles, processes, and ceremonies that strengthen agile principles and give structure to the software development process. Like agile, it is an adaptable methodology but it does include more detail specific to the software development process. Scio provides software development teams using a proprietary implementation of agile and scrum. Not all software development projects require agile or scrum, but most can benefit from some level of integration with the methodologies.
Distributed Agile Teams are a part of the outsourcing of software development when you use either nearshoring or offshoring of a part of your agile team. In agile/scrum methodology, a premium is placed on open and frequent, face-to-face interactions between the development team and the product owner from the client-side. But, agile is also practical and adaptable, so there are practices that help to overcome the team isolation and improve interaction when parts of your team are remote. Scio is a provider of distributed agile teams for software development and integrates the practices necessary to assure success in these situations in all our projects.
What is a Successful Software Development for You?
It is hard to discuss «success» without knowing what it means to clients in general and it is almost impossible for a specific project to be «successful» unless all participants understand what it means from the start. In simple terms, most people would say without thinking it means providing software on time, on or under-estimated costs and that delights users – but that simple definition ignores all the trade-offs and pitfalls that need to be avoided or mitigated and the stakeholders who must be satisfied to arrive at a successful outcome. In researching the literature on this subject, an IEEE literature review came upon the subject that found some interesting results:
Top 5 CSFs for Success in Software Development Outsourcing
Contract Flexibility
Trustworthy Relationship Management
Competitive Bidding
Consultation and Negotiation
Quality Management
Last 5 CSFs for Success in Software Development Outsourcing
Time Management
Culture Awareness
Intellectual Property Rights
Data Security and Privacy
Detailed Specification of Product and Project
These results came from a specific set of criteria concerning the basis of the outsourcing contract and relationship, as well as the contract and contract management – rather than a soft assessment of project outcomes, so it is probably not what you might think at first. But consider the elements of the top 5:
Contract flexibility, like agile practices in software development, this allows the project to evolve in various ways to reach a successful outcome. It is a realization of the simple fact that at the outset of a project, and throughout the development cycle, participants don’t know what they might discover or how they will work together. A flexible contract, instead of locking them into a tight box, provides a framework for realizing opportunities not foreseen at the beginning of a project or dealing with unexpected issues that might derail the project. A good contract focuses on the objectives of the outsourcing relationship rather than operational details.
Trustworthy relationship management gives everyone involved the ability to bring issues up without fear and mistrust. It allows open negotiation during the development process without bringing everything to a screeching halt. Again, it acknowledges the established truth of software development – there are things we don’t know and opportunities we haven’t considered that will be discovered as we move forward. We won’t be able to consider them if we don’t have a relationship of trust between the players.
Competitive bidding, when it is done not just on price, but on a range of weighted factors, helps to increase the feeling of trust and control between the service provider and the client. Everyone understands what is important from the outset or has explored the issues until a successful conclusion is reached. Blind bidding, where bids are submitted, but no discussion or negotiation occurs among the top bidders and the potential client do not build this level of understanding however. No amount of paper and diagrams can substitute for the level of understanding that can be reached in direct, verbal negotiation.
Consultation and negotiation are a realization of the fact that constant communication is necessary in all software development projects to insure the development is on track to meet the goals set out in the beginning of the project or, where needed, the teams can negotiate in good faith to reach alternative outcomes that better fit the situation as it has developed. Virtually all software development projects need both a mechanism to ensure open communication and negotiation.
Quality management, not just against a set of detailed requirements (that is number 15 in this list after all). When everyone is involved in quality, it becomes a key to reaching a successful outcome. But as the agile methodology guides us, only if the management of quality is a continuous process throughout the incremental software development process. If it can only provide feedback at the end of prescribed phases or the end of the project, the risk of going off-the-rails becomes too large and failure to reach the necessary outcomes of a project area almost assured.
Now, of course, you are likely to see a different list in your head or have a specific list of CSFs in mind for a project. But list brings up an important consideration – what weight should you put on the need to deal with change and to work successfully with your vendor throughout a project or relationship? And it is important to understand, this is a result of the frequency of a CSF being identified among several papers, not the weight it was given in any one paper, if indeed weights were given. So the number of times a CSF was mentioned in the surveyed literature produces the order of the list.
Nearshore? Offshore?
We find these kinds of communication problems come up in many aspects of the provider/client relationship in outsourced software development. Agile and scrum development practices address these problems well, but in the case of offshore services, the agile model becomes stretched in ways that require adaptations that can be costly or distracting in the course of project operations. That is not to say that nearshore distributed teams, a model we use frequently, do not require specialized planning and adaptations, but it is part of our standard practice package, not something we do on a one-off basis. We find all projects benefit from attention to better communication and tighter relationships between our teams and their product owners. And we have that built-in advantage of nearshore; our development team is working in real-time with the client team. There is a lot more to discuss successful software development outsourcing – and we will be doing just that as we continue to provide information from the field.
We find these kinds of communication problems come up in many aspects of the provider/client relationship in outsourced software development. Agile and scrum development practices address these problems well, but in the case of offshore services, the agile model becomes stretched in ways that require adaptations that can be costly or distracting in the course of project operations. That is not to say that nearshore distributed teams, a model we use frequently, do not require specialized planning and adaptations, but it is part of our standard practice package, not something we do on a one-off basis. We find all projects benefit from attention to better communication and tighter relationships between our teams and their product owners. And we have that built-in advantage of nearshore; our development team is working in real-time with the client team. There is a lot more to discuss successful software development outsourcing – and we will be doing just that as we continue to provide information from the field.