Agile is tightly connected to the software development area, and is usually mentioned in that exact context. It was created to increase development efficiency. But today it is so much more.
Agile in general is an iterative approach based on the power of dividing and interacting. While it is an oft-suggestedstrategy to “go big” — build something from scratch to a huge launch (and cry if the launch wasn’t a success), Agile is the idea of small steps synchronized in every part of the project.
In Agile process everybody can find and fix small mistakes before they build into a monstrous problem. They’ll feel connected to all parts of the project, instead of like an alien in their own spaceship.
Requirements, plans, and results are evaluated continuously so teams have an opportunity to respond to change quickly.
That’s why Agile is still so popular. It also has an absolutely transparent ideology, and even a Manifesto!
Agile Manifesto teaches us the right things to do, putting it into core values and guiding principles.
It means the human element is always more significant than tech tools, no matter how sophisticated those are. Relying too heavily on processes and tools could cause an inability to adapt.
It means that one should never forget what is really important. And this is not perfectly filled documentation; this is the result. Everybody should do exactly what they need to get the job done, without bureaucracy overload.
Customers are a company's most powerful asset, its stability, its main power. That’s why you should involve them in the process as much as you can to ensure that the end product meets their needs more effectively.
Having a good plan is gold. But every project is changing through time, so it could lose the connection to the initial plan. This is an absolute deal breaker for traditional project and product management, but is 100% okay for an Agile team.
Here are basic Agile approaches that should guide you through every part of the work process.
It is fair to say that these principles should become a North Star for any team adopting an Agile methodology.
We started with “all these years”, but haven’t mentioned till now how old Agile really is.
The answer is: a bit older than 20 years. In early 2001 in Snowbird, Utah, 17 people met to discuss the future of software development. They all were frustrated with the current state of affairs: companies were so focused on excessively planning and documenting all the development cycles that the sight of what really mattered was completely lost. That needed to change. And since many of Snowbird 17 already had ideas about how to usher in software development new era; that was the moment Agile Manifesto was born. It was just 68 words — a good start for the documents mess battle, ready to change software development forever.
Since then, two decades have passed, and Agile principles have been embraced by countless individuals, teams, and companies. Of course, all of them have adapted the statements and core values according to specificity.
In general, Agile helps respond to changes in the marketplace, get feedback from customers quickly, and put it to work with no plan breaking and struggle. Agile lets focus on people — on their needs, desires, talents and strengths, and due to that helps the product development process become more natural, more inspiring, and, after all, more efficient.
But actually every part here has its own benefits from embracing Agile values.
So, Agile methods fit anywhere. But…
While Agile Methodology serves huge international companies leading us to the future, why not change it? Does it need to be updated and improved?
Actually, no. Agile Manifesto is not just a document or some product management guide — it is an ideology, a statement, a firm “no” to bureaucracy mess and time wasting. So this is, basically, untouchable.
And those who want to embrace it might be able to reinterpret it, adapt it to their own development cycles. But never change.
Nobody will judge you if you hire full-time developers through an official contract. The team will be under your full control and you will be able to change priorities and move employees from one task to another.
But… this is expensive. First of all, you must consider the employer obligations - everything from taxes to benefits to job guarantees for your workers. To make the economics work, you need to create constant task flow so employees are not idle. CFO’s are not in love with adding fixed costs into the business, especially in this economy. Also, the hiring process can be complicated and expensive. It’s almost impossible to build an engineering team around an office these days, and remote hiring opens up a new set of challenges. You can spend months and up to 5000$ per hire for just one good developer. Even more — if you are looking for a developer with special skills or huge experience.
If you choose to hire employees, saving money could be tricky. Today you can’t “hire developers from a small town and pay them half as much". Thanks to the global trend towards remote work, large tech companies are hiring technical talent all over the world, making it even harder to compete.
If you are hiring on staff, you will need an IT talent acquisition team, manage relationships with multiple recruitment agencies, and will face the challenge of how to recruit in the modern remote work environment. HR (and it will be one more staff unit) or go with agencies, which are not always safe to rely on.
If you are running this from the tech function, you can create a test task and interview your candidates yourself. Even so, you will need to distribute your offer across the many remote global job boards online, analyze CV’s, help new employees with adaptation etc.
Here is how long it currently takes to hire tech experts in the US:
Imagine you could find a ready-to-go team and trust it with every part of your project. Somebody you know well, who wouldn’t leave you with raw product and code access.
The challenge of this model is it lacks flexibility and customer-centricity. Outsource studios usually have a specialism they are great at, but struggle with work outside of the field of expertise.
Of course, there are always big companies with a bigger range of specialty options, but then you lose the relationship and their services are priced at a premium.
Outsource studios also have to build in a strong margin to de-risk any project at a fixed price, as well as a nailed down SOW. That’s why they are famous for being subject to Change Orders almost from Day 1 of a project and you lose control of the budget.
This is often known as staff augmentation. You engage a company to supply workers with specialist skills for your project, without the commitment of a permanent hire, and you keep the ability to scale up and down as required. With people who have been pre-vetted through technical tests, peer to peer interviews and HR interviews, you can access the best matching people to fit your requirements available on demand.
Skipp is exactly this kind of business; a global network of technical specialists. We come from technology companies, and experienced these hiring challenges, so we set out to solve the hiring problem. We have extensive networks across the world, understand how to sort for the different levels of talent and we know how to find the people to best fit your requirements.
After briefing one of our Talent Acquisition Specialists, they will provide you with a short list of great candidates for final interview so you can start working together within one week. In addition, we will assign a Customer Success Manager to meet you regularly, meet the developer weekly, and monitor their activity through our platform dashboard. We stay on top of everything from task progression in JIRA, to volume and quantity of code shipped, to your customer NPS score to ensure developer productivity. The CSM is your assistant manager to ensure all Skipp talents are always on track to help keep your project on time.
Some projects are more suitable for in-house production. Consider this option, if:
The task is good for outsourcing if it is clear-cut and has a defined deadline. Go with this option, if:
Outsourcing begins with a team picking. How to choose the right one?
First, even if you think you’ve already met “the One”, request offers from a couple more teams. You will get more market data and make an informed decision.
Second, pay attention to offer itself. You should be careful if:
You can be sure your candidate is good if:
Third, check out the portfolio. Similar cases will show the expert level. And if the software development team launched an app with poor navigation and interface a few months ago, there are no reasons to believe it could do better today.
Fourth, meet with your potential team. Specify their methods, figure out their opinion on the product. Too common answers are a bad sign. You need not the cheapest option, but the team who can do the best for your project. It is better to spend time searching than redoing what was already done.
❌ The way to fail: choosing by price.
✅ The way to succeed: choosing by experience and skills.
Development specification usually consists of three parts: concept, design, and functional description. There are one main rule for every part: the more details the better result.
you need a website or application. It is easy to estimate expenses and final result, which is necessary for IT outsourcing.
❌ The way to fail: general description of your idea.
✅ The way to succeed: detailed description and answers to all the team questions.
Sometimes an outsourcing vendor promises you two backenders and two frontenders for your project, but after all it looks like all the job was done by one employee, and not even a full-time one. This can be easily explained by the business model of outsourcing companies — if there are too many projects in process, developers are torn in between.
Meet developers who will work on your task and do your best to keep in contact with them. The more you meet, discuss and plan, the better result you will get.
❌ The way to fail: giving the specification and waiting silently till the product will be ready.
✅ The way to succeed: staying in touch; checking out the work in progress; answering questions.
Project includes design, front and back, testing, and analytics. But outsourcers usually have a narrow tech specialty, so one person won’t be able to manage all the tasks properly. So, he will give it to a more experienced developer, or, in a worst scenario, do it poorly with his own skills.
The solution is to work with meta teams. In this case, you select well-experienced experts for every specific part of the task.
It is important that all meta team members were able to communicate, make decisions together, be on the same page. The tighter their contact, the greater the result will be. You can even use an extra expert to organise the team communication — a product manager who understands the task well and can answer any questions.
It’s nice to have your own development team. You can create features, brainstorm, and discuss your future. You can give your team equity in the company to motivate them, but this practice is pricey.
If you are good at tech and you’re able to give a task and then approve the final code — then sure, hire your future developer ASAP. But if you need to focus on business and management, better be sure you have somebody to lead a team, like a tech director or project manager. You can rely on him for the tech part, and be able to focus on the product.
Define the volume and specificity of the project-supporting work. If there are many new functions to develop ahead, you’ll probably need a few different full-time developers. If it’s enough to just keep servers alive, then all you need is a part-time admin.
Describe your expectations about required technologies and the developers’ experience level, write about your product, and explain possible tasks. Now, you should have something you can upload to career web-sites.
Here is an example of how to describe the role:
It doesn't have to be long. You can summarize everything you need in one page.
Here is how we do it: the page for designer job description has the name, the definition, tech list, and terms. Below that, there is more info about us.
Take a look at the applications and exclude developers who don't meet your needs in specialty or experience. Take the rest to the interview stage. Here are things you should check while interviewing.
Soft skills. Is a developer interested in business goals, or does he just wanna code? Is he independent, or does he need to be guided to complete certain tasks? Does he match your project personally?
There are no right or wrong answers. One project needs an independent contributor, while the other does not. Look at every skill through your goals and needs.
Tech skills. Make sure you won’t need to redo everything your new developer does, and that he is really able to do all the things he said he could. The easiest way to prove this is with a test task.
Assess your possible candidate in the field: connect him to the team and watch how he manages real tasks. It depends on the project, but you can observe just for a day or for a two-week sprint.
At the beginning of the probationary period, organize a kick-off meeting. Introduce the developer to the team. Tell him about the product and its future. Give him access to your repositorium, messenger, and CRM. Introduce him to work processes; explain your prioritization and evaluation policy.
Like any other employee, a new developer will need time to adapt — to understand the code and realize your expectations. Don’t think that he’ll be ready to develop new features immediately, but pay attention to his work methods and values.
Assembling the team is just the first step. If your product is not a one-day issue, but a long-term business, the work needs to be systematized. Here are things that will help you do so.
Regular management system. You can try working in sprints. At the beginning of each sprint, you will set and dissect tasks. You should have meetings everyday, and at the end of them, you should look at the project retrospectively and discuss the work you’ve just done, taking feedback and analyzing problems.
This will help you know that the team is on the same page and moving in the right direction, and that all the developers understand business priorities.
Tech process organization. The tech lead of the team has to ensure that development is always progressing. This requires test processes and auto-updating systems.
Also, the code should be understandable to any new team members. This requires code standardization.
Different teams’ synchronization. Over time, the project will grow, and experts will start working independently. Developers, designers, and analysts will manage their tasks in their detached teams. But their efforts will still need to meet in key points. For example, designers are always 1–2 sprints ahead of developers to make sure they already have mock-ups by the time they get the task.
And, of course, you don’t have to make everything with just your own employees. You can use the magic of outsourcing any time you want.
Skipp helps both with new projects and existing ones. Tell us more about yours, and we will assemble the perfect team for you.
