Innovation Requires Freedom: Experience With Agile Development
The product creation approach, simply referred to as agile, dramatically reduces time-to-market. In addition, in spite of the looser rules, it paradoxically improves control over development. But corporations must step out of their comfort zone.
At UniCredit Bank, they recently faced a difficult situation. It was four months until the start of the main sales season, and the expected new product was still in its infancy. It was clear that there was no way to complete it with the traditional way of management. The classic waterfall model requires a detailed description of all steps and functions, internal alignment of the business specification and its transformation into a development specification. It goes on for weeks before anything happens at all. Therefore, it was decided to try the path of agile development in cooperation with Trask. Agile allows you to start working very quickly on the first tasks and to prepare a more detailed task “on the fly”.
“Instead of a detailed technical specification, we initially had a simple definition of success – delivery on time and customer satisfaction. We agreed on a fixed range of functionalities, but the details were refined during the course. While development worked on one part, the others were preparing. The key was the establishment of the team and its mandate. In agile development, one or two decisions cannot be waited for one’s decision, so we have named key competencies and assembled the implementation team accordingly. We set the rule of decision within one day, ”says Eva Juhásová, Head of Multichannel Sales at UniCredit Bank Czech Republic.
Working together instead of waiting for a result
In agile development, the supplier and the client are in a very close relationship and operate within a joint team. Its members are in everyday contact when solving individual tasks, so it is necessary to have suitable tools for online cooperation as well as a dedicated meeting space. As a result, the advertiser sees the developers ‘hands-on’ so that they have an overview of the progress of the work and the quality of the product, and the product creators looks the client in the eye, which allows effective management of expectations.
They can also constantly verify the degree of mutual understanding – as the saying goes, the developer’s worst sentence is “I thought”. And because the whole team shares a single measure of success and definition of a goal (e.g. a certain number of sales), business and IT goals do not break.
“The right partner is half the success. With agile development, it becomes almost life partner. You have to rely on it, so you should have the same interest and ideal to work long term. Trust is truly essential, not everything is on paper and often the deal is just oral. Of course, it has its disadvantages as well – our lesson is that documentation must be created on an ongoing basis. We left it in the end and it was hard to include all previous agreements and decisions. But still, the software is superior to the ornate documentation. Even so, the project fulfilled our expectations in terms of quality and speed of delivery of a functional solution,” adds Juhásová.
When speed is crucial
Česká Spořitelna was the first to come to the Czech market with a fully on-line loan without papers, but it could be too late to rely on traditional development methods. Instead of the scope of the work, only goals were defined at the beginning, but promises were made instead of documentation. Therefore, Trask and EY had to come up with a new way to deliver the product to the customer. In these cases, different alternative business models can be applied – success fee, risk sharing or exclusivity.
Contrary to the full-scope order, only the final goal is entered, everything is redundant and no secondary things are done just because someone has entered them into the documentation at the beginning. “The motto of agile development is: success is when we don’t have to do anything. An important aspect of the agile approach is also transparency and close cooperation of the whole team,” explains Jiří Soukeník, one of executive directors at Trask.
It is also important to note that the agile approach can be combined with a waterfall model. If an exact assignment is available for some technical subcontracts, there is no reason not to use it. And where there is room for innovation, then agile is applied. In addition, the product team rarely gets all the necessary competencies and from time to time it has to rely on the work of other “non-reactive” departments or suppliers. Then we have to plan the dates well, arrange for the transfer of benefits. External dependencies must always be addressed first to allow sufficient space for synchronization.
“Based on a solution to one problem and a specific product, the whole platform, the concept for other digital products, was created. People have learned to communicate and collaborate, their internal settings have changed. We have discovered new digital processes, but also the ability to learn from and react quickly to failure. We were able to project the feedback from user testing into the product on a daily basis,” says Lukáš Pudil, Head of Digital Sales of Česká Spořitelna.
Planning and measuring an agile project
Agile delivery can also be seen through project management. The basic time unit with which SCRUM (one of the most popular agile methodologies) works is sprint. It usually lasts from two to four weeks and begins with the planning of a specific task for which sufficient assignment is already available. It ends with a functional “product” (application) that is presented to the customer. Sprints are repeated on a regular basis during the development of the entire product, which can be used to optimize work – in each successive sprint, lessons can be learned from the previous ones and are continuously improved. “Today’s development is like shooting a moving target. The project is always full of obstacles, you need to learn from mistakes and adapt. As the agile development takes place in a small team, team dynamics and a tightness that will not come immediately is also important. For example, if you add a new member in the course of a project, it may slow down the team’s efficiency instead of increasing it for a long time,” says senior project manager at Trask Petr Fanta.
Repeating sprints always have the same length, which allows you to estimate the scheduled completion date – it is evaluated whether the team “sprints” fast to the goal. Optimistic and pessimistic scenarios can be modelled on the basis of the remaining work and the speed of the individual sprints, and corrections can be made. However, companies must not forget that the process does not end with the supplier’s delivery. The product has been used in accordance with agile principles since the so-called minimum version, which is usually further developed and enriched with other functions. Accordingly, space and money needs to be planned and prepared for further development, as the basic product will not satisfy customers for long.
While it is possible to jump into the agile train, ideally, agile access needs to be reflected in the architecture and planned from the beginning. While the established model of development works in layers, which are dealt with by separate teams (business, applications, data, presentations…), in the agile these layers are connected to verticals, functional units.
Martin Pitra, solution architect at Trask, lists five principles of agile architecture that are good to keep from the beginning as follows:
Breaking down into verticals. An architect must have a top view, know business connections and dependencies (business analyst consultations). It doesn’t start from technology, but from above.
Consistency principle. Similar assignments should be addressed in the same way for all verticals. It is necessary to reject the tags and not put in the application temporary solutions that will usually remain there.
Directness. To design things just got complicated, so go to the heart of the problem. This brings a faster and more intuitive implementation. The code is supposed to mirror a given problem and not try to solve things universally excessively . Let us not anticipate the future in the design – we will not miss anyway and we will only make more complicated solutions.
Stick to assumptions. When designing changes, one has to think about whether we are moving on the original assumptions. Customer needs to be alerted to requirements that are beyond the original framework and require a technology change.
Completeness of information. The architect must have enough information to propose a solution to the vertical. This is based on approved and defined assumptions.
Agile is about people
In the mentality of an agile approach, we cannot talk directly about mistakes. If a move fails with a 100% result, it will certainly be the source of a valuable lesson for the next steps. In general, we consider our customers the greatest challenge to coordinate a large number of teams working on a wide variety of products. “The greatest potential and even the greatest weakness of the transformation is surprisingly hidden in the organization’s people and its teams. Future results will depend on the correct direction of their energy”, summarizes Jiří Soukeník, Executive Director Trask.