11 most popular myths about developers

To this day, there are still lots of misconceptions about the development process and the actors involved in it. Not anymore a developer is a person who hacks into computer systems, ATMs and performs other actions that are inconsistent with the law. Others are sure that the programmer will fix their computer and reinstall Windows, will set up TV channels, or will write overnight a new Facebook and will show how to generate document content in Word or even will repair a microwave either some other technique. This is funny, but still, it’s the reality for some people.

Moreover, some stereotypes have taken root so much that impact the general perception of a developer’s function.

To avoid confusion in this regard and to make clear every trifle of the most popular stereotypes. We have prepared for you a rating of the most important myths that need to be dispelled first. Let’s get down to destroy them.

MYTH 1. Development  is not for women

Since 2015, such companies as Facebook and Google have been developing towards “leveling” the number of female workers in relation to men. Plus, from the reports provided by Statista, we notice that with each passing year, the number of employed women as developers increases, while the percentage of male employees decreases, in order to balance the ratio. Moreover, such type of action is typical not only related to IT.

Reality. Analysis of statistics for 2020-2021 says that there are more and more women in IT every year.

MYTH 2. Math skills determine development skills

According to the Stack Overflow Developer Survey 2021, more than 50% of responding developers wrote their first line of code between the ages of 11 to 17, and at that age, no one is learning advanced math yet. This means that anyone who studied or studies in an ordinary average school can make a start in programming.

Reality. Good knowledge in the field of mathematics is still necessary, but for those who want to realize themselves in such areas as: scientific field, encryption, Machine Learning, Data Science, development of Artificial Intelligence, and everything related to big data…a lot of math is needed.

MYTH 3. You can become a highly paid IT professional if you have university studies

In addition to Stack Overflow Developer Survey 2021, almost 60% of respondents learned how to code from online courses, forums, and other online resources. From 82,963 of surveyed developers from the USA and Europe:

  • only 25% received university degrees;
  • 10% have degrees in liberal arts and other sciences;
  • 16% consider higher education a waste of time.

Reality. To become a qualified IT developer, it’s enough to successfully complete advanced courses and get some certifications that will prove your skills, to become an exceptional engineer still University is the only way to go through.

MYTH 4. Development has age restrictions

At DAS Solutions, we have senior developers who started their career at 16 years, programming websites and others.

Considering Statista survey findings, most of the responding game developers were between 35-39 and 40-49 years old, with 22% each. Moreover, based on Stack Overflow Developer Survey 2021, 28.48% of developers are over 35 years old.

Reality. Psychologists say that children 8-9 years old are able to understand and learn the basics of programming languages, as well as successfully create their own programs, but they are not yet the engineers that are wanted.

MYTH 5. Machines and applications will rule our FUTURE

People have learned to create artificial food, but farmers have not disappeared anywhere. People have created drones and UAVs, but no one has stopped hiring soldiers in the Armed Forces. So many programs have been written, but there is still a lack of teachers in schools. So it is in IT. The work of a programmer will simply evolve, as, for example, the work of a plowman who followed a horse with a plow and now sits in the cab of a computer-controlled combine.

Reality. As far as AI is concerned, any machine can only generate solutions from a template. It is not capable to create something fundamentally new. Only the human brain can do this.

MYTH 6.  Developers are repairmen of any equipment

A mobile app developer specializes in creating applications for mobile devices. He knows programming languages, technologies, frameworks and has great baggage of narrow skills that allow him to do his job efficiently and without wasting time. However, why should this specialist be able to fix TVs, create websites or install Windows if this is a completely different industry in IT?

Everyone is an expert in their field and we should not forget this.

Reality. Developers are not good at any technical related issue.

MYTH 7. X Programming Language is better than another

None programming language is better than another, just like English is no better than Chinese. Each developer may have his/her preferable language, but in the IT industry does not exist the best programming language. Therefore, arguments about the superiority of one language over another are simply irrelevant, because each of them is focused on specific tasks that have nothing to do with personal biases.

The benefit of the language is only within the framework of solving certain problems. One language is more suitable for mathematical calculations, another is for creating corporate software, the third is good for web development. Learning several languages at once is not an option at all. Programming is an art. If you speak five languages but cannot write a good poem, you are not a poet.

Reality. Each programming language may give the best result for a specific issue. The best or ideal programming language doesn’t exist.

MYTH 8. Developers need to know English perfectly

To start a career in IT, it is enough to know English at A1 level (basic). Of course, along the way, you will need to improve your English level because the size of the salary will depend on this topic and the level of growth as a specialist. Plus, companies have no interest in collaboration with people who don’t want to develop continuously their skills and knowledges.

Reality. The level of English proficiency will only play a role in the salary raise for developers at the Middle level and above.

MYTH 9. Experienced developers work around the clock

Despite the reluctance to succumb to stereotypical thinking, instantly arises in your imagination the image of the guy who types like in the film Bruce Almighty. It’s funny, but the reality is totally different.

