When we think about the landscape of software development, it’s easy to fall into a binary view: people either work at a tech start-up, with the allure of innovation and cutting edge technology, or they work with a corporation like Google, Microsoft, or Amazon that promises stability and long term rewards in exchange for creating products with a more incremental and risk-averse pace.
There’s plenty of content about what it is like to work in both kinds of organizations, with lots of writing devoted to discussing the virtues and drawbacks of each, but are those the only two options in software development? What happens with mid-sized software companies, and in which ways do they distinguish themselves from either start-ups or big companies?
Outputs and outcomes
Let’s try and define the actual differences between these three types of companies, specifically in regards to how they view and measure product development objectives. After all, a software organization can be defined by the outcomes they want to achieve, and the outputs they decide to focus on to reach them. But what do these terms mean? In the words of Kirstie Magowan, from the BMC Blog:
The outcomes are what the business wants or need to achieve.
The outputs are the actions or items that contribute to achieving it.
Or in other words, “outcomes are the results, and outputs are the activities that support the desired results”, and clarity of purpose for both of them defines what a given organization focuses on to develop the best possible products.
So, within product development for software companies, outcomes are things like new version releases, new features implemented for the users, faster development cycles, improved quality, etc. On the other hand, outputs are things like software requirements/user story documentation, UI/UX prototypes, code, database scripts, test cases, DevOps scripts, and so on.
However, some nuance needs to come into play at this point since we can imagine that organizations of different sizes and maturity cannot all seek the same outcomes. We’ll explore it in more detail, but in our experience, the main force that drives start-ups, mid-sized companies, and big corporations is that their target user bases have different expectations of their respective products.
The weight of expectations in development
“The top desired outcome for a start-up development team, working on the early stages of a new product, is to build an MVP as fast as possible so the company can launch it and attract enough early adopters to keep iterating an idea”, says Luis Aburto, CEO, and Co-Founder of Scio, about his experience working with companies of all sizes. “At this point, you have a ‘forgiving’ attitude among the user base if the product shows enough potential. Early adopters will frequently overlook some issues if the value they get in return is enough and the product has a clear roadmap of features and functionalities that will improve the final version in the future.”
So the challenge for a start-up is to iterate a product fast enough to establish itself before interest dries up. After all, if we define a start-up as “a temporary organization designed to look for a business model that is repeatable and scalable”, the push for innovation is always running against time, looking to please early adopters enough so the product gets accepted in the mainstream. That way, you get organizations more willing to bend the rules, avoid the bureaucracy that comes with very defined processes, and overlook some production requirements (like documentation) if the team is small and their output is focused on delivering a product.
“In contrast,for a big company”, Luis continues, “every time you implement a new feature, you have an opportunity to either delight your users or cause a catastrophe. Suppose you are an organization that has maintained a product for 10 or 15 years. In that case, there are a lot of dependencies and expectations that come along with that, and if you are not careful, test everything closely, and research your market fully, you can end up in a position where you can damage your clients and users. What if they depended on certain features or functionality for their jobs, or had important data stored inside the product? The outcomes here would look very different, as the “forgivingness” of your user base gets lower the more mainstream it is.”
These expectations, then, dictate the best outcome for a given organization, and in turn, these outcomes will dictate the outputs needed to achieve the goal. However, the unique challenge here is that, while outputs can be defined and measured easily, the outcomes seek to “change a behavior in the user”, which is a much more subjective and nebulous goal. To this end, Natalie Diggings, of OpenView Partners, proposes a set of questions to evaluate the performance of any given team with an outcome-focused mindset that can help engineering teams and management alike to keep their goals aligned:
Are you delivering value for the customer?
Are you delivering results each quarter that will help grow the business?
Are you mitigating risk?
Do you know the ROI of the features you’re building?
Did you ship when you said you would ship?
“What we try to do at Scio, by implementing the Agile methodologies in every project we work on, is to establish a minimum of processes and continuous communication to ensure the output our team contributes to the desired outcome for the product, avoiding misaligned expectations and other issues”, continues Luis about Scio’s experiences working with start-ups. “And for a big company, we try and secure a seamless on-boarding of our developers, as these organizations have clear and defined processes that we like to follow to a T to fulfill these same expectations.”
Mid-sized companies: Hitting the sweet spot.
However, Scio’s area of expertise is a segment of the software development industry that doesn’t seem to have that much attention directed at the mid-sized range of companies that hit the balance between a start-up and a big corporation, which has some unique benefits worth exploring.
For example, if we go back to expectations, outputs, and outcomes, an organization of around 50 to 100 people is still guided and directed by the vision of its founders, which seems to bring some advantages that balance out the issues of the other two types of companies.
“Working with a big, Microsoft-like corporation seems like a no-brainer, but at that size, and the bureaucracy that comes along with it, there’s a very limited impact you can have in a given project. But with a medium-sized organization, where you still have the opportunity to work directly with the founders and share and understand their vision, alongside an organization still looking towards the same clear goals, collaboration becomes a more personal matter. Is a business with a human element still felt”, Luis concluded.
These kinds of connections are important when you look for a partner to help you reach a specific outcome, as a “clarity of purpose” can still be shared among the development teams, executives, and product owners, with the benefit of the structure, processes, and methods of a mature organization. After all, before hitting the “millions of users” metric, a mid-sized company still has the chance to push innovation forward with minimal risk.
This is also another big difference between these three kinds of organizations; for a start-up, risk in pursuit of innovation is the name of the game, and for a big corporation, incremental improvement with stable growth is the norm. Having an approach that can still make use of both perspectives is what makes working with these companies so interesting.
“On the business side, a mid-sized organization still looks to grow, but the relationship with their users and clients still has a personal touch, with support and communication at a human level, which allows them to get new clients more easily while still maintaining their current ones. And in the development size, the cohesion between collaborators, both in-house and outsourced, still has a clarity of purpose in their outputs.This is the way Scio functions, and also why we like to offer their support to mid-sized companies; our communication, collaboration, and goals always come hand in hand during a project. With this, the best outcomes are more measurable, reachable, and all in all, understandable”, concludes Luis.
The Key Takeaways:
An outcome is defined by the expectations of the clients of a given company, which should be taken into account in every development cycle.
Clarity of purpose is critical; if your dev team doesn’t know where their work is pointed towards, then it’s difficult for the output to match the outcome, which can vary heavily depending on the age and size of the organization.
Companies of different sizes have different strengths and weaknesses, but a mid-size company can have the best of both worlds: the processes necessary for a project to succeed, while still maintaining cohesion among its collaborators.
The personal relationships that can grow during collaboration are important for the outcome of a project, as they make it easier for a team of collaborators to share a vision and purpose in their outputs.
How to measure productivity effectively? Adolfo Cruz, Scio’s very own Project Management Office director, offers insights into a question many in the business have in their minds all the time.
By Adolfo Cruz.
Building an exact image of productivity is a question with no definitive answer yet. Defining what “productivity” means for someone starting a business for the first time is a complex process. From everything I’ve learned these 14 years at Scio, each person needs to discover what works for them, considering the specific context in which they are trying to succeed.
The thing is, when trying to measure productivity in something as fluid as software development, every seemingly useful metric comes from a different perspective (be it from the client, the developer, or the managers), so if you want to establish a baseline, I would recommend defining priorities first, taking into account your business needs.
How do we measure productivity in Scio?
Early in Scio’s history, around 2008 or so, we tried to implement Agile Methodologies along with some number crunching, like the hours put on a project or the number of bugs, to know exactly how productive our teams were. However, the number of variables involved, like realizing that a specific team had better outcomes because they had certain chemistry between them, made it difficult to translate the results into measures that could be implemented in any project.
So we moved away from that, instead of looking at the results from the client’s perspective, thus defining our productivity as the value our developers are adding to a product during development. Our measures became more focused on people than metrics because helping a client to build a product, adding value at every step, and therefore growing their business, was our main priority.
To this end, building a perfectly calibrated development team that proposes new things, learning and evolving together was the best approach for Scio. A lot of the time it’s not even necessary to keep a register of everything happening during development because the team itself realizes when something’s not right and works out any issue; a team of developers capable of self-management is always a good sign.
If you achieve such a team, you don’t need to measure specific metrics for each collaborator, instead, you evaluate the team as a whole, looking for relevant information that can help them grow, so you should think of questions that help you get the information you need.
For example number, many User Stories were completed in a given time?
Was there any serious bug in the development of the product?
How many bugs surfaced?
What priority did these bugs have?
How did the team respond to them?
How long did it take?
However, these questions need to be constructed with the project’s context in mind; although there are a lot of metrics you can use to generate specific “productivity” numbers (like the Personal Software Process popular in the 90s that tried to define productivity through the number of lines of code written), if they don’t reflect reality, then the team will not know how to use this information, as many of the challenges they face can be subjective.
So avoid trying to arrive at exact numbers, and instead, I recommend you to look at the trends emerging from one project to another. A trend interpreted correctly should give you a “big picture” of both performance and productivity, showing places where your attention or some improvement is needed.
First, look for a certain range of information in a development cycle; If the team completed between 5 and 10 stories in a sprint, but only 1 or 2 the next one, there’s probably a red flag somewhere in need of attention. Then dig a little into it, and maybe you’ll find some unforeseen challenges the team needed to prioritize to keep making progress. And finally, make a note out of it, so you can improve the circumstances around an issue so it doesn’t reappear later; that’s how an understanding of productivity begins to emerge.
Most of the trends we watch at Scio are about how our developers contribute to our client’s goals, and we developed some tools to measure that. For example, we use the Team Self-Assessment, a guideline for collaborators to reflect on their work, that we adopted and modified according to what our experiences and specific contexts dictate.
In our TSA, there’s a section where we inquire about bugs surfacing during development, asking how they are preventing issues during development, if they are doing Pair Testing practices, if they are showing their additions to someone else before moving on, and generally if they are focusing on things that matter.
When a team reviews these questions, they realize their areas of improvement, and we work together to avoid falling into them again in future projects, because what you want to do is push your teams into adopting excellence as a natural part of their processes, encouraging them to add their experiences and expertise to the final product.
The subjectivity of a productive team
Productivity is not always a purely technical approach; sometimes you need to look at the business side of things, involving the stakeholders and product owners in the creation of the product to reconcile a multitude of perspectives, converting them into priorities to define the best course of action.
Just remember that you need to experiment in software development, build an iteration of the product to validate its potential, and look for features that can be improved to maximize its success. Your development team will probably need to go back and rework a lot of stuff, updating their methods to create a more efficient version of the product, so your definition of productivity here has to account for it; if stuff is being redone, at least quality should always be improving.
So, to recap, a good measure of productivity is established by defining your business priorities and then choosing the metrics that best reflect the context in which the product will be built. A productive development process gives enough flexibility to iterate and experiment without neglecting business needs, and having your client’s goal as the focus of your team is a great starting point.
Just remember that if you aren’t adapting what you learn into your specific context, capturing the information your team needs, then productivity might suffer. Software is mostly a creative enterprise, so some subjectivity will always be needed to properly define what makes a successful project, fine-tuning every cycle to achieve the value you want for a specific product. With an approach like that, you can be sure your organization will always be improving.
How to measure productivity? That’s a question that many in the business, from CEOs to coders to engineers to managers, have in their minds all the time, and Adolfo Cruz, Scio’s very own Project Management Office director discusses metrics, measures, and meanings of productivity.
At the end of the 90s, a methodology called “Personal Software Process”, or PSP, was designed to help developers measure their productivity. You had to take a course, there was a lot of documentation to follow through, and you had to use a timer to measure your progress, stopping it every time you needed a cup of coffee or to go to the bathroom.
The idea was to see how much you accomplished in a day, but in fact, this methodology was entangled too closely with the number of lines you wrote, meaning that you were more productive the more you coded, which is not necessarily true.
But if this is not productivity, what is it?
I define “productivity” as finishing a task in a reasonable time. The word “finishing” here is key because productivity is not starting a lot of things, but seeing a project to completion, right until you get a product. However, how do you define exactly when something is “finished” in software development? What criteria do you have to fulfill to say something is done? If we were building something physical, let’s say a boat, first, you need to build a hull, and this phase ends when it fulfills certain requirements.
And although not all boats are the same (building a freighter or a yacht would look very different), in essence, you have the same process, blueprints, and requirements to do it. Software development doesn’t work that way.
Developing software involves a lot of things. You may see it conceptualized as a “factory”, or a development team working like a well-oiled machine, where you input requirements and get a product at the other end. But in truth, there’s an artisanal quality to developing software; everyone has their approach and style, and progress changes according to the team you are with.
This results in a lively debate where no one agrees on the best way to measure productivity. If you ask a room full of developers how many lines of code they write to see if they are productive, you can get a very heated discussion, because how are you measuring that?
The best code is concise and everyone checking it can understand it, so I don’t know how you can see someone writing 10,000 lines of code and conclude he is more productive than someone achieving the same in 500. Maybe it made more sense at a time with no frameworks to build things faster, when everything was a bit more rudimentary and you coded every single piece of the product, but today you have to write very few things from scratch, with a whole range of tools that let you produce, let’s say, the shell of a website in a minute without coding anything directly.
So imagine if a company starts giving productivity bonuses based on lines of code produced per project. They would end up with developers gaming the system to get the bonus or at least trying to not look worse than their peers by writing less, resulting in bloated, inefficient products because the incentive wasn’t centered on creating something useful.
You have to be very careful when linking rewards to metrics, or else you’ll generate a perverse environment where everybody is just racing to inflate numbers.
The Scio way
I’ve been with Scio for 14 years, and since then, perspectives have changed. With the arrival of Agile Methodologies, we moved on from counting lines of code to seeing how that code comes together, achieving working software whose process of development is not focused on numbers, but on how the product is going to be used.
To give you an idea of this evolution, not long ago the requirements of a project were written from the point of view of the system, so every requirement started with the phrase “The system shall…”: the system shall do X thing, the system shall do Y thing, the system shall do Z thing, etc.
So you ended up with a massive document repeating “The system shall…” for every little thing. Then the Agile Movement centered on the user, with requirements stating “The Administrator can…” or “The Manager can…” because we understood that software is not about a system that “shall” do things, but what people in different roles “can” achieve with the product, resulting in productivity built around how much value we give to the final user, not how much code our devs write.
Coming back to Scio, we see it from the perspective of the stakeholders and clients we are building a product for, and our productivity is measured on the information we get from them, knowing how our teams are doing, how much value they are adding to a project, and what their perception of the whole process is. It’s a more people-oriented approach, far from the days of counting lines of code, and more interested in understanding how a developer is contributing to the goals of our clients.
To that end, we developed some internal tools, like the Team Self-Assessment, based on our prior experiences, consisting of questionnaires about the things we consider important for a team to focus on. For example, there’s an entire section about quality, how they are preventing issues during development, if they are doing Pair Testing practices, or if they are doing code reviews to make sure the code is maintainable and scalable…
Are they giving issues the proper attention? Are they documenting them? The team members have to ask themselves if they are focusing on the right issues, and if they aren’t, it’s something we have to improve. That’s how we try to motivate our teams to share their experiences, practices, and insights into our client’s projects.
It is said that only 35% of software development projects succeed, and I think it has to do with the planning stage of a product. Let’s say I want to complete the A, B, and C steps of a project in six months, based on previous experiences in similar projects. But it ended up taking 8 months instead of 6 because something needed to change, does that 2-month delay mean the project is going wrong?
It happens a lot with start-ups trying to create something completely new. In the course of development, it’s common to see something, a feature or function of the product that changes the client’s perspective, that taps into some potential we haven’t seen before, so the plan has to get reworked to harness that and bring its full potential. In six months, priorities can change.
But if we measure the productivity of the process very rigidly, and then that very same process brings out the value in unexpected places that, nonetheless, force you to rework entire parts of the project, it’s easy to see it as a failure.
The Project Management Institute uses these rigid measures a lot, asking for a specific basis, beginning, and end of every phase of a project, and if you don’t deliver them exactly as planned, then you get a mark against you. In an actual software development environment, that doesn’t happen, because the dynamics of a development cycle can change fast.
Software development works by evolution
The measures you have to use are subjective more often than not. Some industries require strictness, especially when manufacturing something, but in the world of software, and start-ups in specific, I don’t think it’s necessary to be like this to create a successful product.
This is why we back away a little from the technical aspects of a project and focus instead on the business side of things, having conversations with stakeholders and product owners to get them involved, reconciling all these points of view about what the business needs, and how development is.
We take a look at the features planned, check how many people ask for them, how critical they are for the business model to work, and decide how to proceed from there, adding real value by focusing on building those pieces first. Technical aspects are solved later, as you first see what the business needs, and then the technical team starts sketching solutions for the challenge.
Productivity is a question with no definitive answer yet.
Considering all this, forming an exact image of productivity is a question with no definitive answer yet. Every individual has to decide what works, but only in the specific context in which that person is acting, so no one has come up with a universal method to measure productivity in software development, as even the perspective from which you measure can change; seeing it from a client’s perspective is a world apart from a developer’s.
As you discover better routes during development that weren’t foreseen during the planning stage, or maybe because the technical aspect ended up being unfeasible for one reason or another, or the infrastructure cost is too high for your purposes, or any other number of reasons, a lot of what you may define at the beginning of the project will change.
You adapt, which is very different from building furniture or producing food, where it is clear what you are trying to accomplish over and over. But in software, where there’s no single solution for the same problem, it’s difficult to reach a consensus on what you need to do in detail.
However, you want to measure productivity, metrics evolve, and whatever method you use to decide how productive your team or your company is, I think the Agile Methodologies got it right, where it doesn’t matter the number of lines, or the documentation you have, or how pretty your database is, what matters to the client and the final user is having software that works.
The idea of a future when AI can perform all sorts of tasks, even programming, is irresistible, but is it something feasible? Is programming a job that can be done by machines, and if not, why?
By Scio Team
One of the biggest leaps of these past two decades, and indeed the most intriguing technology development of the 21st Century, is the advancement of Artificial Intelligence that seems to occur every day. It is understandable why; science fiction technology has a sort of magnetism that attracts all kinds of engineers, entrepreneurs, and visionaries, many of them with the cash to back up the R&D necessary to bring these visions to life.
AI also has the allure of being potentially implemented anywhere, automatizing plenty of daily tasks to free up our time. It’s also attractively dangerous, as countless Terminator jokes can attest every time a new development hits the news.
However, what is actually feasible for AI to accomplish? What are its real applications, at least for now? For the last 7 years or so, there have been some talks about AI being capable of performing more intensive labor, programming, and development among them, but is the job of the programmer in danger of being done by a robot?
It’s easy to imagine, at least. Plenty of tools already use some measure of AI to function, and interesting experiments crop up daily, from intelligent chatbots to autonomous machines. But are those tasks comparable to the actual job of programming in any way? Because as an engineer or developer knows, writing code is just a small part of the whole process of creating software.
“Processing large amounts of data? Software’s great at that. Figuring out what a human wants, or what a usable UI is like, or what the real problem you need to solve is… those are hard”, says an entry in the blog Code Without Rules titled “When AI replaces programmers”, which goes directly to the big issue in a future of machine-produced code.
Although there have been some advancements on the idea of teaching an AI to write code and produce entire programs, like the experiment done by Andrej Karpathy in 2015 where he trained a neural network with GitHub’s Linux repositories to write its own code, the results are still mixed. According to the site Perforce.com:
“[The] AI generated code (including functions and function declarations) overnight. It had parameters, variables, loops, and correct indents. Brackets were opened and later closed. It even had comments. However, the AI produced code had syntactic errors. It didn’t keep track of variable names. Sometimes variables were declared but never used. Other times variables were used but not defined.”
Of course, this was way back in 2015, and the technology behind these networks has only improved since then, but the actual viability of letting a machine program by itself one day, especially for more critical areas like Defense, Finance, or Healthcare, it’s still far away and will still be at the mercy of human instruction.
The advantage of outsourcing these kinds of tasks, be it to a remote developer or an entire Nearshore company, is the ability to communicate clearly anything you may want in the software produced. Collaboration is constant, communication is key, and the skill to apply different ways to solve issues is a given in any valuable development team.
This is to say, the “creativity” involved in these kinds of efforts is still a long way off, and having this skill while programming is critical to producing code that solves actual problems and accomplishes the expectations of both clients and final users.
“There have been some experiments before, even since the 90s, with tools whose purpose was to generate applications”, explains Adolfo Cruz, Scio’s Project Management Director, and the best person to have an idea of where this technology is going. “If you wanted to generate a User Form, for example, you defined the parameters (first name, last name, age, date, etc.) and these programs delivered a simple but functional result.”
“Those very early tried, but they worked and now it’s evolving to full-on Artificial Intelligence. However, if these tools become a reality, they’ll probably lack the spark of human imagination. During development, a programmer sometimes gets ideas about cool features that could add value to a project, and these kinds of things will be difficult to achieve for a machine.”
“But beyond that, I think we’ll see software coded by machines. Maybe there will be a point when an AI can understand and interpret the user, getting a command like “create a chat program” and propose three options, which can be narrowed by the user.”
For sure, these three options would not take any time at all for a machine, but deciding which path to take from there, refining and redefining options, could be a tiring process, although, in terms of man/hours invested, it’ll need a lot less effort than having multiple people working on this same project.
“Still, there are a lot of questions unanswered”, Adolfo concluded. “How long would it take to explain exactly what you want, what frustrations would that cause, and how that impacts the adoption of this technology is a whole discussion to have. It’s not simply about technical feasibility, but acceptance among the public.”
When we hear the word “agile,” the first thing that comes into our mind is the quick ability to respond to change. This skill is crucial, especially if you want to adapt to the evolving world of technology.
This term represents how you are able to think and respond to uncertain situations you will come across.
Agile software development involves practices and frameworks based on certain values and principles in software development. It uses planning, test-driven development, sprints, and pair programming, among others.
Approaching software development in a specific method can help you understand exactly what you need to do in a particular scenario.
It is important to know your duty and responsibilities as an agile software development manager. Hence, we have come up with a list below to help you succeed in your role.
What is the Role of an Agile Software Development Manager?
A lot of companies empower their teams to self-organize with an expectation of committing and delivering their goals on time. While bigger organizations may have different agile teams, they continue to use self-organizing principles to manage the roles of the team members.
Each technique used in agile software development has a clear and defined role that varies. To be able to work effectively as a team, each member needs to know what their role is as well as those of other team members.
Hence, it is important to define the responsibilities of an agile software development manager. Generally, the manager helps the team members excel in their specific roles while making sure that the process is up to standards using agile principles.
Overall, the manager ensures that the team delivers excellent results.
Here are some of the most important duties of an agile software development manager.
1. Project Planning and Management
As a manager, you need to define the scope of the project, create an efficient workflow, and a realistic delivery schedule. At the same time, you are expected to be on top of everything, including leading, organizing, and preparing the progress reports.
Part of the role of a manager is to project plans and make necessary changes if required.
Managers must ensure that the project runs on schedule and everyone is updated in the process. An agile manager should also live and breathe the agile process and principles so that you can tackle the project more effectively.
2. Team Management
One of the most important duties of an agile software development manager is to manage your team properly. By assisting the teams and holding each member accountable, you can efficiently improve the work process.
You should guide and mentor your team properly, especially as they undergo a stressful environment.
Most agile projects require a critical timeline. Therefore, you need to ensure that the project gets completed on time.
As you manage your team properly, make sure you don’t micromanage them. Avoid overstepping and respect their roles. How you treat them can have a huge impact on their work process and output.
3. Risk Management
A good agile development manager should know how to clearly identify risks and come up with an effective risk management plan. By resolving issues, it helps keep the project moving.
Part of this task is to ensure that there are no conflicts within the team members, the budget is on point, and the tasks are achievable.
As a manager, you need to anticipate potential risks in advance so that you can determine the steps of how to avoid them. By creating risk development plans, you prevent your team and company from wasting time, effort, and money.
4. Process Management
A well-defined process creates more structure to the workflow. Make sure you identify and follow the best practices in agile software development.
Divide the project into segments and distribute them among team members so that you can reach your target goals within the given timeline.
Keep the workload balanced so that no member falls behind. In an agile environment, the communication between the team and the product owner is crucial in terms of meeting deadlines.
5. Team Building
Part of managing your team is to empower each member. Make sure that everyone is engaged in the project and is contributing to the goal. You should manage their tasks at an achievable pace without sacrificing the quality of work.
An agile software development manager should act as a mentor to his team. Hence, you should follow the basic steps in management which include coaching, one-on-one meetings, and providing constructive feedback.
At the same time, you need to ensure rapport between the members so that they can work better as a team. A successful manager encourages the team members to bring ideas to the table.
Conclusion
An effective agile software development manager is crucial to any organization. However, the job requires knowledge, research, and hard work. Most organizations require software development and continuously adapt to the automated and digital world.
To be a successful manager, we highly encourage you to fully embrace various responsibilities such as project planning, team management, and risk development. In an agile environment, you need to learn how to adapt and react quickly to any situation that may arise.
If you need additional support in setting up your roadmap, we at Scio can help you find the best solution to achieve your business goals. Talk to us today!
Of course, the first question for anyone looking at this is – what is the difference? Let’s start by saying that we’re not speaking specifically about “product engineering” – although it plays a part in this discussion. We’re actually looking at software development teams broadly, how they work and what they can (and can’t) do for your development efforts.
Today’s IT environments can be complicated beasts – with unique mixes of internal and remote API’s, web services, service-based components, virtualized infrastructure, and various open source, proprietary and custom applications. Orchestrating this architecture to provide the internal and external business services for an organization is an increasingly critical operational concern. Depending on the size and complexity of the environment, it is likely to be managed by one or more skilled engineers who are focused on the security, standardization, automation, scalability, availability and reliability of IT systems.
Traditionally, software development teams have been separated from this complexity to some degree by internal standards for application architecture and operation developed by IT. But, as the maturity of IT environments has progressed and agile has become the standard of the tech industry, software development teams are gradually being integrated into combined engineering and engineering teams under DevOps implementations. At this point, there are many different levels of integration between IT engineering and software development teams and if you are considering outsourcing a project – knowing what you are asking for is an important part of your research and decision process.
So, let’s set up a scenario: You are about to embark on a custom software development project. For the sake of this discussion, let’s assume the application to be developed is strategic and tied to your business model. With so many applications and systems available on the market, if it wasn’t – you would probably just adapt an off-the-shelf application for your purpose. You have a charter and description of the business problems your custom application needs to address, a general budget and executive support. The decision has been made to outsource this project rather than do it in-house.
With that in mind, let’s insert some different conditions that could make a significant difference in your needs for an outsourced team:
New, but fully-backed venture with basic organizational structure but with no IT engineering beyond office systems automation and help desk.
Existing IT team with legacy experience but little experience with modern infrastructure or IT operation patterns. No dedicated development team or significant custom applications.
Traditional operations, IT and software development but siloed – not integrated other than by operational standards.
An enterprise-level organization with a fully-integrated IT operations and development team in a DevOps style implementation with a significant portfolio of custom applications that are under continuous development and/or maintenance.
A new venture of an existing entity that is expected to operate as a free-standing organization based to a large extent on the services provided by the new application(s) developed during the project.
There are other complexities we could imagine, but for the most part, they can be addressed as variations of these five scenarios and the basic conditions we set up for this discussion.
1. The New, Mostly Naked, Venture
As a new and growing company, there is always (or there should be) pressure to be efficient and do things right from the beginning. If you have a technical leader in your team and/or a significant part of your operation is based on leveraging software applications to provide your services, there is a natural tension – should you focus on your customers, your value proposition and lead your software development at the product level (leaving the actual development to an outsourcing partner), or should you build and control everything in-house? We’ve covered this question before and it is a significant decision – but now, we’re considering a little deeper level of thought. If you are considering an application that will actually support all or a significant part of the services you offer and your revenue – the proper operation and maintenance of that application is a strategic decision.
Your application must be:
Planned with a set of operational standards in mind.
Scalable, so it can grow along with your business without significant rewrites and basic changes in architecture.
Logically broken into maintainable and extensible modules so it can be enhanced and the value of individual services can increase as they find their place in your portfolio.
Reliable across upgrades, changing loads, and new features through the full product lifecycle.
Economical to operate and maintain based on a solid architecture and the ability to leverage automation across all levels of development, deployment, and maintenance.
Photoshoot at Cluster 8/1/16
If you are a new venture and you want to spend your time focusing on your customer, the value of your services, and managing feature-fit, you shouldn’t expect an outsourced development team to simply take on these issues from day one. They may deliver a wonderful application that provides everything you need, except the five points above. Although your customers will be happy, you have just purchased a load of technical debt. Like any loan, it will come due at some point and the longer you wait to deal with these shortcomings – the more expensive they will be to retire.
So as an entrepreneur with enough problems on your plate, you have a choice (remember – our scenario is that you’re going to outsource this project):
Dig in and hire a really competent engineering team that has real world experience in larger operations and understands where you are going. It is going to be expensive, time-consuming and at times – frustrating. You will have more expertise sitting around than you need in the early days, but it is an investment you need to make in lieu of the cost of redoing much of your early work when all your predictions come true. You don’t want to have to operate your business while changing the undercarriage as it speeds down the road. Once you have your engineering team and they understand your business model and where you are headed, they can manage your outsourced development team – but with both sides being new to you it is likely to be a fairly inefficient match in the beginning. Expect six to nine months to hire, train, and begin your project and another period of time integrating your outsourced team (which you also have to select) and your in-house engineering to the point where the combined team can be productive.
Find an outsourcing partner that can provide the engineering skills as a part of the team they provide. If you find the right vendor, the team should be scalable with the resources you need, when you need them. The application should be designed with the five points above in mind from the start. If the vendor operates as a partner with your organization, doing that part of the development and operation successfully is part of their value proposition to you. If the outsourced team has broad experience (as they should) they will bring to the table a range of solutions you may not find otherwise. They have worked in the market and delivered solutions in many different situations. Finding the right vendor will not be as quick as it might be if you were only looking for an outsourced development team (there are many pretenders in the field), but in the end, you should be able to get your project running faster, with better efficiency, lower cost, and risk.
The choice is yours and (of course) there are other factors you may have to consider in your situation – but at a high level, if cost, time-to-market, and lowering distractions from your emerging business are concerning, an outsourced engineering and development team would seem to be a strong option.
2. Existing IT Team, No Internal Software Development Team & Little or No Current Experience with Custom Apps and Modern Infrastructure
At first, this would seem to be a simple match for an outsourced development team – and in some cases it may be. But, the lack of current experience with custom application development and modern infrastructure in this situation should be concerning. Companies in this position tend to be service-based, SMB/E organizations with established client bases, regional strength in their market and a strong, competitive need to grow. As we pointed out at the beginning, we are assuming there is a budget for this project and the company is committed to outsourcing but – they have an existing market and they can’t afford to burn their existing customers while they transition to a new or expanded level of services. Because of that limitation, even without considering the eventual operation and maintenance of the new application once it is released, an organization in this position can’t afford to overburden their existing staff with development of a mission-critical, custom application and the operational planning needed while they continue to serve and maintain their existing services. The staff must be involved in the changes but only to the extent that they need to be to be able to take a role as things move forward.
Again, we come down to some choices:
Hire one or two technical leads/product and project managers who will take the position of planning the new application, its architecture, and operational requirements while managing the outsourced development team. They will need to be much more experienced than the existing IT team so there will be some initial friction and it will (again) take time, be costly and frustrating. It will take time to get them up to speed and integrated into the team before an outsourced development team can be selected and put to work. The reason to use only one or two resources, in this case, is to hold down costs, but doing so will only make each resource more critical and (probably) more expensive.
Hire outside consultants to develop the operational architecture, requirements and train your internal team. Since the internal team is unlikely to be large or have the skills necessary, there will still be a need to hire additional internal resources, but it can be delayed to some extent. The downside of this strategy is that when experienced staff is added eventually, they may or may not agree with the direction put in place by the consultants and there may be a period of realignment and unexpected technical debt. Also, the use of external consultants to manage all or part of the work done by the outsourced development team can create an “arms length” relationship with the development team that can make it difficult to have the level of collaboration and trust you need to avoid communication problems, especially with agile development.
Find an outsourcing partner that can provide the engineering talent as a part them team they provide. If you find the right vendor, the team should be scalable with the resources you need, when you need them. If the outsourced team has broad experience (as they should) they will bring to the table a range of solutions you may not find otherwise. They have worked in the market and delivered solutions in many different situations. If you want to transition the outsourced team out at some point, you will still need to hire additional staff for operations and maintenance of your new applications, but you should be able to have them work in parallel with your outsourced team during the transition and lower the burden significantly.
Any of the three options could be successful but if you find the right outsourcing vendor, it would be a faster, less costly and less risky route to get your project going. But, of course, it depends on finding an outsourcing vendor with the option to include engineering skills in their team and to have a flexible approach to providing the team you need.
3. Siloed Operations, IT & Software Development Teams
This scenario lends itself to slightly larger and more technically-based operations than we discussed in the second scenario. This is the type of organization we expect to find in an established ISV with a strong client list in a specific vertical. Their operations are usually as they have been for a decade or more. Their IT staff is established and has a strong operational base. Their software development team is well-versed in their existing applications, the technologies they use and the customer base they work with. If they didn’t have to step out of that box to build this new application, we can easily assume they wouldn’t need to outsource and their engineering is just fine for what they are doing today.
But that is the rub. We’re examining a scenario where they need to extend themselves into new technologies and possibly change their operations significantly. And because we’re assuming their teams are informal, separate silos – we’re also assuming they know about the higher efficiencies they could achieve if they began to shift to a DevOps methodology but – again, like our second scenario, they have existing customers and products/services in the field to maintain and support. Like most companies in this situation, their backlog of feature requests for their existing software is just what they can handle at the moment. Adding another layer of work would just mean something would have to give. An outsourced development team, in this case, makes sense and this organization is likely to have customer-facing product development well-in-hand. But, what they don’t have is a scalable organization to match the importance of the project and a broad understanding of new technologies and architectures they need to consider to streamline their organization.
So, in this case, an outsourcing vendor who can bring in engineering experience as a part of their team skill and experience, a flexible, scalable team makeup and willingness to work in a partner role to help their existing team rethink and realign their operations could be a real asset. It is risky to try to do both at once with the same team, but if both teams have regular work to do and can collaborate to adapt operations over time it can be an opportunity that would be nearly impossible any other way. Again, the critical step is to have the skilled resources available as an integrated part of the team who can lead the effort to plan architecture and operations before development gets underway and you find that serious adjustment is needed. There are risks in this scenario, certainly, but there is also an upside to making changes in parallel with everyone onboard the organizational development and change initiative.
4. Mature Enterprise with Integrated DevOps style IT and Software Development
Again, we’ve moved the situation up the scale a bit but we’re still committed to outsourcing and we’re still considering what type of a team we need. In this case, the internal team has an implementation of DevOps and even if it is not complete, it is moving forward with staff support and commitment. Like scenarios two and three, our existing team has a number of custom applications in production and knows what it is doing when it comes to operations and development. We can assume they are fully engaged and the time allotted to this project is short, or they would simply hire as needed and do the project internally.
Since this organization has a DevOps implementation, there is already an assumption that new development resources will have experience in both development and systems architecture for continuous development and maintenance. Bringing on a team that doesn’t have that type of cross-functional experience and mindset would be a serious problem. They simply wouldn’t be able to hold up their end. In this case, if the project is to be outsourced, the incoming team must be able to handle both engineering and agile software development if they are going to hold up their end and integrate with the larger team successfully.
5. Spin Out/Off Venture with Software-Based Service
You might think this scenario would be a lot like the first, but spin-out ventures tend to be better positioned and planned simply because they usually come from organizations with a strong market position and goals that are carefully evaluated before the venture is started. In most cases, staff members come from the “mother ship” with a background in product development and deep understanding of the market they are going into. But, because the loss of technical resources inside the home organization could seriously impact production there for a prolonged period, they rarely pull out more than a few senior IT resources. With that in mind, their team is usually fully aware of current technologies and methodologies, even when they may come from an organization that culturally has not be able to move to them as quickly as they might wish.
A spin-out gives this core team an opportunity to move in fresh directions with less organizational baggage and legacy overhead. So, in some ways, they may look like scenario two with little IT in the beginning – but the big difference is they have experience in the product development side of custom software and how supporting systems can be orchestrated. They are better positioned to evaluate partners and decide on the roles they want in-house versus outsourced. Since we said at the beginning that all scenarios would be based on a decision to outsource – the question is still, “Do we just need an outsourced software development team or do we also need an integrated engineering component?”
The decision comes down to how much of the burden the mother organization wants to continue to shoulder and how expensive the “charge-backs” would be if they did. Leaders of spin-outs usually have strong stock incentives to keep costs in line and move relatively quickly to prove their direction is worthy of the risk. If using existing services inside their home company would create complications, slow product development, and increase costs – they will think twice about that direction. Since we have specified that they have already decided to outsource this project, we can assume they are not looking to spend any time taking on problems that do not get their services and products into the market. But that said, we know the IT resources in the venture are limited and if they want to go to a modern continuous release methodology so they can incrementally improve and tune their applications, they will need to have flexible, integrated teams of engineers and developers from the beginning so that their applications are architecturally and operationally sound from the beginning.
Bottom Line
The bottom line here is that software development is shifting away from internally-focused product development,siloed enterprise teams and monolithic applications to incremental release patterns, agile organizations, and customer-focused lean product development. Not everyone is there now. There are many different ways to implement change. But, all of these organizations have chosen to take on custom application development for a strategic initiative, the opportunity now is to do it better with an eye toward the future of their organization. This is just one small part of the change they seek, but it is an important one to consider. So, yes – an outsourced team that brings a range of engineering skills and experience along with their development background can be a big advantage for any of these situations, with a vendor who will operate as a partner in the organization.
Scio provides nearshore, outsourced software development and flexible teams with a range of software development and engineering skills based on our experience in many verticals and situations. Our teams can have flexible roles and their bias is toward agile methodologies broadly. If you have a project in mind, please contact us to discuss how our unique blend of skills and experience can benefit your organization. We would be happy to take the time to listen and provide insight into how we could partner for success.
But that is the rub. We’re examining a scenario where they need to extend themselves into new technologies and possibly change their operations significantly. And because we’re assuming their teams are informal, separate silos – we’re also assuming they know about the higher efficiencies they could achieve if they began to shift to a DevOps methodology but – again, like our second scenario, they have existing customers and products/services in the field to maintain and support. Like most companies in this situation, their backlog of feature requests for their existing software is just what they can handle at the moment. Adding another layer of work would just mean something would have to give. An outsourced development team, in this case, makes sense and this organization is likely to have customer-facing product development well-in-hand. But, what they don’t have is a scalable organization to match the importance of the project and a broad understanding of new technologies and architectures they need to consider to streamline their organization.