Mastery of agile processes in custom development. Key steps to successful collaboration between vendor and customer

Author of the article: Dmitry Kurdyumov

Participated in Agile transformations in the largest companies in Russia (Alfa Bank, MTS, X5 retail group), with international experience in startups abroad.

My name is Dmitry and I am engaged in Agile transformation of companies and help companies build processes, and I am also the founder of a consulting agency Smart units. Over the past few years, I have been building custom development processes and also participated in large product implementation projects together with the vendor. And here I made a lot of mistakes, and also formed a set of rules on how you really need to develop a product if suddenly you are either a Customer or a company that provides custom development services.

The system that I will describe will allow you to get faster and better results when doing custom development. And the companies themselves that do custom development will receive happier clients who will return for new cooperation.

The key problem of custom development

Custom development is one of the most difficult development processes, because… During this process several calls occur:

  1. Solve the Customer’s needs so that he is satisfied;

  2. Do this within a limited time frame and budget;

  3. Organize effective interaction between the Customer’s team and the development company.

And within these 3 questions, a number of problems arise in classical development:

1 problem. During the preparation of the project

Preparation of the project, during which they try to take into account all the details and package them with technical specifications. As a result, we spend a huge amount of time and resources in order to take into account all requirements. I went through a similar path with different companies and instead of starting to make a product, we spent months trying to agree on a contract, constantly correcting clauses of the contract and discussing the cost. And how many resources were involved in analytics, development, security and others.

Why is this a problem:

  • Uncertainty at the start of a project: In the early stages, it is often difficult to fully define project requirements and details, which can lead to incorrect assumptions and planning errors.

  • Freezing requirements: Trying to take all the details into account from the beginning can lead to the desire to “freeze” the requirements, which makes the system unable to adapt to change. During the project it is very difficult to make these changes; there is a cycle of agreeing on Scope, cost and changing the contract.

As a result, this is a waste of a lot of time for something that will change anyway.

So in one company we spent several months agreeing on requirements with the vendor, although then these requirements were constantly changing and we spent no less time on approval.

Problem 2. Implementation according to technical specifications

The problem is that when implementing according to a strict specification, we stop thinking about the result, and think only about how to fulfill the specification.

I have often noticed that during implementation according to strict specifications, people stop thinking and make mistakes. Also, the vendor’s only goal becomes to meet the deadline and they even stop thinking about quality. So in one project, when the deadline was coming to an end, and a lot of things had not yet been done, the vendor simply began to sacrifice quality just to deliver the project on time. And when the Customer began to review the code, they found a lot of imperfections and technical debt, which had to be eliminated after the project was completed, spending additional budget.

Also, the vendor does not know the specifics and real needs of the Customer, so development according to the technical specifications proceeds head-on, and even if something was not taken into account, the vendor is unlikely to ask about it, since he does not have the full picture.

3. Interaction between the customer, his team and the vendor’s team

The interaction between the Customer and his team and the development company often looks like a complex machine in which it is impossible to communicate and quickly resolve issues. Everything is very formal, teams, as a rule, are located at a distance, communications take a long time and most importantly, everyone is responsible for their own piece, but when they need to do it together, everything breaks down and no one wants to take responsibility.

Whenever the solution made by the vendor depends on the decisions of the Customer, when it is necessary to tightly integrate and test the solution together, overall teamwork is important, otherwise it will turn into something where everyone has done their own piece, but there is no overall result. And for it to work, the same amount of time needs to be spent on corrections and integration.

How to work differently or a flexible approach to project implementation?

Firstly, in any project when implementing custom development, it is necessary to understand three important factors:

  1. Requirements change

It’s impossible to take everything into account at the startso provide flexibility in your contract with the vendor so that requirements can change.

1.1. It is important to ensure flexibility both in the contract and in interaction

Types of contracts

  • The easiest and most flexible is Time and material, when payment is made for the actual time worked (team days). It’s easy to agree on one-week or two-week sprints, planning points with the vendor and review of results, during which you can easily plan and change requirements along the way, and you can regularly monitor the progress of the project.

  • Another type of contract is when we do not plan the entire project, but plan and fix the scope of work only for an iteration (conditionally for 2 weeks) and every two weeks we have a predicted expected result, to which the vendor commits, and even if it is not completed the scope of work, this does not relieve him of his obligations. At the end of each sprint, a delivery acceptance certificate is signed.

  • You can also include a scope in the contract in the form of user stories that must be made. They must indicate acceptance criteria in order to clearly understand what is planned to be done and there are no discrepancies in the understanding of the Customer and the vendor. The user story, on the one hand, describes the solution to the client’s problem, and on the other hand, it introduces an understanding of what should be done using acceptance criteria.

