Abnormal Agile in Finance

About the system

The company in which I work developed its own trading platform such as MTF. In this system, tens of thousands of trade operations are performed every second, and using the Disruptor pattern , the average speed of a trade does not exceed 20.5 milliseconds. The project involves the most complex integration with third parties - large banks, London Clearing House LCH and other corporations.

The development of the project took about 3 years and a team of about 20 engineers. There are no project managers, a coordinator, project plans, Gantt charts, architecture documents, requirements specifications, and testing plans.

In addition to awards for outstanding technology, the company is recognized in the Agile community for a simple and effective development process. About him I want to tell in this post.
')

About the process

The company uses its Agile development process. The development of the system never stops, and new customer requirements are regularly met, with a new release cycle every 2 weeks.

The developers of the company are divided into 3-4 groups, each of which is engaged in a certain direction. In each group there are 5-6 programmers, a tester and an analyst.

The work of all teams is divided into two-week iterations. The iteration begins on Wednesday, and ends after 2 weeks on Tuesday. The middle of the week is chosen so that it is not necessary to urgently finish the development on Friday, lingering at work.

Requirements for the new version appear mainly from customers, the marketing department and the sales department. All wishes are recorded on cardboard cards that are glued to the planning wall.

The planning wall is divided vertically into teams, and horizontally into iterations. The whole wall contains tasks for a quarter of a year, 6 iterations. New cards are glued to the top, and backlog is at the bottom. Between them - 6 iterations.

Every Tuesday, all interested parties gather near the planning wall and re-glue the cards according to priorities, thus planning the next iterations. Usually in the iteration of the team is 2-4 cards.

The analyst collects detailed requirements for the cards of the next iteration. Requirements are recorded in the Mingle system. A regular card contains 5-10 acceptance criteria, in the form of sentences such as “If the trader has set the size of the order, it should be kept until a subsequent change”

About work in iteration

Every second Wednesday at 10 am a retrospective and kick-of of the next iteration begins. The teams scatter by rally-rooms or sofas (who didn’t have enough), and start meeting with eating the cake.

In retrospect, the team discusses what was good, what was bad, what questions and ideas were. To do this, the board is drawn in 4 segments, where the assigned volunteer records the reasoning of the team members. The goal of this exercise is to come up with improvements for the next iteration.

After the end of the retrospective, a rotation takes place, as a result of which each team loses one developer and acquires another.

Then begins the analysis of new stories, where the analyst tells about the plan for the next iteration. Developers ask questions clarifying requirements.

Cards are moved from the planning wall to the kanban wall for this team. The kanban wall is divided into tasks - horizontally, and status - vertically. The first column contains all non-commented tasks. The following columns occupy the started card, then “in progress” and “finished”.

The development of a story begins with breaking it down into subtasks. The whole team gathers in the kitchen, and on the sticky sheets splits the card into subtasks. Often at this stage a solution is designed - for this we use a white wall and multi-colored markers. Adhesive sheets go to the kanban board in the “Started” section. The first and second tasks are selected, with a pair of engineers for each.

Usually the first task is to write tests. This involved a couple of programmer and tester, tester and analyst, or analyst and programmer. Tests are written based on acceptance criteria.
All tests are executable specifications. Tests are a direct part of the system code, and participate in a continuous integration (CI) environment. At the moment we have about 20,000 tests, and each commit is subject to automatic testing against these tests.

Direct development always happens in pairs. Most often, 2 programmers are involved in the development, although it is often a combination that includes a tester or analyst. As a result of pair programming, the quality of the code is improved, the knowledge of the system is disseminated (excluding the need for documentation), and more correct decisions are made.

In addition to “mating”, we use “swarming” - the development of one story in several pairs at the same time. Some make the user interface, others meanwhile - the server side. Since the breakdown into subtasks and design was done by the whole team, everyone knows what to do.

A constant rotation also takes place in the development - the pairs converge and diverge, change tasks. As a result, everyone knows everything, and the need for individual review of the code disappears. In addition, confidence increases and relationships improve in a team, because it simply works as one organism.

Changes are constantly being sent to SVN, where they are automatically tested.
Theoretically, the system is ready to run at any time. In the middle of the office there are monitors showing the status of testing, speed of execution, latency and other parameters.

Such a development process, which is not typical for financial institutions, is used in the London Diversified Asset Exchange (LMAX). All planning is exposed on a general review, each developer knows work of all system and practically each specific function. As a result of “pairing” and “crowded” specifications are not needed, there are no conflicts between different parts of the organization. Everyone can always offer a new solution, having familiarized with the “wall painting” of the neighboring team. Documents are missing as a class, e-mail is almost never used. There are no decision committees and boring meetings discussing plans ...

By the way, we always need talented testers and Java programmers.

PS work in London