Remember Blackberry? Once a dominant force in mobile phones, they failed to adapt to changing customer needs and were ultimately surpassed by Apple and Android. This cautionary tale highlights the importance of customer discovery, even for established tech companies. A study by Gartner reveals that acquiring a new customer can cost 5 times more than retaining an existing one. Customer discovery is an investment that can pay off in spades by ensuring your product remains relevant and keeps your existing customers happy.
What is Customer Discovery (and Why Do You Still Need It?)
Customer discovery is more than just a fancy term for market research. It’s about fostering an ongoing conversation with your customers to understand their evolving needs and frustrations. Here’s why it’s crucial even for companies that have been around for a while:
The Customer Churn Challenge: Did you know that according to bain, even a 5% churn rate can significantly impact your bottom line? Customer discovery helps you identify potential churn risks and proactively address customer concerns.
Staying Ahead of the Curve: Technology and customer expectations are constantly evolving. Customer discovery allows you to identify new trends and opportunities before your competitors.
Planting New Seeds: Real-World Examples
Here’s how some established tech companies used customer discovery to adapt and thrive during the pandemic:
Intuit (TurboTax): Intuit didn’t just use customer discovery to improve tax filing features. They also focused on user experience. In response to feedback about complexity, they introduced a simplified filing option. During the pandemic, this focus on user experience proved critical as they catered to a broader audience filing for unemployment and stimulus checks for the first time.
Airbnb: Airbnb leveraged customer research to understand the changing travel landscape during the pandemic. This led them to introduce “flexible search” and “longer stays” features, catering to the rise of remote work and domestic travel.
Dropbox: Dropbox recognized the need for enhanced collaboration features through customer discovery methods like user interviews. They responded by developing integrations with popular productivity tools, making Dropbox an essential tool for the remote work revolution.
Zoom: Zoom’s constant focus on customer feedback allowed them to identify features critical for the remote work environment. Based on user needs, they prioritized video call security, ease of use, and integrations with popular calendar applications. This data-driven approach kept Zoom ahead of the curve during a time of massive user behavior shifts.
The Customer Discovery Toolkit for Established Tech Companies
Ready to breathe new life into your tech company? Here are some actionable tools to get you started:
User Interviews: Have in-depth conversations with your customers to understand their current frustrations and unmet needs. Focus on addressing their specific pain points related to your product or service. Ask questions like: “What are your biggest challenges using our product?” or “What features do you wish our product had?”
Customer Surveys: Gather broader customer insights through surveys with a mix of open-ended and closed-ended questions. Tailor your survey questions to address common challenges faced by established tech companies. For example, you could ask questions about customer satisfaction with your current product roadmap or their openness to new features.
A/B Testing: Test different product features and marketing messages to see what resonates best with your current audience. Use A/B testing to validate your customer discovery findings and measure the impact of changes based on customer feedback.
Bloom Again: Make Customer Discovery a Priority
Customer discovery is a continuous process, not a one-time fix. By regularly assessing your customer landscape and planting new seeds based on their needs, you can ensure your tech company flourishes for years to come.
For over 18 years, I have had the privilege of working with software development teams in Mexico and other countries in Latin America, while serving clients based in the United States. This unique professional journey has provided me with invaluable insights and experiences, highlighting the benefits and challenges of the Nearshore model in the realm of software development. In this blog post, I will share some of the key lessons learned and the remarkable advantages that emerge from this collaborative approach.
1. The Nearshore Advantage:
The Nearshore model refers to the practice of outsourcing software development services to neighboring countries with geographical proximity and cultural affinity. Latin America, with its rich pool of talented professionals, has emerged as a preferred destination for US clients seeking high-quality software solutions. The proximity offers significant advantages such as overlapping time zones, cultural similarities, and ease of travel, making collaboration seamless and effective.
2. Cultural Alignment:
Latin American countries, including Mexico, share cultural affinities with the United States, such as a similar work ethic, business practices, and familiarity with American market dynamics. This cultural alignment fosters effective communication, shared values, and a deep understanding of client requirements. It also helps create a harmonious work environment that facilitates collaboration, trust-building, and successful project outcomes.
3. Proximity and Time Zone Synergy:
Latin American countries, including Mexico, offer a nearshore advantage to US clients by being in the same or similar time zones. This proximity allows for real-time collaboration, agile development cycles, and seamless communication. The ability to address client queries, provide timely updates, and resolve issues promptly has been instrumental in maintaining high client satisfaction levels and fostering long-term partnerships.
4. Cost-effectiveness and Value Proposition:
The Nearshore model in Latin America provides a cost-effective alternative to onshore development while ensuring the delivery of high-quality software solutions. The region offers competitive rates for software development services compared to the US market, without
compromising on talent and expertise. The cost advantage is complemented by the region’s robust infrastructure, technological capabilities, and access to a skilled workforce, making it an attractive proposition for US clients.
5. Language Proficiency and Communication:
Proficiency in the English language is a key strength of Latin American software development teams. English language skills are highly emphasized in education and professional settings, enabling effective communication and seamless collaboration with US clients. The ability to comprehend complex requirements, actively participate in discussions, and articulate ideas fluently has been a significant enabler of successful project outcomes and client satisfaction.
6. Agile and Collaborative Approach:
Latin American software development teams have embraced agile methodologies and collaborative work environments. They prioritize close collaboration with clients, iterative development cycles, and frequent communication to ensure that project goals are met effectively. This agile approach, coupled with the Nearshore advantage, allows for rapid adaptation to changing requirements, quick decision-making, and accelerated time-to-market for software solutions.
7. Knowledge Sharing and Professional Growth:
The Nearshore model in Latin America has created opportunities for knowledge sharing and professional growth, both for the software development teams and the clients. The exchange of best practices, industry insights, and technological advancements between the US and Latin American professionals has fostered a mutually beneficial learning environment. This continuous knowledge transfer has elevated the skill sets of the software engineers, enabling them to deliver cutting-edge solutions.
Conclusion:
The experience gained over 18+ years of working with software development teams in Latin America, particularly Mexico, while serving US clients, has reaffirmed the remarkable advantages of the Nearshore model. The cultural alignment, time zone synergy, cost-effectiveness, language proficiency, agile approach, and knowledge sharing have collectively contributed to the success of this collaborative model. Through bridging borders, we have witnessed the power of diversity, innovation, and efficient project execution. As the world becomes increasingly interconnected, the lessons learned from this experience will continue to shape the future of software development, encouraging global collaboration for mutual growth and success.
Craftsmanship is timeless, being an integral practice to human history since the dawn of our species. It represents a quality of uniform excellence, often characterized by removing unnecessary elements from a design and bringing out the best in the crafted object. And although craftsmanship is often associated with aesthetic pursuits like painting or sculpture, its importance goes beyond; it serves as a powerful reminder of the value of hard work and skilled ‘hands-on’ effort, a notion that helps us tap into our creativity and realize our ambitions. Mastering craftsmanship, therefore, is not only a source of motivation but also a means to change our current place for the better.
And considering how technology is the biggest agent of change in our world, it might be interesting to find out if the idea of craftsmanship has a place in this modern computer-driven reality. Is there craftsmanship to be found in software development? After all, programming consists of a combination of hard skills, innovative techniques, and a love for constantly perfecting processes that translate into high-quality products. It can be said that developers practice a craftsmanship approach in every project, taking pride in the details and focusing on making changes that have a clear impact on performance, stability, scalability, and many other aspects of development.
However, for most people, it’s easy to overlook the art behind software development, but the craftsmanship is present in every little task. From developing feature-rich designs and diagrams to writing clean and error-free code, the job of a software developer involves multiple levels of precision and detail that demand proper diligence. A well-crafted software is an accomplishment, just as a well-crafted painting or sculpture would be, with each step involving thoughtfulness, attention to detail, and careful consideration. There’s an almost creative element to writing software since developers must find ways to solve programming puzzles with innovative ideas and stylish solutions, so designers must have some artistic understanding of how users interact with technology. Nonetheless, this approach must coexist with the demands of an industry that is always moving forward, making today’s software development an incredibly ingenious and complex task that must always rise to the challenge.
The balance between craftsmanship and business
Crafting software is an attempt to capture a responsive balance between the idealistic embrace of artistic virtue and the practical needs of a business environment. On one hand, developers want to use their creativity to build something meaningful that reflects a sense of usefulness and long-lasting quality. On the other hand, there are ever-present realities that require careful decisions about timelines and budget, and finding harmony between these factors while developing software can be hard to navigate. However, it’s by solving this creative tension that developers ultimately can create elegantly well-rounded solutions.
Still, it’s no small feat: both angles need to be taken into consideration when pursuing a successful project. It takes careful forethought, planning, and collaboration from everyone involved (developers, project managers, stakeholders, etc.) to prioritize craftsmanship over profit while still satisfying the business demands. The biggest challenge here is maintaining quality while meeting time and budget constraints; if a product is rushed out the door too soon or neglected too long, users will pay the price with buggy applications or poor feature implementation, so it’s important to have an experienced team of professionals who understand their collective responsibility to craft perfect software while keeping in mind all other key objectives.
As we have already mentioned, the importance of craftsmanship in software development can often be overlooked. It’s easy to rush through a project to meet a deadline and sacrifice quality, but this doesn’t end well in the long run. Quality software is efficient, minimizing user frustration and increasing overall productivity, and crafting robust software requires an investment of time and thought that demands an eye for details both big and small. High-quality craftsmanship requires rigorous testing before deployment, as well as regular updates after implementation to ensure maximum efficiency at all times. In other words, software craftsmanship may involve an initial extra effort, but it pays off by creating an outstanding user experience for years.
Thus, craftsmanship is an idea that one should take care of and pride in when writing code. Being a software craftsman involves learning, understanding, and researching best practices to write amazing code, with a developer constantly asking themselves questions such as: are there better ways to refactor this piece of code? How can I make this easier to maintain? Is there an accepted design pattern that I could use here? By taking the time to ask these questions themselves, developers can ensure that their software is of higher quality and more robust than it otherwise would be, the result of putting your knowledge, dedication, experience, and passion for problem-solving at the forefront. Craftsmanship in software development requires attention to detail, continual refinement from iteration to iteration, and an interest in learning new technologies for their work and aims for excellence when building quality products.
Craftsmanship at every level
True craftsmanship in software development can be seen in its intricate details. Developers who take their time to create their projects with a focus on the elegance of style and precision when producing games, websites, or applications that stand out from the crowd. Crafting a piece of software to be efficient and durable takes skill and talented developers to understand the importance of meeting user expectations, and making sure their work lives up to those standards by adding creative touches wherever possible. Part art, part science—true craftsmanship in software development makes the difference between an ordinary application and one that really shines when developers care about…
Writing clean and maintainable code: Craftsmen developers strive to write code that is easy to read, understand, and maintain over time. This means using meaningful variable names, avoiding duplication, and following established coding standards.
Building scalable software: Good software craftsmen know how to design and build software systems that can scale to meet the needs of a growing user base. This means understanding how to distribute workloads across multiple machines and designing software with horizontal scaling in mind.
Emphasizing testing: Crafting software means placing a strong emphasis on testing. Developers who practice craftsmanship ensure that their code is thoroughly tested and they use automated testing tools to make sure that any changes they make to the code do not break existing functionality.
Being efficient with code: A software craftsman understands the importance of being efficient with code. They know that every line of code that they write has an impact on the overall performance of the application, so they strive to write code that is as lean and efficient as possible.
Continuous improvement: Finally, software craftsmen are always looking for ways to improve their skills and the quality of their work. They stay up-to-date with the latest tools and techniques, and they are always looking for ways to improve their code and their processes.
In short, software development is an ever-evolving understanding of how coding works and communicates with different systems. By developing software, coders, and engineers are constantly pushing the boundaries of what can be done, learning from a variety of sources, and tackling complex tasks in efficient ways. It’s hard work, but the craftsmanship exhibited within can be extremely rewarding, as it offers an opportunity to create something useful and marketable that solves a problem or makes life easier for everyone. By continuously pushing their own boundaries of excellence, software developers are able to develop projects that achieve unprecedented levels of quality while ensuring usability and scalability. It’s this iterative approach that separates the best software projects from those just good enough—and it’s the commitment to continuous improvement and craftsmanship exhibited by software developers that allow users to seamlessly interact with highly sophisticated products.
The Key Takeaways
When it comes to software development, the value of craftsmanship cannot be overstated; creativity and artistry are critical for any successful piece of software out there.
What craftsmanship provides is an inspiration to always become better, strive for a better result, and grow new skills and talents that will result in a more positive outcome for any project.
However, finding the balance between craftsmanship and the business needs of the organization can be tricky, and must be navigated carefully.
Craftsmanship is found at every level of a development project, and the best developers will take it seriously to build the best possible product at the end.
The show must go on: Developing a venue booking app with UPick
As the year winds down, it’s time to look back and celebrate all of our achievements of 2021, the challenges and the goals we conquered, and the clients whose projects we helped to become reality.
This time, let’s take a look at the story behind the development of the UPick app, which had the goal of creating a useful and reliable booking tool for both venues and artists, and how we helped them bring that dream from concept to a product you can use today. Enjoy!
What goes into making a good idea into reality? For the creators of UPick, it meant finding a reliable team that could build upon their idea, understand the concept completely, and offers the best technical know-how to bring it from paper into every smart device you can imagine. The beginning was simple enough; back in 2020, a couple of friends were looking into an area of opportunity no one else seemed to be exploring yet: what if you could simplify the process to book a show for a venue through an app?
The pandemic gave them a wide-open window to implement a solution for an industry that felt the consequences of this crisis deeply. Live shows account for nearly 50% of the music industry’s revenue, so six months into the pandemic, according to the World Economic Forum, shutdowns had already cost venues around the world 10 billion dollars in sponsorships and ticket sales, with no end in sight.
But with vaccination rates increasing, it was probably a good time to try and bring shows back, and UPick’s creators thought that an app that offered a quick way to reconnect performers with venues had some fertile ground to grow.
So, in February 2021 they started considering Scio as a partner, looking for developers who could create this app from scratch, decide the full scope of the final product, and make important decisions about the direction of the platform.
This was the first time our clients worked with Nearshore developers, and the advantages of having a fully experienced team equipped and ready to roll inside your own time zone became invaluable, keeping the costs of development down without sacrificing quality.
Since our clients had never been involved in a project of this size, constant communication to decide the specifics of UPick was critical, going from things like how to monetize the service, to the best hosting platforms to use.
Typically, development at Scio consists of a 5-step plan designed to arrive at a solution in the most productive way possible. Understanding users and their needs, as well as the objectives and constraints of the app itself, was Step 1. Step 2 involved analyzing the requirements of the app in order to trace a plan for the UX/UI and architecture of the platform. Then, Step 3 is pure Agile Development, up to the official launch, which was Step 4. And after the kick-off, is a matter of support to ensure the quality of the app, giving ongoing maintenance and adding features as a Step 5.
The Scioneers chosen were a Programming Lead who developed the architecture of the app, a UI designer tasked with creating a comfortable and stylish interface, another one assigned to create a search bar and review functions within the app, and a QA lead who would make sure everything worked perfectly.
Communication was key. Thanks to daily scrums, a core pillar of our process, we walked our client through the progress of the project, needing nothing more than 15 minutes every day to discuss the changes and challenges that surfaced, as well as what we accomplished, every week.
Here, we solved tons of questions born during development, like “how will a band schedule a show?”, “how will refunds work?”, and “how will the venues and bands make deals?” to more technical matters, like choosing a cost-effective hosting solution (AWS in our case), implementing login credentials from Apple, Spotify, and social media (including some necessary workarounds), to selecting the best payment processor.
Also, as we briefly mentioned, the business plan of the app had to be revised entirely once the booking process was decided, as Upick could easily be cut out from the deal between venue and performer, and our team took care of that.
The biggest breakthrough was deciding to make UPick a “progressive application”, where a web portal could function as an app with consistency across devices, like desktops and smartphones, making it as convenient as possible.
Then features were added, like the ability to share photos, videos, setlists, and even playlists from Spotify, and we had to rethink the way bands could contact venues as our understanding of these deals grew.
Progress went smoothly until finally reaching our Minimum Viable Product, where one of UPick’s users, whom the client showed a preview, managed to run all of their bands through the platform before it was 100% finished, which not only showcases the talent of our team but also made the customer base excited about the final product.
All in all, by September the app was ready to be launched, a whole project contained within the chaotic year of 2021, where Scio was able to offer the exact solutions UPick was looking for. A learning experience for both our team and our clients, we celebrate the effectiveness of Nearshore development, which can deliver no matter the circumstances.
The Key Takeaways:
Since communication is crucial to make a product succeed, choose a development option that can communicate with you at the best time possible.
It doesn’t matter if the details of your idea haven’t been ironed out yet, a good team will help you with those decisions.
Development time of an app, depending on scope, doesn’t have to be too long. It took us around nine months to bring UPick from concept to reality.
Some APIs are not very friendly, but there are always workarounds to any obstacle.
If better ideas surge during development, it’s good to always voice them. The schedule might need to be reworked, but the final product is always going to be better.
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.