Agile Methodology, Entrepreneurship
The field of software development has a lot of roads, some are more challenging than others. And for Nati Lara, a Front-End dev currently living in Denmark and mom to a toddler, these experiences have been incredible. How does remote work and software impact her job as a mom and developer?
By Scio Team
Whenever someone asks me what I do for a living and I tell them I’m a software developer, the response almost always is “You must be very smart!”, because this preconceived notion of this job is that only the more intelligent persons can do it and, well, no.
It’s like when I see a carpenter doing their thing, and I say to myself “I could never do that”, but if it really interests you and you want to make your ideas into reality, it’s within everyone’s reach.
I started programming back in High School when a teacher helped us learn to use Delfi by designing a simple website. It was a very interesting exercise, having to do an entire page by myself; it was the final project of the semester and everyone did whatever they wanted, but I got really into it.
It was a gripping challenge because the teacher didn’t explain much, so we had to make with whatever solution and tools we had on hand, and I liked that a lot. Delfi already has some basics, so we didn’t have to start from scratch, writing zeroes and ones, which changed my ideas of programming. I used to think it was a black screen with green text on it like in the movies, so it was a different experience.
I used to like computers a lot as a kid, my parents got their first one when I was 10 years old, but I didn’t know anything that had to do with programming. I was curious about interfaces, not as much as the inner workings, and that’s what I specialize in today.
That’s why I do Front-End in iOS, I like things where I can see the result. I don’t get too much into Back-End stuff, where I don’t have a clear vision of how things are working, I prefer working on things where I can see the immediate result.
As a developer, the best feeling I get is when I can put my ideas in motion, and make something useful out of them, building a work of art without using my hands directly, so to speak. I like working with others, knowing everything about every part of a project, and contributing in a specific direction. The client I’m currently working with makes vegan and vegetarian food; the chefs here run the kitchen and develop recipes that avoid meat, trying to show that the absence of it still results in a good dish.
Their clients subscribe to the app I’m maintaining, and they get pre-made meals for three days, all vegan. There are many ideas involved with this project, like showing how much CO2 is being saved by avoiding the consumption of meat. I like it because, beyond the food, it tries to show the individual impact we have, and it even changed my conception of vegan and vegetarianism, which has changed since I work here and now I want to do my part.
The road here wasn’t a straight line. I originally studied Art and Digital Animation, because even though I always had some affinity for STEM stuff, I also liked creativity, drawing, and graphic design, but I didn’t want to go completely in that direction. So I tried something that had a bit of everything, but I ended up realizing that I liked it a lot, but maybe I wasn’t as good at it.
At some point, I started developing web pages with a friend that wasn’t very good at programming, but skilled at designing, so we started taking freelance jobs where I did the technical stuff and she did the visual part of the project.
That is how I ended up pursuing a Master’s degree in Software Development because I found it the best way to keep in touch with both worlds. I’m a developer, and I like having an opinion on everything visually going on during a project; when doing a website, I like to make sure everything lines up, looks good and works well. Even if I don’t consider myself the best designer, I like to pay attention to the details of it by programming.
For a degree like this, a proportion of 30% women does not sound like a lot, but it is, even if women are the most prone to abandon it before finishing. In Digital Design it was more balanced, around 50/50 or so, but here it was a noticeable difference. I think this ratio holds in most engineering careers, and in our culture at least, more women go for careers in Humanities like Arts or Social Studies, and a lot less in STEM.
My dad was a teacher, and he always raised us close to the sciences, so it wasn’t an issue for me, but my parents did prevent me from trying things like sports, especially soccer. I mean, I still don’t play it, but I also never had the opportunity, even if my dad somehow planted the seeds of interest in sciences like math.
As a female developer, though, I have never felt out of place or made feel less, although I’ve never worked full time in Mexico. I currently live in Denmark, and so far I have been the only woman in the Tech team of both companies I have worked at.
There were more women at school, that’s for sure, but right now we are fifteen people in the Development department, and to be honest, I like it that way. A lot of owners and entrepreneurs are feeling the pressure of attracting women to close the gap between male and female developers, so it has been easy for me so far to find a place to work. Being a woman in this industry is an advantage some of the time. There’s nothing to be intimidated by.
It’s even funny sometimes. At work parties, I’m the only one trying to dress well and use make-up, and my friends like to joke about it, saying that my job is making sure everything looks great, so of course, I do those things.
That being said, it’s curious to notice that, at companies like Scio for example, most women tend to gravitate towards analytical and QA stuff. I wonder why that is. I’ve never met another woman doing Test Automation or things like that; last year a girl started working with us in Full-Stack but doing Data Analytics, and everyone else has always been men.
It’s something I talk about a lot. I have many friends dedicated to Humanities, and we always discuss the differences between our fields; in the case of one of them, her office is almost purely women, with one or two guys here and there. I guess there are many reasons for it, and I have wondered before why it’s so important to close gaps in certain areas.
I don’t see a field dominated by either gender as something inherently wrong, if these differences were dictated by more biological, natural affinities, like women being more social or men being more analytic. But when those exclusions are cultural when we try to separate genders from childhood by allowing kids to play with certain toys only, we are creating inequality, and something should be done about it. And this is a change that we are not going to see in the next year or two, but it will take maybe an entire generation to change these points of view.
Now, in the actual job, do these differences matter? Maybe I have different aesthetic sensibilities and ideas of how things should look, so I can tell my coworkers an application needs, but I’m not sure that’s because I’m a woman, or because I have a background in Design. Who knows?
Being a developer has also brought other advantages for me. I have a son currently four years old, and working in software gave me a lot of leeways to define my schedules and limits, define my own way to work, and leave enough time for my family. I feel like I’m more productive, with better control of my time, and applying a developer point of view to raising my kid, where I accomplish big things by dividing it into smaller tasks, finishing each, and going from there, has helped me a lot.
Also, I’m used to staying up very late at night, so being a developer has also helped me a lot with that. Working in software, then, is very freeing and flexible, and I’m glad I could do it even before I was a mom. I don’t have to go to the office all the time, I can get along anywhere and the pay is not bad at all, so my quality of life is something I’m really happy about.
Agile Methodology, Outsourced Engineering Team
There are multiple methodologies that can be applied during software development, and one of the most popular is the concept of Agile software development. In an Agile environment, applications can be created through the implementation of individualized steps, with each one working toward a common goal. And while Agile methodologies (Scrum and Kanban, just to mention a few) have many benefits for developers, they are also advantageous for clients as well. Here are several ways that Agile development helps clients:
Client Engagement
Perhaps the foremost benefit of using Agile software development methodologies is the ability to keep the customer involved in every facet of the project. Commonly, Agile development progresses in stages known as Sprints, and it is after the completion of each Sprint where both developers and clients can make assessments and implement changes. This helps to promote a fluid exchange of information leading to an increase in project transparency. In addition, the fact that each Sprint represents a small piece of the development cycle means that clients can be frequently updated on the progress of the application.
Adaptability
It is not uncommon for a client’s needs to change during the development process, and with an Agile environment, these changes are relatively simple. While there is usually a formal plan as to how the finalized application will function, by building it in individualized steps, clients are able to refine specific functionalities while the software is still being created. In this way, these updates can be put to use during the next Sprint, after which the results can be retested to ensure client satisfaction.
Predictable Costs
Software development can be costly, and in many cases, these costs can fluctuate significantly as programming obstacles are encountered. However, through the use of Agile methodologies, developers have the ability to more accurately predict the costs that will be incurred throughout the process. This predictability comes from the fixed duration of the Sprints that separate each development phase. By knowing exactly how long a phase will take to complete and the amount of work that will be required, developers and clients will be aware of the costs before the next Sprint begins.
Goal-Oriented
The Agile development process allows clients to set their own goals for the project and this can help the development team better understand the specific needs of the client. Through this added level of understanding, programmers and developers will be able to make recommendations to the client which could have a positive effect on the final application.
In Summary: Agile Development is…
When it comes to meeting the needs of the customer, Agile software development offers many advantages to the more standardized ways of building applications. Through Agile development, programmers and clients can easily engage and collaborate throughout each phase of the project, and this level of transparency helps to ensure that all team members are working toward a single goal. In addition, by breaking the development process into stages there is a greater ability to predict the costs that will be involved in the creation of the application. Furthermore, Agile phases, known as Sprints, allow for coders to make adaptations even as the software is being developed. Remember to keep these points in mind when looking for hiring a software development company.
Looking for a partner to build an app?
Agile Methodology, Customer Experience, Project Management, Successful Outsourcing
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.
From the Agile Manifesto: «…we have come to value:
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.
Agile Methodology, Outsourced Engineering Team, Successful Outsourcing
Are you having a difficult time upgrading your services and software products? Do you feel like you are wasting time and resources on starting up your game plan?
A lot has changed in the tech world in the past few years. More and more, companies are realizing the importance of having a strong software development team in order to remain competitive. If you’re still on the fence about whether or not you need a software development company, here are seven reasons that might make you change your mind.
1. Save Time and Cost – You need to update your existing applications but don’t have the time or resources to do it yourself.
The software development lifecycle can be tedious and time-consuming. You have to plan, implement, test, and document your project before moving on to deployment or maintenance of the finished product – all in addition to an ever-changing industry environment where anything could happen at any given moment! But there’s no need for that anymore thanks to modern technology; nowadays we emit a minimum viable product (MVP) which saves you money by launching products faster than ever before possible while validating customer feedback early so they focus their efforts on what really matters: features people want rather than wasting countless hours perfecting things not needed yet (or perhaps even never)!
2. Integrated Agile Method
The July 2017survey of Forbes showed that 92% of the 500 senior executives interviewed believe organizational agility is critical for success. This goes hand in hand with statistics showing how 85% of software developers are using Agile methods at an increased rate – more than ever before!
Rapid development and deployment at the most critical time are what Agile provides. The goal of this approach, as you may know by now, is to benefit production software engineering teams looking to move quickly while still meeting expectations, and developing products that work well in the current environment – it’s all about getting things done!
Software developers who use true Agile ensure that you’re always in the know about your product’s progress, and can quickly adapt to changing demands.
3. In-house Experience: don’t have the in-house expertise to develop certain types of software.
The experience of developing your product is important. The lack in some cases can lead to problems for the company, especially if they are a startup with no previous projects under its belt and need help from an experienced team who has already been through this process before so that investment costs don’t pile up too quickly while also ensuring good teamwork and an MVP that hits the market as soon as you need it.
Fortunately, seasoned IT professionals of software developers can serve as an in-house team and work on your products. Their presence and expertise can significantly aid in your project’s success.
4. Software development projects can often be complex and time-consuming
Software development projects can often be complex. This is due to the many factors that need to be taken into accounts, such as the functionality of the software, the user interface, and the overall design.
Time is another important factor to consider when developing software, as we said before. It is important to ensure that the project is completed within the allocated time frame, as this can often be a determining factor in the success of the project.
There are many different aspects to consider when developing software, and it is important to take all of these into account in order to create a successful project.
Software development companies are able to provide you with a team of qualified professionals. Stack Overflow’s 2018 survey projected that three-quarters of more than 85,710 professional developer respondents have bachelor’s degrees in computer science and engineering – which is an impressive statistic!
By outsourcing your software development needs to a pool of educated IT and technology professionals, you will have more flexibility with your time and resources.
5. Strategic Focus: You want to focus on your core competencies and leave software development to the experts.
Hiring the right software development company is crucial to creating a successful product. Anne Latham, founder, and president at Uncommon Clarity says that hiring wisely will provide focus by limiting what direction an organization can take in their work, so when it comes down to deciding how to move forward with developing a product, choosing correctly is key.
By aligning your product with the expertise of developers, you can focus on what’s most important. Developers know their field and will work to make sure there aren’t any complications or issues when it comes time for launch; so with a clear and focused strategy, your product launch can be successful.
6. Advanced Technological Resources: working with an external developer gives you access to new ideas and perspectives.
As the world of technology continues to evolve, it’s important for software development companies not only to have a strong understanding of what their clients need but also to be able to work with them on an ongoing basis so that innovation can happen regularly.
By outsourcing software development services, you can have the assurance of getting fresh perspectives from innovative experts. As a result, your product’s success is secured.
7. Risk management
Many businesses view risk management as an unnecessary expense that cuts into profits. However, the truth is that risk management is essential to protecting your business from catastrophic losses. By taking proactive measures to identify and mitigate potential risks, you can save your business money in the long run.
One way to reduce risks is to invest in app maintenance services. By keeping your app up-to-date and free of errors, you can minimize the chances of it crashing or malfunctioning. This can help to prevent customer dissatisfaction and lost revenue.
Another way to manage risks is to be mindful of potential threats. This includes things like cyber-attacks, natural disasters, and even employee theft. By being aware of these risks, you can take steps to mitigate them. For example, you might invest in cyber security measures or insurance policies.
Ultimately, taking proactive measures to reduce and manage risks can save your business a lot of money in the long run. So don’t view risk management as an unnecessary expense – view it as an investment in the future of your business.
Benefits of Working with a Nearshore Software Development Company
Nearshore software development companies have become a popular option for businesses looking to stay ahead of the curve. By outsourcing their development needs to a nearshore company, businesses can tap into a pool of talented developers at a fraction of the cost of hiring in-house. In addition, nearshore companies are often more flexible and responsive than their onshore counterparts, making them ideal partners for businesses that need to move quickly. So if you’re still on the fence, send us a message and we’ll be happy to discuss how our team can help yours stay competitive in today’s tech world.
Agile Methodology, Product Development
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!
Agile Methodology, Customer Experience, Outsourced Engineering Team, Product Development, Project Management, Successful Outsourcing
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.
