Read next
Maintaining and growing
business software systems
Our services
There are multiple myths about developing tailor-made software. Many people think, for example, that once developers receive a specification, they lock up in their rooms for several weeks to develop the software until they open the door and reveal the effects of their work to the delighted client.
In accordance with modern methodologies and to ensure high quality and customer satisfaction, software is always created in close cooperation with the client. For me, software development is not a situation where we simply get a written specification and get down to the coding. My role in the company involves agreeing with the client how the software should work, and overseeing the development process to ensure the client's satisfaction.
Currently, the work of the project team is organized differently. The traditional approach you are talking about is increasingly being superseded by agile methodologies. We also work in this way. In the traditional approach an exact specification of the program is followed by the designing of the entire system, then developers start preparing the source code. Subsequently comes the testing phase, and the final product is delivered to the client.
We also follow these stages in our approach, but the time intervals are shorter and the phases apply only to smaller parts of the whole system. Such phases are called sprints. During a single sprint, which usually takes two weeks, we are not able to implement all the functionalities of the application, only a part of them. After each sprint the work can be tested and submitted to clients for review. Most complex information systems follow this development path nowadays.
Clients are more hands-on with the project, they can quickly evaluate the application and give us feedback. While in the traditional approach they have to wait up to a few months to see an early version of the system, here the first functionalities are ready for testing within the first month. We continue the development if the client is happy, and include potential suggestions in the next sprint.
Let me use a system for traders working remotely as an example here. In the first stage we prepare a customer base that reps can freely browse and search. Even though it lacks several functionalities, it can still be used for instance for business correspondence. In subsequent sprints we implement the ability to create orders, view inventory, calculate transport cost for specific orders, view payments and credit rating. Each of these functions is a value for the users.
Many projects assume that clients know precisely that the application should do from the get-go. But when it comes to development, it turns out that this vision becomes less clear. Let me use the earlier example to illustrate this.
Along with the growing number of customers, the application should provide our client an easy way to find them in the database. The search can be implemented in many ways, from simple find by name, to sorting by various parameters such as time of last contact, the volume of orders (or recent lack thereof), customer location and the like. It is often not until users actually start to use this application when we find out their preferred search method. You can obviously try to predict it at the design stage, but life can surprise even the most experienced people.
Users report requests such as: „I use it quite often. It would be best to put this feature on the main screen. This should work differently” etc. Thus, a great advantage of working in sprints is the possibility to give applications to users and listen to their suggestions for further development.
We begin our work by defining a minimum viable product, i.e. a basic set of functions that must be implemented to allow the client to verify the business value of the product. Sometimes several Sprints are needed to achieve this.
It happened to us that the first version of the software was ready in a month. If this time is longer, it's good practice to prepare a working prototype that enables users to evaluate the proposed solutions. Although some functionalities may not work, the users will be able to formulate their initial opinions.
Feedback is very important. It is the cornerstone of agile methodology. When lacking such information we must create software guessing at whatever would appeal to the customer. This approach, however, is doomed to fail. Fortunately, customers are usually after efficient communication. It helps a lot.
Since it is difficult to say how much the project will cost, a very detailed specification is needed. However, the cost of creating such specification may actually be bigger than the cost estimation error of agile development project.
Whether it is business or any other relationship, building trust is important. The provider must earn it. It is difficult to take it for granted, especially if the client has bad experience working with other companies. We often started working with very limited trust, but ultimately managed to earn it with time.
Additionally, agile methodology allows clients save money on useless, from their point of view, detailed documentation which would still be subject to change later on. Instead, the client can oversee our work and receive the first version of the product. There is no need to make any assumptions, the clients can see for themselves we are able to deliver exactly what they need.
There is always time for that. Otherwise, error correction costs too much, and may also compromise our reputation.
We test our software in various ways. We like automated testing: we test in this way the individual functions in the code, as well as all the functionality. Think of it as a machine testing our application: clicking all the buttons and navigating through the screens. For some of the projects we do, automated tests are so complex that they take all night to complete. But when we come to the office in the morning, we can immediately see what needs to be improved.
Of course, even the best automated tests will not replace our invaluable testers. Their extraordinary inventiveness allows to detect issues that no programmer or machine would otherwise pick up.
Traditional methods make sense for clients who know exactly what they want their product to do and can not afford continuous availability at the meetings. They would rather come back when it's ready and receive a complete system, developed exactly to their specifications. If, however, at the stage of making assumptions there were many concerns in the project team, you may want to consider agile methodology instead. Then most of the concerns will be settled during the development, with the participation of end users.
Each of us works a bit differently. Some of us work on huge 30-inch monitors. I work on a laptop, which is just fine for me. It is often said that IT people would rather read an email from you that speak to you. While I understand some people are busy and don't like being distracted, I personallly love to talk and definitely prefer a little chat to e-mails.
Anyway, conversation is an important part of the methodology we use. We meet every morning to discuss the tasks for the day: what has been done, what obstacles are impeding the progress, and what we should focus on and do today.