Besides that, many people know that lack of sleep does not increase productivity, on the contrary, slows down the working process. Few people are happy with this state of affairs, because many developers have family, friends, and personal affairs, to which they are more likely to devote their free time.

Reality. Developers ONLY SOMETIMES need to work overtime, and get paid in return with a higher hourly rate.

MYTH 10. The more people check the code, the fewer bugs it contains

“Given enough eyeballs, all bugs are shallow”, said Eric S. Raymond. This implies an advantage to open source because any developer can review it and fix bugs. In reality, this is not quite the case, because open-source software has more users who are unable to fix bugs in the code than people who are willing to contribute. Simply said, seven nannies have a child without an eye. The best solution in this situation is to employ a problem-focused team as Quality Assurance engineers.

Reality. Each specialist has his own point of view and 2 of 5 developers have something to add or edit in the code.

MYTH 11. Developers are rich people

Against the background of line workers and employees with flowing short tasks, senior developers really look like Arab sheiks. It’s true that for a programmer it is easier to find a job with a higher salary than the national average.

The developers’ salary varies greatly from specializations, skills, education, hard work, a little bit of luck 😊, and other factors like the ability to sell oneself to an employer or stress resistance. To reach professional heights you need to work hard, or come up with a really cool product.

A large salary is offered to already experienced developers. Novice developers will have to settle for small amounts, gradually building up a portfolio. Nobody becomes a billionaire overnight, and most programmers never even become millionaires.

Reality. Years of practice, desire, and hard work are the ingredients of success.

Surrounded by stereotypes, newcomers find it difficult to take the first step towards high technology. We hope that by getting rid of the misconception about developers, it will be easier for you to choose the right development direction.

It will be interesting to discover the funny stereotypes that you have come across during your practice, and we’re sure there were quite a few of them. Leave your options in the comments.

12 benefits to hire a PM to your Outsourcing team

Sometimes happens that projects do not realize their full potential or even fail, that’s why having a skilled, well-rounded, and dedicated project manager on the team, even if it is an outsourced crew, the likelihood the project will be successful and profitable regardless of your and business vision and direction. Yeah, maybe you see this as a risky leap, but it’s a great option to get an experienced person who will positively influence your business lower costs, innovate, and grow.

Our clients usually appreciate the decision to hire a dedicated Project Manager. They understand that a project manager is a person who will organize and will streamline the workflow, focusing on dozens of issues simultaneously. In such a way, customers overcome the problems, keeping the timeline, productivity, and motivation of the team and other key processes.

42% of companies don’t understand the need or importance of project management. (Project Management Institute)

The PM not just leads the team, navigating any hiccups, awkward situations like failure to meet deadlines, overstated and unjustified costs, provide clear specifications of tasks and mitigate risks. This person is always in touch with clients regardless of the time zone difference, organizing regular calls, demonstrations of the project, and gettering feedback constantly. He is responsible for the project’s success, meeting deadlines, and balancing the complex components of a project, and still, it’s only the tip of the iceberg.

Companies start looking for project managers when they’re already hurting for one between 10 and 20 employees. (Divvy)

Many businesses should already have a project manager for a team that exceeds 7 people. But the majority of outsourcing projects that are do not have a person who will take the lead, suffer from inefficiency, and work more on project development than it’s necessary.

If you want to have a management to match the business vision but not a storm of inefficiency, lack of accountability, extended timelines, and blown budgets, we kindly suggest to hire a confident and dedicated PM with wide and complex competencies as are the following:

Soft skills:Hard skills:
clearly communication
critical thinking
power to motivate others
IT expertise
team management/integrity
cost management
risk management
project management tools
empowering others
math and analysis
conflict management

The primary benefits of hiring a project manager for the outsourcing team:

  • reducing development costs and time allocated to this process;
  • regular communication with the client and keeps a client in the loop;
  • steers the project in the right direction.


