Agile in customized web development
If we (a web studio or a private developer) are doing a web project for ourselves, we are free to choose a development method: flexible (Agile) or cascading (“waterfall”). As a rule, the more complex the project, the less chance of a waterfall. But when we make a website for a customer, the method is always the same: cascading. This article is about how (and why) to convince a customer to try a flexible model for complex web projects.
To prove something to the customer, you need to think like he thinks. Without going into details of a flexible methodology (I will give some useful links at the end of the article), we will try to make a comparative table.
The development process in a cascade model is divided into a limited number of stages. Usually they are: a pre-project study (according to the results - estimates for the preparation of technical specifications), design (TK and estimates for the project are obtained), design drawing, development (it can also be divided into stages), filling, testing, delivery. In the flexible model, after each iteration, we have a conditionally completed project (“preliminary site structure and draft design”, “bare site with draft design”, “the same with the interface to the customer base”), which can be used as a basis for continuing work , further detailing or rethinking the previous steps.
Design in a cascade model is the writing of a large detailed TK based on the study of the subject area, the customer’s internal information system, interviews with its employees, etc. In a flexible model, detailed TZ may be absent: to get started, you only need a clear understanding of the audience, the goals and objectives of the customer, as well as a general vision of the project: an approximate structure, requirements for design, a general description of functionality. Detailed TK may be, but it should be accompanied by the understanding that in the process of work TK can change significantly.
In a cascade model, client involvement in a project usually occurs 3-4 times: when choosing a contractor, in the design process, when approving the TOR and design, at the end of the project. In a flexible model, the customer must be prepared for the fact that they will be jerked for approvals and discussions every one to two weeks, thereby detaching from other equally important matters. For "lazy" customers (they are also "busy"), this can be a serious obstacle.
')
As for the timing and cost of the project , when working in a flexible manner, neither the contractor nor the customer know when the project will end and how much money it will cost. However, even with a cascade model, it often turns out the same :)
Well, finally, the principle of payment . In the cascade model, the customer pays for the site: so much for design, so much for programming, so much for data import, etc. In the "flexible" case, he actually pays for the process of work (even if estimates are made not upon the execution of the next stage, but before that). It's worth talking about it separately.
Customers do not want to pay for the process. After all, your programmers may be unprofessional, spending twice as much time as necessary; you can be distracted by a more profitable project, without bearing responsibility for delaying the deadlines; You can deceive the customer by attributing extra hours. The customer is not used to this: he knows in advance how much it will cost him to update the computer park, cleaning the office, supplying stationery, sending products to another city. Why should the site be an exception?
The difference is that we are creating a new product, something we have not done before. Of course, for sure there are projects that are very similar to ours, but if the project was not done by us, then we can’t judge their complexity. And it’s very rarely possible to reuse my own workings, I know it myself (for more than 10 years I have been managing a web-studio specializing in complex web-projects). Thus, we can take a preliminary assessment of a large project either from the ceiling or based on the previous experience of “most-similar-to-this projects”, that is, also from the ceiling; and we will put a “risk” on top. If we are lucky, we will make the project faster and save (the customer is in the red). If you are unlucky - we will delay the project, we will be forced to save on testing, cross-browser, documenting. It turns out, the customer is again in the red.
Therefore, if we approach the project as an innovation, an invention, it will be much easier for us to justify the need to pay for the process.
When paying "for the result" we are faced with the fact that we buy one (the time of our employees), and sell another (design layout, software module). Above, I showed that we will solve problems with the wrong conversion of one to another in any case at the expense of the customer, because we don’t have other sources of income besides clients. The cascade model can create other problems for the developer. For example, the project will be delayed due to the fault of the customer, and we will not be able to get paid on time. And since a large project, the absence of this planned payment may create a gap in the budget. We will not be able to pay salaries or rent on time, which is unlikely to have a good effect on employee motivation. And it will still hit the client.
Another example of a potential cascade model problem is the inconsistency of the result with customer expectations. In my practice, when a project was submitted, more than once there was a dialogue in the spirit of:
- What it is? I do not need this at all!
- So we did everything according to TZ, you signed it.
- Are you kidding me? There are 100 pages of your bird language, I did not master it, I relied on your professionalism.
- Okay, remake, pay money.
- Here's another, I paid so much money, redo it for free.
- We will not.
- And we will not pay until you redo it.
The situation is stalemate, each side considers itself right; even if the developer will have to bend (as it usually happens), the customer will also lose: time, loyal partner. Agile dramatically reduces the risk of such problems.
If the relationship between the customer and the developer is equal, partnership, based, among other things, on trust and the understanding that the problems of the other side bother us, then both parties will try to help each other solve problems related to the project.
By the word "lazy" I mean not only and not so much natural laziness. An ideal customer is one that:
In addition, lazy customers are very shy. On my own experience, I was convinced that:
Since NetCat separated from the AIST web integrator (legally a year ago, actually more than two), we have become a recipient of a custom web development service provider (customized web development is very different from the design of lottery software). We are a small company, and we try to outsource all the work that is not very relevant for us: layout, design, auditing, work on the site; and sometimes even profile work, too. Wherever it makes sense, we try to use flexible methods.
As a customer of web development services, we experienced both disadvantages (bad faith or lack of professionalism of the contractor, the impossibility of visual contact during work), and Agile advantages. I think that it will not be too presumptuous to say that we are a pleasant customer for our contractors.
But we, of course, are far from a typical web studio client, because we understand the business of web development well. But there were no examples of a successful “flexible” project for an offline customer (when I am in the position of a developer) in my practice. If you had such, be sure to write in the comments (and I will put a link to them in the post): how did you manage to convince the customer whether the project was successful, whether it was possible to save in money or time.
To ensure that the article does not turn out to be one-sided, it is worth listing the negative sides of Agile from the point of view of the customer. First, there is a whole class of customers who simply cannot fail to work according to a cascade model: government organizations, large firms that are obliged to plan and approve estimates in advance. But it is they who first of all order large projects.
But even if the customer can and is ready to work on a flexible model, for him it will be a stressful process. I know for myself: it is morally difficult not to be able to plan a budget and release dates; it is much more convenient to issue a task and forget about the project for a couple of months than to constantly return to it. Yes, and the opportunity at any time to transfer the project to another developer, which is presented as one of the main advantages of Agile, rarely goes smoothly. Therefore, the customer must be really very well motivated.
But the most important thing in Agile work is mutual trust, both at an interpersonal and professional level. In order to get a good “flexible” project, you must not only trust the customer, but also ensure that he trusts you: your honesty, the professionalism of your employees, your motivation. In this case, the customer will be able to get the project that he needs (not to be confused with the one he wants), and you will make an interesting project (big projects are always interesting), in addition to well-deserved money, you will also enjoy the process.
Agile and the waterfall through the eyes of the customer
To prove something to the customer, you need to think like he thinks. Without going into details of a flexible methodology (I will give some useful links at the end of the article), we will try to make a comparative table.
| Model | Cascade | Flexible |
| Development process | Continuous, with predetermined stages | Iterative, number of iterations unknown |
| Design | Once, at the beginning of the project, detailed | Repeated, detailing as necessary |
| Customer involvement | 3-4 times | Permanent |
| Timing and budget | Predefined and spelled out in the contract | Unknown until the very end of the project. |
| Customer pays for ... | Result | Process |
Design in a cascade model is the writing of a large detailed TK based on the study of the subject area, the customer’s internal information system, interviews with its employees, etc. In a flexible model, detailed TZ may be absent: to get started, you only need a clear understanding of the audience, the goals and objectives of the customer, as well as a general vision of the project: an approximate structure, requirements for design, a general description of functionality. Detailed TK may be, but it should be accompanied by the understanding that in the process of work TK can change significantly.
In a cascade model, client involvement in a project usually occurs 3-4 times: when choosing a contractor, in the design process, when approving the TOR and design, at the end of the project. In a flexible model, the customer must be prepared for the fact that they will be jerked for approvals and discussions every one to two weeks, thereby detaching from other equally important matters. For "lazy" customers (they are also "busy"), this can be a serious obstacle.
')
As for the timing and cost of the project , when working in a flexible manner, neither the contractor nor the customer know when the project will end and how much money it will cost. However, even with a cascade model, it often turns out the same :)
Well, finally, the principle of payment . In the cascade model, the customer pays for the site: so much for design, so much for programming, so much for data import, etc. In the "flexible" case, he actually pays for the process of work (even if estimates are made not upon the execution of the next stage, but before that). It's worth talking about it separately.
Website as an invention
Customers do not want to pay for the process. After all, your programmers may be unprofessional, spending twice as much time as necessary; you can be distracted by a more profitable project, without bearing responsibility for delaying the deadlines; You can deceive the customer by attributing extra hours. The customer is not used to this: he knows in advance how much it will cost him to update the computer park, cleaning the office, supplying stationery, sending products to another city. Why should the site be an exception?
The difference is that we are creating a new product, something we have not done before. Of course, for sure there are projects that are very similar to ours, but if the project was not done by us, then we can’t judge their complexity. And it’s very rarely possible to reuse my own workings, I know it myself (for more than 10 years I have been managing a web-studio specializing in complex web-projects). Thus, we can take a preliminary assessment of a large project either from the ceiling or based on the previous experience of “most-similar-to-this projects”, that is, also from the ceiling; and we will put a “risk” on top. If we are lucky, we will make the project faster and save (the customer is in the red). If you are unlucky - we will delay the project, we will be forced to save on testing, cross-browser, documenting. It turns out, the customer is again in the red.
Therefore, if we approach the project as an innovation, an invention, it will be much easier for us to justify the need to pay for the process.
Your problems are customer problems.
When paying "for the result" we are faced with the fact that we buy one (the time of our employees), and sell another (design layout, software module). Above, I showed that we will solve problems with the wrong conversion of one to another in any case at the expense of the customer, because we don’t have other sources of income besides clients. The cascade model can create other problems for the developer. For example, the project will be delayed due to the fault of the customer, and we will not be able to get paid on time. And since a large project, the absence of this planned payment may create a gap in the budget. We will not be able to pay salaries or rent on time, which is unlikely to have a good effect on employee motivation. And it will still hit the client.
Another example of a potential cascade model problem is the inconsistency of the result with customer expectations. In my practice, when a project was submitted, more than once there was a dialogue in the spirit of:
- What it is? I do not need this at all!
- So we did everything according to TZ, you signed it.
- Are you kidding me? There are 100 pages of your bird language, I did not master it, I relied on your professionalism.
- Okay, remake, pay money.
- Here's another, I paid so much money, redo it for free.
- We will not.
- And we will not pay until you redo it.
The situation is stalemate, each side considers itself right; even if the developer will have to bend (as it usually happens), the customer will also lose: time, loyal partner. Agile dramatically reduces the risk of such problems.
If the relationship between the customer and the developer is equal, partnership, based, among other things, on trust and the understanding that the problems of the other side bother us, then both parties will try to help each other solve problems related to the project.
Lazy customer - the enemy of Agile
By the word "lazy" I mean not only and not so much natural laziness. An ideal customer is one that:
- has enough time and desire to work closely with you throughout the project
- possesses (or seeks to possess) skills on the Internet at least at the level of advanced user
- not afraid of experiments and their responsibility for participating in them
- really interested in making a very good project
In addition, lazy customers are very shy. On my own experience, I was convinced that:
- it is impossible to plan tightly for the release of a large project, since programmers break deadlines always
- in the process of work, very often new interesting ideas come to mind that contradict the original TK
- in a few months that the development of the project lasts, the client’s vision of the tasks may change, and this information may not reach the developer
- the most thoughtful interface on real data is not always as beautiful and convenient as on prototypes
- designers very rarely “get into the task” as the client sees it (and this is not always the designer’s fault), and are forced to redo the layouts
- big specifications are not read completely not only by clients, but also by developers
Our experience
Since NetCat separated from the AIST web integrator (legally a year ago, actually more than two), we have become a recipient of a custom web development service provider (customized web development is very different from the design of lottery software). We are a small company, and we try to outsource all the work that is not very relevant for us: layout, design, auditing, work on the site; and sometimes even profile work, too. Wherever it makes sense, we try to use flexible methods.
As a customer of web development services, we experienced both disadvantages (bad faith or lack of professionalism of the contractor, the impossibility of visual contact during work), and Agile advantages. I think that it will not be too presumptuous to say that we are a pleasant customer for our contractors.
But we, of course, are far from a typical web studio client, because we understand the business of web development well. But there were no examples of a successful “flexible” project for an offline customer (when I am in the position of a developer) in my practice. If you had such, be sure to write in the comments (and I will put a link to them in the post): how did you manage to convince the customer whether the project was successful, whether it was possible to save in money or time.
Thin flexible spots
To ensure that the article does not turn out to be one-sided, it is worth listing the negative sides of Agile from the point of view of the customer. First, there is a whole class of customers who simply cannot fail to work according to a cascade model: government organizations, large firms that are obliged to plan and approve estimates in advance. But it is they who first of all order large projects.
But even if the customer can and is ready to work on a flexible model, for him it will be a stressful process. I know for myself: it is morally difficult not to be able to plan a budget and release dates; it is much more convenient to issue a task and forget about the project for a couple of months than to constantly return to it. Yes, and the opportunity at any time to transfer the project to another developer, which is presented as one of the main advantages of Agile, rarely goes smoothly. Therefore, the customer must be really very well motivated.
But the most important thing in Agile work is mutual trust, both at an interpersonal and professional level. In order to get a good “flexible” project, you must not only trust the customer, but also ensure that he trusts you: your honesty, the professionalism of your employees, your motivation. In this case, the customer will be able to get the project that he needs (not to be confused with the one he wants), and you will make an interesting project (big projects are always interesting), in addition to well-deserved money, you will also enjoy the process.
Related Links
- Agile , Scrum , Waterfall on Wikipedia
- How to sell Agile to the customer , Askhat Urazbayev (video)
- Features of Scrum in custom development , an article by Boris Wolfson on Habré
Source: https://habr.com/ru/post/133229/
All Articles