1.2. Don’t forget about non-functional requirements

An important nuance in development is non-functional requirements that the vendor must fulfill, otherwise without them your application will not work or it will not meet the required quality.

What are these types of requirements:

  • Requirements for testing and test scenarios;

  • Code requirements;

  • System security requirements;

  • Logging requirements;

  • Documentation requirements;

and others.

You can fix the basic requirements in the contract, those that you know exactly what you need. The rest, subject to flexible contracts, you can add as you go.

1.3. Determine Definition of done

A very important document that everyone forgets about and is especially important in an agile development environment. When you discuss iterative development and iteration acceptance with a vendor, it is important to capture the definition of done. Otherwise, a situation will arise when they did something to you, but did not properly test it (for example, the load) or the quality of the code does not meet expectations.

In the Definition of done we include all the things necessary to consider the product or part of it ready.

Without this artifact, you will be shipped a half-finished solution that is not usable and it will be difficult to predict completion because The amount of work in progress will grow every sprint, so it is important to ensure and record the basic definition of done criteria in the contract and ensure that they are met every sprint.

  1. Agree in advance with the vendor to work together as one team

It is important when interacting with a vendor to make sure that the vendor’s team and the customer’s team are working together.

There are several rules:

  • A single chat for the Customer and the vendor where you can resolve product and development issues;

  • Agree on regular calls (daily, planning, results reviews);

  • Determine the rules of interaction and kick off the project at the start with the participation of both parties.

  1. Allocate 100% of participants to the project team

It is necessary to make sure that participants from both sides, both the vendor and the Customer, are allocated 100% to the project team and do not carry out several projects in parallel, as this has a detrimental effect on the speed of interaction, the focus of people and the quality of solutions. In practice, I went through options when people were allocated 100% and when specialists were pulled out for specific tasks. In the first case, the level of motivation, understanding of what we are doing and focus on tasks increased many times, which influenced the speed of interaction, involvement and, ultimately, better and faster results.

4 Discuss the process

If you want to lead Agile projects in custom development, then you must have a process of interaction with all participants in the spirit of Agile:

  • Organize product development in iterations in which all the work must be done (taking into account the definition of done);

  • Make sure there is a Product owner who can make decisions and prioritize the product backlog;

  • Participants are 100% allocated to the team and they have all the tools and authority to implement the project;

  • Ensure fast interaction with service functions. For example, with those who issue access to the company, security. Because often when implementing projects with a vendor, they need to be given a lot of access during the project, and if this interaction and quick response with service functions is not established, then you will simply waste time on approvals. Ideally, again, the project team should include people who can quickly process these requests;

  • Support the Agile culture and values, where the customer and his needs are at the forefront, the desire to do well, and not just deliver on time, get paid and leave.

conclusions

The problems of the project approach in custom development have long been known and 100% of companies face them. The option of fixing the cost, deadline and budget is possible if you are doing something very clear from a business and technical point of view, where there are no dependencies with other teams, including. As a rule, these are packaged solutions or simple websites. However, if you are building products from scratch, or even parts of products, such as mobile applications, where there is business uncertainty, a lot of technical nuances and requires collaboration between several teams, lead projects in Agile.

The principles I described above will help you get a better product, have more transparent development and better communication between parties. Yes, there may be an illusion that the budget and scope are less predictable, but in classical development they are also not unpredictable. The fact that you identified them at the start and recorded them does not mean at all that it will be like that in reality. 90% of the time everything goes wrong.

So in one project, for example, having received a product with a certain scope and amount, we ended up rewriting it because we received a lot of technical debt, and for the next 6 months we spent the next 6 months debugging instead of continuing to develop it. As a result, we spent twice the budget, if not more. And at the beginning everything seemed predictable.

Therefore, why not immediately do everything the normal way and take a flexible route to creating a product in order to get high-quality results for less money?

The article was prepared in anticipation of the start of the course “Agile Project manager”. By following the link you can find out more about the course and also have time sign up for the next stream.

If you are interested in the approach, subscribe to my telegram channeland if you need company support in building such processes, please contact us.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *