Various collaborations between a software development company and a client require flexibility in communication as well as in work methods to achieve the best tailor-made results. Even though it’s said “he who pays the piper calls the tune”, there are also occasions when to say “no”.
Every collaboration between a software development company and a client requires pre-analysis. This analysis includes mapping of the desired results in the technical as well as in the business perspective, but it also involves agreeing on the work process to get there. Behind-the-scenes preliminary work also includes teaming up the right people for the job. This is all necessary to assure graceful cooperation from start to finish, even if there will occur some bumps along the road and the need to make changes.
Helmes is a software development company that is known for the skill for saying “no” at the right moment, but there are occasions when the cooperation partner needs a little bit more convincing.
One illustrative story of this is about a promising Scandinavian start-up that had the ambition to make some revolution in the recruitment of temporary employment. The client had a clear vision regarding the desired features of their product and had a strong wish to oversee the software development tasks. This is a good thing – a decisive partner is always a plus. But in this case, this decisiveness excluded the need for technical and business pre-analysis. And the “limp” started to show after only two months.
Due to the lack of a bigger picture and clients IT illiteracy, the “limping” included:
- An impaired flow of cooperation and work processes;
- Continually changing development ideas and tasks;
- Struggling to meet the development goals by the end of the agreed sprints;
- The decreased motivation of the development team due to the disorganized arrangement of tasks and failing to achieve deadlines; and
We are not code-robots; we want the best for you!
This is the part where the famous “no” was brought into play. This included rewinding the project to the beginning and getting everybody on the same page about what is a top-shelf outcome and about what are the best tactics to achieve it.
The “no” comprised the following:
- Implementing a reasonable business and technical analysis for making wiser decisions regarding development tasks. Every new task the client requested was now first pre-analysed, both from a business and technology perspective. Many bad ideas were canceled, and for many other ideas, we found smarter ways of implementation.
- Changing the project management method. The rather rigid Scrum methodology was replaced with a more loose-limbed Kanban method. This methodology allows the client to make as many changes to the work plan as needed. The developer will just concentrate on a task that the client sets as a priority in the task list.
- Trusting the recommendations. One cannot emphasize it enough – the fundamental of any successful cooperation is trust.
These changes were a win for both sides. The client was able to maintain the responsibility and freedom to set the tasks and prioritize, and the software development team achieved success by getting things done. A cooperation that was about to go sour was now blooming.
Communication and mutual feedback is crucial in agile development.
Particularly important is constant reflection and the will to become better and make the work process even more efficient. There is an endless list of details to improve oneself throughout the cooperation process. But this is doable, and the ideal process for the client and for the software development company.
Trusting the ‘no’ of a professional software development company will provide you with the following:
- A smart and time-effective software development process;
- Smooth communication and cooperation;
- Sensible, easily manageable and changeable solutions;
- A committed and motivated team to achieve the best results; and
- Cost efficiency
Trusting the analyst pays off
An analyst is a sort of a filter between the client and the development team of a software company. The analyst thinks about the following:
- What are the desired business process and its results;
- What is the smartest way the technical system should function, starting from the architecture to screen views and UX, and how the end-consumer will use it;
- An analyst suggests the most efficient work plan, analyses which pieces carry the largest value and prioritize accordingly; and
- Keeps in mind the business problem that needs to be resolved throughout the development process.
Scrum vs. Kanban
Scrum is an agile development method with fixed sprints. One sprint is usually with the duration from one to four weeks. Every sprint has a concrete to-do list, and in the end of the sprint, there will be a retrospective of what is done and what needs to be improved.
Kanban is a Toyota invented agile development method with an ideology that there are no rigid milestones. The priorities in the to-do list can be changed constantly. The idea of the software development process is to work with the task that is currently the top priority, finish it, test it, and then move on to the next assignment. However, the priorities that make the Kanban list must pass through pre-analysis and even prototypes, when necessary.