But if you still doubt that you’re an outsourced project is an optional addition, carefully read all the clearly stated reasons below for hiring such an important expert. Learn about key tasks, responsibilities and see the importance of hiring a PM for your outsourcing team.

  1. Industry expertise.
    • The project manager clearly defines the vision, the direction of the project, based on a high-level view of business goals. As a result, he creates the action plan to be followed in order to deliver a successful and qualitative project.
  2. Diversity.
    • A temporarily hired project manager will come up with more new ideas, due to his extensive experience delivering projects of various sizes to customers in various industries and countries, while in-house PM works only for a particular project. When you work on different projects, your ideas progress. The same thing would have happened to your employees if you offered them to an outside company. They will constantly exchange experience, ideas, and knowledge. Plus, the experience of an outsourcing project manager does not permit to dull but important administrative tasks to be overlooked and focus being thinned. Perfect!
  3. Openness.
    • The subcontracting project manager is more transparent, more open, and focuses on the outcome because he doesn’t rely exclusively upon you for their income. Which rarely happens with the in-house project managers.
  4. Persistence.
    • The project manager has a commercial interest to deliver the project qualitatively and to get a good review, because the number of customers will depend on the work done, influencing the profit.
  5. Dedication.
    • As a lot of changes may arise on the go (adjustments, new ideas’ tests, etc.). Having a PM outside your company, you’re fully committed to the completion of the project throughout every stage of the project life cycle; from planning, right through to the final execution and delivery. He monitors closely every step of development. In case you have hired yourself, there may be risks such as loss of work efficiency, loss of motivation, and many others that will put the project at risk.
    • In case of subcontracting a project manager, you’re assured that the employee has the experience and that he will deliver the project successfully in the established terms and up to standard. Otherwise, the PM will pay penalties and will have to compromise his paycheck.
  6. Flexible workforce.
    • Working with worldwide customers in a variety of industries, the outsourced project manager is always flexible and adapts to any conditions. Even if is a significant difference of a client’ and our PM’s time zone, our expert adjust to the client’s preferred way and time of communication.
    • Moreover, the zone difference in our case this is a benefit. In this way, PM organizes his work in the most efficient way in order to have a productive conversation, and with the responsible team to structure all the necessities quickly and operatively at the same time.
  7. Cost-effectiveness.
    • You pay for exactly the length of time you employ thus you save a project’s budget in the long run. A qualified PM with vast experience will cost you enormously, having him as an employee in your company. But only taking strict advantage of the hours of an external project manager will save you money. In addition, for the in-house project manager you need to allocate money for some additional costs that you don’t have to pay for contractors:
      • Employer-provided benefits;
      • Insurance;
      • Social Security and Medicare taxes;
      • Office space;
      • Equipment;
      • Education and development (trainings, courses);
      • Team buildings.
    • Thereby, you save a substantial amount of money that can be used for your project development if necessary.
  8. Quicker time-to-value.
    • Solving small problems takes a lot of time and when there is a person who is responsible for the effectiveness of the team and the optimization of processes, both the client and the developers can focus on the key things, business/project development.
  9. Quality assurance.
    • Before launching the project, the project manager tests the product and makes sure that the app corresponds to the real scenarios of the user’s behavior. This is just one and the most important stage in which the client should not get involved and waste time. He will always remove obstacles or solve sudden issues, because he has problem-solving skills.
  10. Budget overruns.
    • PM is the person who ensures that engineers meet the deadlines. Due to regular reviews of the project budget, he makes sure that no specialist is misusing/overuse project resources in order to ultimately avoid idle expenses.
  11. Risk management and analysis.
    • Due to the comprehensive experience of the project manager, he constantly analyzes and isolates the risks to minimize the possibility of the breakdown. But even if the worst scenario happened, he knows how to find the solution even if it is the most complicated situation.
  12. Skillful communication.
    • When the team consists of specialists with different responsibilities, communication is key. As a bridge between developers and client, the project manager streamlines the process by receiving feedback that clearly defines the project’s vision. He knows better how to filter information and transform an hour-long conversation into clearly defined tasks.

Generally, no matter the size of your business, projects, or required skills. Therefore, you need an expert with a highly specialized area of knowledge and skill who will deliver successfully your final product, on time and without a prohibitive budget.

DAS Solutions is a company that has professionals with excellent entrepreneurial skills. Our Project Managers are certified and continuously improve their skills through trainings and courses. If you decided to implement new software, roll out a new product line, or undergo a new business initiative, contact us today by email, [email protected] . Let’s staff an exact project your business needs to thrive.

