To be at the forefront of their industry, businesses need to constantly evolve. It is no longer enough just to build a website and wait for customers.
What makes a true leader different is that they aim to upgrade their online presence on a regular basis: they try new things, test hypotheses and want to bring ideas to life in as little time as possible.
If you are aiming at scale, it is not enough to give a freelancer the task of "changing the picture on the home page". You need to entrust the development of your web-project to those who will maintain it in working order and at the same time improve it.
At Initlab, we believe that a website is a process, not a ready-made solution. Constant planning, the balance between solving current problems and introducing new features: done, analysed, outlined improvements - this song has no end, start again.
Our job isn't just to fix minor flaws - we're interested in the long-term development of the client's site. We've been in IT for so many years for this reason.
In this article, we'll tell you how agile development is organised at Initlab and how it helps us maintain and improve our clients' websites in parallel.
A little about ourselves
We are Initlab. A cool team of specialists with twenty years of experience in web development and 15 years in Drupal. We're called when the simple is done and the complicated is left. When everyone has given up or broken everything, when there are large-scale projects that the client wants to develop.
How agile development is built
We won't say anything new to those who have heard of Agile or Kanban. But if you want to learn about the obvious benefits of this approach, stay tuned. In classic website support, the scenario is: the client is told the price per hour of work→ a contract is signed→ tasks are given to performers→ they are completed. In the case of agile development, after the client asks, the following happens:
1. Calculate the approximate time it will take to do all the planned work. The keyword is approximate. We do not give an exact estimate on the revision of the site in cases where: 1) if the site was not made by us and we do not know how it is written; 2) if we have to do something new and we still do not know what and how much it will take. We give a rough estimate at the client's request, based on our experience.
2. We agree on the optimum budget per month. In a classic situation, the client is invoiced at the end of the month/quarter based on the work done. For flexible development it is necessary for the client to determine the amount of money he is ready to invest in the support and development of the site per month, and we calculate whether it is enough to employ the necessary team and planned tasks. We'll tell you what it's for below. When the budget is agreed upon, we sign a contract.
3. Prioritise the tasks. What needs to be done urgently, what can be tolerated for now, and what can be done on the remaining budget? In most cases, it is the client who prioritises tasks, especially if the project is large and there is a lot to do. For our part, we give a list of tasks that the client may not think about from his point of view: testing the site, eliminating technical debt, etc.
4. Allocate the budget to all the tasks you are planning. The most important item has its own section.
Spreading the budget
Every project is different and there is no single recipe, so as an example, we will describe a generic version of where the money goes. Thus:
1. Monitoring the state of the site with manual and automatic tests. Is the shopping cart working? What are the results of searching the site? Is the layout upside down? All this should be checked after each change/update. Small projects have enough human power, larger ones need automation. It takes approximately 20% of the budget for continuous testing.
2. Problems, bugs, operational tasks - from the "drop everything and run to fix the basket" category. We allocate about 30% of the budget to this.
3. technical debt - fixing accumulated bugs and defects. Past developers do not always leave the site in perfect condition. Small defects can slow down the site and complicate development. Technical debt takes about 10% of the budget to fix.
4. upgrading to the latest versions of the site software. For example, upgrade Drupal from version 7 to 9. On this we put about 10%.
5. New business functions. We make a road-map with a customer: what will be the site in a year or two and what functions he wants to see there. For big business, this is probably the most essential part of the job, so we spend about 30% of the budget on it. If we "make sense", all the above helps us to keep the balance on the project: to solve urgent tasks and in parallel to harmoniously develop the project. Roughly speaking, putting out a fire and planting new trees at the same time is agile development.
The percentage from our 'example in a vacuum' can be allocated as desired according to current goals and objectives. We save 30% until the end of the month for urgent tasks, but doesn't anything happen? The allotted hours can be spent on security upgrades. Closed the technical debt that was preventing normal work faster than planned? Use the remaining budget for something else.
As the project develops, we are constantly analysing whether it needs new business features, working on speeding up the site, and updating all the available Drupal modules. If the site expands and language versions appear, our job is to create copies of it. On large-scale projects, we need to make sure that changes are made in one place and updated on five sites.
Maintaining a website is not just about current tasks. It is thinking ahead, maintaining a state of readiness for business growth, expansion and development.
Distribution of tasks
To the client, all this can sound daunting. How can they know that we have sorted out the main problems and started to improve the project according to our plan. As they say, it sounds nice, but how do you prove it? One of our main principles is openness. And it is easy to do so with our task-setting and task-control service (tracker). We give the client access to the tracker and teach them how to use it. All processes can be monitored here. But first and foremost, together with the customer, we enter the required tasks into the system and prioritise them. You can add, change or refine what you need at any time.
Tasks are allocated to the assigned project specialists in order of priority according to their specialisation (front, back, administration, etc.) We make changes to the site when ready, rather than waiting until the end of the month, another iteration or payment for the task. For us, as for our client, the result is primary.
Customer fears: missing tasks, project pauses and missed deadlines
In practice, we have encountered different attitudes to the planned budget, which is important for agile development. Let's list some of them - Let's pay for it when the tasks are done.
The point of budget planning is to reserve the developer's time. If a developer isn't engaged in your project, he is most likely busy with another one, and it's hard to pull him away - he allocates his time where there is a work plan and a clear salary. Once tasks from an unscheduled project fall on him, he is likely to take a very long time to get to it, because the schedule is packed. If the client is prepared to wait for months, this format of work is in principle possible.
- And if there are no / few tasks / business has difficulties, and the budget has already been paid for? It's simple: if there are few tasks, we redistribute time on things that are not directly related to business: refactoring code, setting up testing, etc. That is, on the existing budget we prepare the site for future growth, to accelerate and simplify future processes.
If there are more tasks than the budget, we agree on increasing the budget (if the business is ready), or we "cool down" and focus only on what is important. If the business is having problems, of course, we can put the process on hold. But here you have to realise that it takes time for developers to shut down services and then they will go off to other projects. When work resumes, follow-up onboarding and some time to get the right people back together will be necessary.
But we have little faith in the complete absence of tasks on the site. It's like a private home: there is always something to do. With a fixed budget and flexible design, we can:
- stop tasks if they take too much time or while something more important has come up;
- redirect resources to what the business needs now;
- Correct critical errors that were found in the process without waiting for additional approvals.
Developers will always know what to do on your site. There are no separate meetings, no tedious negotiations about which button to move this month and when we will finally roll out the catalogue expansion - tasks are set through the tracker, the site improves, business runs and grows.
Rigid development: fixing hours per task and penalties for failing to meet deadlines
Some customers are still intimidated by uncertainty. They feel that the allocated budget is not being spent correctly and want to be specific: tell us exactly how much it will take for this task. We have written above that we do not give a clear estimate, but let's say the client asks for it and we give in: our estimate is 5 hours. And the client, in order to keep the budget within the limits, adds: if you exceed these hours, you will pay a fine or do it at your own expense?
Sounds fair: if you've done the estimate, do it for as much as you've estimated. But let's try to transfer this approach to another job. Let's say you tell an electrician that your socket is broken. He quotes a price for the job and starts working. In the course of the inspection, it turns out that the problem is in the wiring. Is it fair to demand from the electrician to change the wiring in the same amount of time as the socket and for the amount he initially quoted?
Or the opposite situation: you've decided that your meter is permanently broken and you're getting ready to shell out a hefty sum. But it turns out that it's just a loose wire and it's not that bad. The electrician will either charge you less or use the remaining money to check/repair outlets/switches/lights in all the rooms. When a customer asks for a specific cost for a step or task and wants to fine you for exceeding it, there are a number of problems that arise:
1. We can only take on a complete ToR. Describe to the molecules what exactly needs to be repaired and where. On the client's side, you either need a competent person who is able to give detailed terms of reference, or you need to pay for the time of our manager, who will clarify/supplement/clear up what you need. And if it turns out that the customer didn't want or didn't want it that way, the bribe is free: the TOR is agreed upon, we worked strictly according to it. Plus, you won't get any edits along the way. A simple request to repaint/move a button at the same time will require new approvals and a new ToR.
2. We have to lay down risks. If someone agrees to work with you in this format, then they have already multiplied the estimate by a factor of two or three. No one is going to work at a loss. We don't think this is very fair, but in such a case you have to cover the costs: the manager, the appraisers, the possible fines. Instead of an approximate but more honest estimate, we insure, multiply the hours by the tasks and your costs. We are not comfortable with this approach. Conditional peace of mind only multiplies the cost of the project.
3. we are not interested in finalizing tasks. Get it right: if a developer does a task and finds a problem along the way, they will not solve it to the detriment of the time available for the main part of the work. Even if the 'side quest' is quickly solved. Now he will simply say that there is such a problem and wait for the TOR to be agreed with the client. We end up agreeing, formalising, clarifying, drawing up, counting and estimating. And we could be working. Where better to start, get 80% of the result, refine and finish. Flexible design means:
- more trust on the part of the customer;
- prioritising rapid implementation of change over reading and signing paperwork.
Communication with the manager and project managers does not turn into a series of approvals - it is a joint work of people interested in improving and developing the site. In summary: it is possible to work in this format, but it is necessary to do so:
- to tax the team with managers;
- to assess any kind of bullshit;
- not to expect our team to give their all;
- accept the fact that risks have been mortgaged.
Flexible development + years of well-established work processes = solving our customers' large-scale problems:
- enter new markets and develop language versions of the website;
- launch online sales;
- speed up the operation of the website;
- update the design and add new and needed features;
- fix any bugs that cause the company to lose money
and still stay within an understandable budget.
Conclusion
Let's conclude with the idea we started with: a website is a process. A process that should run like clockwork, or be like a continuous dance, if you like. The future lies in a coherent alliance of businesses and development teams dedicated to helping those businesses. We at Initlab are sure of this, and we base all our work on this basis.
Add new comment