The magic word to define modern businesses would most probably be 'flexibility'. Now, large international organisations with a structure and working principles that might seem sluggish at first glance are trying to include flexibility into their routine as well. Some of these large organisations launch internal teams operating like start-up companies, providing them with more leeway and opportunities to experiment. On the other hand, these teams also have the opportunity to use corporate know-how and financial resources that start-ups tend to lack.
NorthStar, operating inside Danske Bank, is one of the examples. It only took our team six months to develop a car leasing solution which allows users to purchase a car in under two minutes. This solution is now successfully used in Sweden and will launch in Denmark and Norway shortly.
The project developed, which was developed by an international team, has not only given us valuable experience, it has also paved the way for a better understanding of what works best when developing a product or service and what does not. Within six months, we have proven the aptness of a well-known truth: the best way of learning is to learn from one's own mistakes. Most important then, is to find the right time to make those mistakes.
Lesson one: start testing as soon as possible
The development of each product consists of numerous steps. Experience shows that it is necessary to start testing from the very beginning. Early revision helps to prevent the so-called 'butterfly effect'. An inconsistency identified at the provisional stage can be resolved within five minutes, while, on the contrary, it might require a few days or even weeks when the system is already running. On top of this, everyone would have already forgotten the exact development circumstances if testing only happens at a later stage.
None of the modern technological solutions can do without testing. If testing is omitted at the early stage of the project, you would have to do this right before your deadline. And, as we all know, the day before launching a product, you will already have your hands full.
Last-minute checks not only require more human and technological resources, but they also increase the probability of errors. That is why it is essential to test even the smallest mechanisms throughout all of the stages of the product's or service's development.
Lesson two: global leaders are the best teachers
We had a tight six-month schedule at the beginning of the development of the NorthStar product, and we missed several things that needed to be revised. Sometimes we consciously left testing for a later stage. When we discovered that many details were not working, we had to work overtime. We swallowed a bitter pill and started to look for inspiration using the experiences of global companies. Using the best practices of Facebook and Google, we now implement automatic testing of new projects from the initial development stages.
Another lesson we have learned from Google and Facebook might seem contradictory with the market situation: these companies, as well as other technology leaders, do not have a designated tester role. They believe that every team member is responsible for the product being of excellent quality. As a result of this, the liability for testing is distributed proportionally to all team members, from the programmer to the sales staff.
However, while gaining expertise, it is not enough to only look into examples provided by global technology leaders. When talking about testing, we cannot ignore the most advanced testing tools that are being improved continuously. Some of these tools help prevent issues, while others offer answers to questions before they are even asked.
Lesson three: the more variety, the better the product
Testing is inevitable when developing intelligent solutions, but it is not necessary to have a separate testers team for this. I believe that a small team following Agile principles would only be interrupted in their work by specialists who sole job it is to do testing. This would confuse, rather than it would offer solutions. When each member of a small team is involved in all of the processes, less harmonisation and complex debate are required. Additional links can unbalance this structure, and a tester may feel like they are not in the right place.
If software developers are complaining about testing being a harsh procedure, they should be told that testing is an opportunity to improve, assess their skills and learn from their work. Moreover, when testing involves every team member, there are much more favourable conditions to create a better and more customised product or service. Testing should be explained to the team using feasibility terms instead of imperative ones.
It is also essential to have people responsible for business processes involved in product testing alongside programmers. This is the case, as having a diverse team is just as important as professional competence and personal qualities. This contributes to the development of a product. Elements that might be missed by one person do not remain unnoticed by others. The possibility to share competencies throughout an international team is even better.
While developing the car leasing solution, we remotely worked with Scandinavian colleagues. This not only forced us to refresh our English but also to use video conferences and start our morning routine with a review meeting on the couch. During the meetings, all team members who joined in on the teleconference reviewed product development's status, as well as any challenges and the tasks at hand.
Lesson four: correct estimation of the delivery time of the product
A frequently occurring situation: by the end of the workweek, someone from the business or sales department comes over to the programmers and announces the product should go-live on Saturday. The person in question here would be convinced that the solution will not be accessed as much over the weekend, so that any disruptions could be handled conveniently, without significant problems.
We followed these instructions only once. After launching any product, developers will need to remain vigilant and ready to tackle any problem at once. Weekends are the least suitable for this task.
Launching a digital solution is not the same as flipping a light switch: as soon as a product starts operating, programmers must monitor the first activities, collect feedback and remedy any identified errors immediately. We have learned this lesson on-the-job. That is why we typically launch our products at the beginning of the week. In that way, we have the entire week for monitoring the operation, and at the same time, we can respond to any problems without the necessity to work over the weekend.
Lesson five: trust automated solutions, but use your perspective too
Human skills and competence still back-up even the most advanced artificial intelligence and IT solutions. Although the vast majority of testing is already automated (Google has automated as much as 95% of the code testing), critical decisions still have to be made by a programmer or tester. It is necessary to maintain the link to reality, especially when consumer expectations for services constantly rise, and companies seek to provide the best possible experience for their customers.
The development of complex multilayer systems is bound to attract some failures, but it is essential that they also create added value. A random mistake is not a verdict; it should be seen as a lesson and a reality check. The awareness of such mistakes leads to the avoidance of similar errors in the future and, finally, the success of the developed product.
NorthStar, operating inside Danske Bank, is one of the examples. It only took our team six months to develop a car leasing solution which allows users to purchase a car in under two minutes. This solution is now successfully used in Sweden and will launch in Denmark and Norway shortly.
The project developed, which was developed by an international team, has not only given us valuable experience, it has also paved the way for a better understanding of what works best when developing a product or service and what does not. Within six months, we have proven the aptness of a well-known truth: the best way of learning is to learn from one's own mistakes. Most important then, is to find the right time to make those mistakes.
Lesson one: start testing as soon as possible
The development of each product consists of numerous steps. Experience shows that it is necessary to start testing from the very beginning. Early revision helps to prevent the so-called 'butterfly effect'. An inconsistency identified at the provisional stage can be resolved within five minutes, while, on the contrary, it might require a few days or even weeks when the system is already running. On top of this, everyone would have already forgotten the exact development circumstances if testing only happens at a later stage.
None of the modern technological solutions can do without testing. If testing is omitted at the early stage of the project, you would have to do this right before your deadline. And, as we all know, the day before launching a product, you will already have your hands full.
Last-minute checks not only require more human and technological resources, but they also increase the probability of errors. That is why it is essential to test even the smallest mechanisms throughout all of the stages of the product's or service's development.
Lesson two: global leaders are the best teachers
We had a tight six-month schedule at the beginning of the development of the NorthStar product, and we missed several things that needed to be revised. Sometimes we consciously left testing for a later stage. When we discovered that many details were not working, we had to work overtime. We swallowed a bitter pill and started to look for inspiration using the experiences of global companies. Using the best practices of Facebook and Google, we now implement automatic testing of new projects from the initial development stages.
Another lesson we have learned from Google and Facebook might seem contradictory with the market situation: these companies, as well as other technology leaders, do not have a designated tester role. They believe that every team member is responsible for the product being of excellent quality. As a result of this, the liability for testing is distributed proportionally to all team members, from the programmer to the sales staff.
However, while gaining expertise, it is not enough to only look into examples provided by global technology leaders. When talking about testing, we cannot ignore the most advanced testing tools that are being improved continuously. Some of these tools help prevent issues, while others offer answers to questions before they are even asked.
Lesson three: the more variety, the better the product
Testing is inevitable when developing intelligent solutions, but it is not necessary to have a separate testers team for this. I believe that a small team following Agile principles would only be interrupted in their work by specialists who sole job it is to do testing. This would confuse, rather than it would offer solutions. When each member of a small team is involved in all of the processes, less harmonisation and complex debate are required. Additional links can unbalance this structure, and a tester may feel like they are not in the right place.
If software developers are complaining about testing being a harsh procedure, they should be told that testing is an opportunity to improve, assess their skills and learn from their work. Moreover, when testing involves every team member, there are much more favourable conditions to create a better and more customised product or service. Testing should be explained to the team using feasibility terms instead of imperative ones.
It is also essential to have people responsible for business processes involved in product testing alongside programmers. This is the case, as having a diverse team is just as important as professional competence and personal qualities. This contributes to the development of a product. Elements that might be missed by one person do not remain unnoticed by others. The possibility to share competencies throughout an international team is even better.
While developing the car leasing solution, we remotely worked with Scandinavian colleagues. This not only forced us to refresh our English but also to use video conferences and start our morning routine with a review meeting on the couch. During the meetings, all team members who joined in on the teleconference reviewed product development's status, as well as any challenges and the tasks at hand.
Lesson four: correct estimation of the delivery time of the product
A frequently occurring situation: by the end of the workweek, someone from the business or sales department comes over to the programmers and announces the product should go-live on Saturday. The person in question here would be convinced that the solution will not be accessed as much over the weekend, so that any disruptions could be handled conveniently, without significant problems.
We followed these instructions only once. After launching any product, developers will need to remain vigilant and ready to tackle any problem at once. Weekends are the least suitable for this task.
Launching a digital solution is not the same as flipping a light switch: as soon as a product starts operating, programmers must monitor the first activities, collect feedback and remedy any identified errors immediately. We have learned this lesson on-the-job. That is why we typically launch our products at the beginning of the week. In that way, we have the entire week for monitoring the operation, and at the same time, we can respond to any problems without the necessity to work over the weekend.
Lesson five: trust automated solutions, but use your perspective too
Human skills and competence still back-up even the most advanced artificial intelligence and IT solutions. Although the vast majority of testing is already automated (Google has automated as much as 95% of the code testing), critical decisions still have to be made by a programmer or tester. It is necessary to maintain the link to reality, especially when consumer expectations for services constantly rise, and companies seek to provide the best possible experience for their customers.
The development of complex multilayer systems is bound to attract some failures, but it is essential that they also create added value. A random mistake is not a verdict; it should be seen as a lesson and a reality check. The awareness of such mistakes leads to the avoidance of similar errors in the future and, finally, the success of the developed product.