Tell us about your project

    By using this form you agree with the storage and handling of your data by this website.
    Send me NDA

    Classification of developers by martial arts ranks [Junior, Middle, Senior]

    In many martial arts, the color of the belt corresponds to the skill level. Usually, the color changes from white to black, where the experience level corresponds to the darkness of the belt. A beginner wears a white belt because he has no experience. White means “new and clean”. As you train, the belt darkens, showing progress. The color represents the dirt accumulated through hard work and sweat. A martial artist with many years of experience eventually reaches the black belt, which means a high level of knowledge and skill. Traditionally, the belts were only black or white. But in recent decades, more colors have emerged. The same in our company our developers are going through a challenging trip to gain the “black belt”.

    How do junior, middle, and senior developers differ? How does the transition between these levels take place? For these and many other questions, our experts provided detailed answers.

    Basic Characteristics

    For us, “Junior”, “Middle” and “Senior” levels mean not only technical skills (hard skills), but also the soft skills of being able to communicate with people, working in a team, and the willingness to take responsibility for own decisions.

    The higher the developer is positioned; the higher requirements for soft skills are. Technical skills are usually the easiest for us and developers to develop in comparison to communication and teamwork skills.

    Experience is a rather conditional characteristic. Some developers can be classified as newcomers even after 4 years of work in the company, but there are real “diamonds” who, just in a few months after entering the market, already show independence and do not continuously support their senior colleagues.

    An important element in evaluating the developers’ experience depends on their background performance and future potential. Sometimes an engineer who works for a small company that is engaged in streaming development of similar projects can hold the position of a senior developer in that company, but at the same time, if he jumps into an ocean of a large high-tech firm, his level can be assessed lower or higher. Thus, we get a person who is coming with a background from one company, and he still might need to go a long way with us increasing her/his professional level.

    World statistics say that a junior developer is defined as a beginner with real work experience of up to 1-1.5 years, a middle programmer as a still learning specialist with 1-3 years of experience, and a senior as a professional who has worked in the company for a good 5-6 years. But remember that this gradation is an approximation. Therefore, the level of the developer should be determined depending on the professional skills, knowledge, and characteristics as following:

    1. Computational technologies (Computer Science): data structures, algorithms, system programming;

    2. Software Engineering: VCS, IDE, CASE, CI / CD, middleware, processes, metrics;

    3. Programming: programming languages, libraries, frameworks, code organization, organization of own work;

    4. Communication skills;

    5. Cognitive skills;

    6. Knowledge of the subject area;

    7. Experience.

    ***The first two disciplines are often overlooked, but they play a large role in building an effective development process and have a significant impact on the quality of applications developed. Sometimes we meet developers who apply for Senior developer, while do not know what a stack or a graph is. The question arises if a person does not know what a stack is, then how affair example, a debugger?

    If a person does not know the development process, then how can he effectively part know addition to other obvious statistics and knowledge, I would like to draw attention to cognitive skills: the profession of a developer requires constant training not only to grow but also to stay at your level, keeping up with the times. And here memory, attention, the ability to focus, and the speed of information processing play an important role.

    Definition and Differentiation

    The specific content of the levels depends on the technology stack that is used in the company.

    Junior developer: white belt

    is usually a person with little or no development experience. In our cases, s/he’s a yesterday’s student or even a student who still studying at university with a random set of initial skills that we thought was sufficient to give the person a chance. S/he is ready to listen to criticism and learn a lot.

    You need to understand that for tasks that the signor will solve in ten minutes, Jun may need three approaches an hour each, and in the process the code will have to be completely rewritten, spending a lot of additional energy.

    Middle developer: blue belt

    is yesterday’s Junior, who has successfully mastered the entire technology stack used by the team. He confidently, independently and on time solves small problems/bugs. Provides useful remarks when reviewing someone else’s code. In addition, he knows several programming languages/frameworks, and for what his/her knowledge is systematized. Additionally, the middle developer can independently evaluate his part of the project and start developing it without additional assistance.

    Senior developer: black belt

     is mentor, evangelist. Due to his/her deep understanding of the system architecture, s/he can be entrusted with a new product or direction. This expert already runs a team (team lead) or is a very cool developer (tech lead). S/he understands for whom this or that product is being made. Who should do what and how?

    Moreover, the Senior developer sees the picture of development as a whole, presents the complete architecture of the project, and understands what should ultimately come out in the release part.

    There is also division within these concepts. Besides Junior, there is entry-level Junior, med-level Junior, and plus-level Junior. Likewise with Middle and Senior. We focus on these levels when looking for new programmers and working with those who are already on the team. Looking at the requirements, and they are fixed and open, employees understand in which direction to “dig” to grow. This is something like OKR (Objectives and Key Results).

    If we go into more detail, when we have something to add to the above mentions:

    What should a Junior be able to do?

    • Possess the basics and programming tools;
    • Speak basic English;
    • Be able to write basic program code;
    • Possess the skills of reading code;
    • Be able to listen and hear criticism, improve his/her mistakes;
    • Navigate the IDE interface and manage it using the taskbar;
    • Know how to work with the API.

    Skills required for a mid-level developer:

    • Knowledge of keyboard shortcuts for quick and efficient work with IDE;
    • Writing understandable code, confident knowledge of technology;
    • Database management and development: provision of stored procedures, triggers, user-defined data types (UDT), knowledge of object-relational mapping (ORM) technology;
    • Having a deep understanding of the functioning of more than 4 platforms;
    • Active collaboration with team members, guidance over junior developers;
    • Independence in work;
    • Search for non-standard solutions;
    • What are the responsibilities of a senior developer;
    • Pre-intermediate or intermediate English.

    What are the responsibilities of a senior developer?

    • Technically consistent with the business product program;
    • Have leadership qualities, be able to manage a team;
    • Fully understand the architecture of the application;
    • Constantly improve qualifications, learn new things;
    • Be able to calculate an accurate estimate;
    • Know how to independently implement a project from scratch;
    • Solve any problems that arise;
    • See the strategic path from an idea to its successful implementation and market launch;
    • Intermediate or fluent English.

    Higher-level moving

    Junior ➜ Middle

    This way, they will fall into many possible pitfalls and learn how to avoid them. They learn how to write simple code by thinking of the person who will be working on the program after them. Also, learn how to fix bugs and educate themself.

    At this phase, they learn how to debug, as this will help better understand what’s going on in the process. In addition, they are familiarized with best practices and learn about architecture, performance, security, and more. Close the knowledge gap required to move to the middle tier. For a junior developer, learning design patterns, architecture, test automation, performance, and security techniques, and more is a great way to close the knowledge gap.

    Middle ➜ Senior

    Moving from middle to senior level can be quite challenging, usual now the focus is on learning, not just on solving routine tasks. Some developers stay middle for their entire careers. Seniors know what can be discarded in the code, and what cannot be removed in any case. Previous experience and mistakes taught them all this. If a developer wants to be a senior, then he/she should be prepared to take on tasks that no one else can do. Also, to have to help less experienced developers, Seniors are their lifeline in difficult cases. It is not surprising that seniors thoroughly study the entire range of technologies of their company. This is more than just programming – it is an immersion in all aspects of creating a product.

    Seniors need to know more than just how to get the job done.

    What’s next?

    The Senior Developer position is precepted by us not as a career plateau, but as a springboard for further development, for example, in one of the following areas:

    • Technical expert;
    • Industrial expert;
    • Front man;
    • Team lead;
    • Architect.

    Serious fighters have been learning martial arts all their lives; serious software developers do the same. Any knowledge in this area is completely outdated after 3-5 years, and if there is no constant growth, they can “slide” from senior to the middle position again. Therefore, we recommend to all programmers to constantly educate themselves and keep their fingers on the pulse of technology development.

    We recommend reading new articles and research on the topic, testing new products and technologies. This is what always keeps you afloat and makes you competitive.

    We hope you find useful insights based on the differences between these three developers’ levels.

      By using this form you agree with the storage and handling of your data by this website.
      Send me NDA

      9 steps to make a “marriage in Heaven” with your IT customers

      Have you ever wondered how your customers comprehend your joint projects? It’s a useful exercise to experiment with both sides of vision since most issues appear because everyone sees things from their own point of view and fails to observe the situation from other angles. 

      This article is about some of our golden rules which offered us in years agility and open relations with our clients. Follow the white rabbit!

      • STEP #1 Do not miss the start check-up

      Confirm with your client the purpose, value, and objectives following the how, why, and what questions. Thus, you will have a firm answer that will ensure the 100% truthful basis of your project. Ask the client for a formal confirmation.

      • STEP #2 Hold a kickoff meeting and plan out key activities, milestones, and approval loops

      GO for a realistic, achievable, and detailed enough timeline for product development as a comprehensive road trip, to effectively monitor the project’s progress. Without clearly defined tasks, you will waste your resources, just like going on a trip on an unknown road and wasting fuel.

      The project implementation schedule should coincide as much as possible with the control schedule. That way, you will not lose time and effort. Use Gantt Charts for better project planning and tracking short-term and long-term tasks.

      If you control the project every two weeks in Agile Sprints style, then the development schedule should provide the ability to detail up to 2 weeks. The best way out is to “cut” the project into smaller iterations. As a golden rule, always update this plan.

      • STEP #3 ALWAYS work collaboratively

      Communication is the groundwork of any human relationship, regardless of its nature. Proper and efficient communication can ensure our success both professionally and personally. Therefore, by having regularly short stand-up meetings a few times weekly, your relation will not be like a blame game, but on the contrary, it will become more friendly, avoiding moments full of arrogance, disagreements, negativity, high tones, ingratitude, etc. Create an agenda of your meetings in advance for the next several connections.

      Working proactively, everyone will know what stage the project is at, and will have a clear picture of its tasks. Furthermore, there will be fewer technical errors related to the project and the probability of retaining the project will be much lower.

      • STEP #4 Be friendly but don’t do not cross the personal line

      Add a little “air” to your relationship, but don’t go beyond the personal area. Simple things like congratulating on birthdays, having small talk during meetings/calls about life in general, sharing a joke or two, having a good laugh together, telling stories, and also listening to their stories and other stuff like this can help build bonds that can never be achieved only with working relationships.

      • STEP #5 Ask for weekly feedback

      Confirm with the client the weekly work. Request a full answer to all your questions, sending him a friendly form with easy check answers (yes/no, rate from 1 to 10, and other options). Most clients are lazy or do not have enough time to complete the long feedback surveys. Put yourself in their shoes.

      • STEP #6 Taken into account each detail

      From the very beginning, determine together with the client the milestones, budget, priorities in the smallest details, such as detailed budget by categories, and so on. Always, listen actively and understand what the client is talking about. It’s a key factor.

      • STEP #7 Keep your client informed

      Every time when you have changes, update data and make sure that your client is aware of them, providing access to them and communicating via email in the weekly status report (budget burn, timeline, blockers, requirements, risks, and questions).

      • STEP #8 Foresee potential risks beforehand

      Make sure in advance that there is a “backup” manager in all project negotiations, who could take the reins into his own hands in the event of an unforeseen situation like staff leaving. Use to be notified about tasks moving from one stage to another. Prepare with your team some outstanding alternate control measures, list all types of risks, and course of action plan “B”.

      • STEP #9 Prevent the change directions mid-course and cost overruns

      By providing tasks’ implemented time and cost for each one from the start, the client will have a clear decision and will understand the value of your resources. Invite the client to planning sessions and backlog refinement. Here s/he will understand the volume of work, that things happen interactively, will be aware of the time of implementation of the tasks, and the value of both human and financial resources. Do not be shy to explain that adding tasks to the scope is changing the estimated time of delivery.

      Considering the tips listed above, your projects will always be implemented successfully and with fewer problems along the way. You tend to have a fruitful relationship full of collaboration with your customers.

      Meet us and we’ll be glad to show you how the perfect project match is done.

      Tell us about your idea

        By using this form you agree with the storage and handling of your data by this website.
        Send me NDA

        One Sprint in DAS Solutions life

        It’s not a secret that having an Agile mindset is absolutely essential for Business Development.

        Nowadays, everything is changing very fast, we have a lot of challenges, and therefore, it’s all about how fast you can react and how fast you can adapt to changes.

        Changes are inevitable!

        It’s something that we have to welcome, because in this way, we will become less stressed and more powerful, we will see a situation from different angles. The problem is that during years, we were comfortable to work according to plan, without any deviations, because for a lot of people, to change something means that they need to perform some additional work, recalculate costs, they will have some additional communication channels, some additional risks and as a result, another deadline. It’s true. To work according to the plan – is a really great way to reach your objectives and strategic goals. However, it’s not so easy and you always will deal with changes, due to different factors, such as: Business need, Market change, etc.

        First of all, in order to manage a change, we really need to “Accept” the idea that changes are something you can’t control until it happens. This is the critical element that we have always to keep in mind. It’s a long process to capture this idea, however, it is something fundamental.

        From our perspective, we don’t think that sticking just to one approach or methodology is the best way to reach your goals. We really believe that Team need s to be flexible and adaptable to different situations. We prefer to mix methodologies for a better outcome. We want to give our team all knowledge and instruments that will make their work more comfortable and productive.

        So, as an IT company, mostly, we are using SCRUM, but in addition, we add some instruments and techniques from other frameworks, such as Waterfall, to get a better outcome. We are opened to experiments, and always are in the process of continuous improvements of our processes.

        Usually, our Sprint begins on Monday (it’s more comfortable for us) and the duration of the Sprint is 2 weeks or 10 business days. Before we are getting to start our Sprint, we need to perform some activities to make sure that everything that was planned – will be delivered.

        These events include:
        • Backlog Refinement or Grooming,
        • Sprint Planning,
        • Daily Scrum,
        • Retro meeting and Review.

        So, first of all, imagine that you have a list of hundreds of requirements. We all understand that these can’t be delivered in 2 weeks, therefore, we need to prioritize our Backlog to make sure that first of all, we will deliver the most important features from a business point of view. This type of meeting usually is performed with the Product Owner, who is responsible for Ordering Product Backlog items and, ensuring that the Product Backlog is transparent, visible and understood. It’s a very important part of our process, because the team, which consist of 7 people, must have a clear understanding of what needs to be done, its acceptance criteria, estimations and to know the amount of User Stories which will be included in the Sprint according to team capacity. Also, we are assessing additional risks that might or might not happen and track them daily. Risk Analysis is based on the Probability and Impact of an event/risk that might happen in the future, having a positive or negative result.

        A Grooming or Refinement meeting is a meeting where we prioritize all items in the Backlog from those which bring maximum value. To make it happens, we use different techniques for prioritization:

        1. MoSCoW Prioritization scheme — The MoSCoW prioritization scheme derives its name from the first letters of the phrases “Must have,” “Should have,” “Could have,” and “Won’t have”. This prioritization method is generally more effective than simple schemes. The labels are in decreasing order of priority with “Must have” User Stories being those without which the product will have no value and “Won’t have” User Stories being those that, although they would be nice to have, are not necessary to be included.
        2. Paired Comparison — In this technique, a list of all the User Stories in the Prioritized Product Backlog is prepared. Next, each User Story is taken individually and compared with the other User Stories in the list, one at a time. Each time two User Stories are compared, a decision is made regarding which of the two is more important. Through this process, a prioritized list of User Stories can be generated.
        3. 100-Point Method — It involves giving the customer 100 points they can use to vote for the User Stories that are most important. The objective is to give more weight to the User Stories that are of higher priority when compared to the other available User Stories. Each group member allocates points to the various User Stories, giving more points to those they feel are more important. On completion of the voting process, prioritization is determined by calculating the total points allocated to each User Story.
          Our favorite prioritization method is MoSCoW, due to its simplicity and efficiency. Regardless of what method you use during the prioritization phase, all of them offer a simple idea – “To choose items which are most important and valuable for the customer.

        After our Backlog is prioritized, and team understands what is important for the customer for the next Sprint, we have a Sprint Planning meeting. Usually, we are doing this meeting on Friday, because the new Sprint, with prioritized Backlog, estimated effort of User Stories and tasks begins on Monday. Therefore, during the Sprint Planning Meeting we discuss and estimate each User Story in terms of the effort required to complete it.

        Here we can use different techniques to estimate the effort for each User Story:

        1. Planning Poker
        2. Fist of Five
        3. T-Shirts Size
        4. Bucket System
        5. Points for Cost Estimation

        But mostly, we are using:

        1. Planning Poker
        2. Fist of Five
        3. T-Shirts Size

        Planning Poker, also called Estimation Poker, is an estimation technique which uses consensus to estimate relative sizes of User Stories or the effort required to create them.
        In Planning Poker, each team member is assigned a deck of cards. Each card is numbered in a sequence and the numbers represent the complexity of the problem, in terms of time or effort, as estimated by the team member. The Product Owner chooses a User Story from the Prioritized Product Backlog and presents it to the team. The Scrum Team members assess the User Story and try to understand it better before providing their estimate for developing it.

        Then, each member picks a card from the deck that represents their estimate for the User Story. If the majority of all team members select the same card then the estimate indicated by that card will be the estimate for that User Story. If there is no consensus, then the team members discuss reasons for selecting different cards or estimates. After this discussion, they pick cards again. This sequence continues until all the assumptions are understood, misunderstandings are resolved, and consensus or agreement is reached.

        Planning Poker advocates greater interaction and enhanced communication among the participants. It facilitates independent thinking by participants, thus avoiding the phenomenon of groupthink.
        Planning Poker is a really great technique for effort estimation, but how would you do it for people who work remotely?

        We have found an extension for Project Management software that we use for all our projects. It gives us a possibility to estimate the effort remotely, using the same cards with the Fibonacci sequence, but online.

        Mostly, we prefer this technique to Estimate all User Stories, because we believe that communication and agreement between team members – is the key to success.

        Fist of Five
        Is a simple and fast mechanism to achieve consensus in a group and drive discussion. After an initial discussion on a given proposal or a pending decision, the Scrum Team members are each asked to vote on a scale of 1 to 5 using their fingers. The value in using this technique is not only consensus building but also driving discussion because each team member is asked to explain the reason for their ranking. They are also given the opportunity to express any issues or concerns. Once the team has discussed it, a collective decision will be made.
        The number of fingers used to vote indicates the level of agreement and desire for discussion:

        • One finger: I disagree with the group’s conclusion and have major concerns.
        • Two fingers: I disagree with the group’s conclusion and would like to discuss some minor issues.
        • Three fingers: I am not sure and would like to go with the group’s consensus conclusion.
        • Four fingers: I agree with the group’s conclusion and would like to discuss some minor issues.
        • Five fingers: I wholeheartedly agree with the group’s conclusion.

        T-Shirt Size
        Is a technique used for relative estimation and high-level sizing of Items/User Stories. You use this technique of relative estimation as opposed to absolute estimation when you just need a rough estimate or comparison of items. Speed is valued over accuracy which stops people from overthinking and overanalyzing, as you just want people to use their instincts and gut feeling. Information may not be available at this point anyway for detailed estimates.
        You can have as many t-shirt sizes as you like, but best to keep it simple as it’s only a rough estimate.
        The most common amount is 4 – Small, Medium, Large and Extra-Large.

        The main difference between the 2 commonly used techniques (Planning Poker and T-Shirt size) is based on what amount of User Stories will be estimated. In Planning Poker, you can estimate less Use Stories than in T-Shit size, because Planning Poker is about the interaction between people, communication amongst them and reaching consensus. According to Scrum rules, for the Sprint Planning meeting we have no more than 4 hours for 2 weeks of the Sprint. That’s why if you will use Planning Poker, you can’t estimate a lot of User Story (usually you can estimate less than 15 User Story per session). Instead, this type of effort assessment, gives us a clear understanding between team members, many details could be discussed, and a lot of risks could be identified, just because people communicating with each other.

        There is a lot of information about using Scrum Planning meeting and many suggestions on how to use it correctly, but we really believe that we need to use only what works for us better, what brings value for our company, what makes a customer satisfied and a team is happy and productive.

        Just to be cleared at this point, there are several recommendations that the Sprint Planning meeting should be divided into 2 parts :

        1. User Story Estimation and the
        2. Tasks Estimations to complete this User story.

        Our Sprint Planning Meeting includes just User Story Estimation. It means that the effort required to complete each User Story is estimated during this meeting. With regards to tasks, all team members are responsible for decomposing the User Story into small manageable pieces/tasks, as well as estimate these decomposed tasks. This can be done during a Sprint Planning meeting or not. Formally, we don’t have a specific rule for that. Only one point is important: to have as much as possible of Estimated User Stories and Estimated tasks before the start of the next Sprint.
        We use several techniques to estimate tasks, based on how accurate an estimation should be given for each task and what information do we have about these tasks. Of course, it is important to give a real estimation, which is very close to reality, that’s why we are using some techniques to make it happen:

        • Analogous estimation means that will be used estimation based on experience from past projects. It’s not so accurate estimation technique, but you can use it for high-level estimation.
        • Parametric Estimation is a more accurate technique for estimating the cost and duration of the task. It uses the relationship between variables to calculate the cost and duration. Parametric Estimation is determined by identifying the unit cost or duration and the number of units required for the project or activity. The measurement must be scalable in order to be accurate. In other words, you need statistical data.
        • 3Points Estimate is a part of the Program Evaluation and Review Technique (PERT). This method based on 3 points to calculated weighted mean or so-called Beta Distribution.


        Most Likely Time is the most probable, therefore, it has the biggest weight.

        Pessimistic Time – the worst scenario. When everything goes wrong, there are a lot of risks, constraints
        Optimistic Time – good scenario. When everything goes according to the plan
        Most Likely Time – most probable. When everything goes according to the plan, but we assume some risks or changes can happen in the future.

        Further, you need to calculate a Standard Deviation, to understand possible deviation from the initial plan.

        Standard Deviation Formula:

        When we know everything what we have to do in the next Sprint, we create the Sprint Backlog.
        The sprint backlog is a Backlog of prioritized Items /User Stories, their estimation, acceptance criteria and Definition of Done.

        Every day we have a Daily Scrum meeting which focuses on understanding what issue or blocking points we have and what we will do with that. This is in addition to standard questions like “What did you do yesterday?” and “what are you planning to do today”. Each team makes their Daily Scrum different, depending on what you want to capture during this meeting, but we believe that: “If it works for you and brings value- do it this way!”. This is exactly what Agile mean s for us. And of course, the duration of this meeting is less than 15 minutes.
        A Sprint is finished with a presentation of the deliverables that were performed in a span of 2 weeks. Of course, we have a situation, when a deliverable is too big and it takes more time to show how it works, however, the goal of each Sprint is to make sure that we have usable increment at the end of the Sprint.

        One of the main points of any project is Lessons Learned, no matter what timeframes you are working on. We really believe that learning makes us better, therefore, after each Sprint, we look at what we can do better, what we are not going to do in the next Sprint and what went well. One of the important points of Retro meeting is to make sure that all suggestions for what needs to be improved are tracked and will be implemented. We are not discussing improvements just for being discussed! We are tracking all team’s feedbacks and the team decided what, when and how it can be improved, so that, each next Sprint gets better.

        In a nutshell

        It’s really safe to say that all Scrum ceremonies and techniques help you manage your projects properly, but if you don’t have a flexible mindset, if you don’t want to change, adapt and respond to challenges- you may never achieve your goals. The first thing we need to do – is just to understand that there is always a way to make you perform better, just open your mind and experiment.

        Tell us about your project

          By using this form you agree with the storage and handling of your data by this website.
          Send me NDA

          A letter from your future colleague, Daria

          Dear Future Colleague,

          I am Daria, Head of Sales, and for me DAS is a real professional adventure. I’m amongst those few people who witnessed the raise of the company, its first steps, its victories and challenges along the years. I joined the core team of DAS at the moment when its establishment was in the active process of materialization. I remember that November day when I came to see yet an empty, but already OUR first office, ah…the pleasant feeling of having your own place. It was the beginning. I met the initial small team of five developers who built the foundation of the first projects and gained the trust of our initial clients.

          In the beginning, I was involved in a pilot project, not related to IT, and at some point, I was offered to try my skills in the sales department. I found it interesting, though, must confess stressful at the beginning. My colleagues trusted that I can grow my competencies in this direction. I closed my first deals and felt extremely happy. This is how I continued with the sales. In the meantime the team was growing, I was meeting great people and establishing friendly relationships.
          Of course work is not only about friendship. Sales is a hard and responsible work. You need to always remember that it’s on you that your colleagues will be covered with tasks, projects, and of course financial benefits the next day, weeks, months.
          Even though it’s not an easy job, I love my team and the way we share information, thoughts, experience, happy and sad moments together.
          They are like a part of my family. It can be funny, it can be stressful.
          I love to observe the difference between the dialogue you can have via emails, chats, phone calls and the moment when the person see you live. It’s like breaking the ice and entering a new space.
          What I would say to new people joining DAS?… Be friendly and don’t use too much perfume, please. 🙂 
          If I would be asked to share some advice for a sales person, then I would say that my main mantras are:
          1. Don’t give up. Never.
          2. Be yourself with your customers, because after all it’s all about human interaction.
          3. Be honest in everything you do (first of all with yourself).
          4. Take responsibility for your deeds. It makes you stronger and more attentive.
          5. To fail is human. Learn from your fails, turn the experience into wisdom (if possible), don’t repeat it and get back to point 1.

          I believe that the company is like a living house, a natural organism which can grow and evolve. In this house, every new person is like a new room with a new door which opens a new space, furnished in a distinct way, with its personal design, wallpapers, furniture and atmosphere. And each room of this house has a window with a unique view outside the house.

          I wish that every new room would make the house better, stronger, more interesting, distinguished amongst many other houses and may every view from all the windows remain unique, but all as one – beautiful.

          As you (maybe) can tell – being in sales doesn’t mean to lack the seed of poetry in your soul.  

          Happy journeys!