Are you agile enough? How do we measure agile? Are you agile when you implement the practices of an agile methodology? Are you agile when you have daily stand-up meetings? With these questions, Dejan, our colleague and friend, started his presentation “Road to Agile Transformation” at this year’s Code Camp conference.

The event attracted a record number of more than 1000 attendees. CodeCamp provides high-quality content across 4 different stages. This makes it really hard to choose which presentation to attend. For that reason, we decided to give you the highlights of Dejan’s presentation. In case you were not able to be there or simply want the ”juicy” insight summed up ;), continue reading.

At Singular, we always strive for improvement. This goes equally for the software we create, as well as for the people we develop. Dejan Dimitrovski leads the Sportsbook team in the role of Product Owner. The team has grown from 8 to almost 30 people in the past three years. These people have created software that has been repeatedly nominated as one of the most innovative software in the iGaming industry.

Along the way, we implement the agile principles, but we adapt them to our team dynamics and product needs. They originate from the 12 principles of the agile manifesto with few modifications.

This is our agile story.

In agile environment, you must have clarity above all else. For that reason we have a very structured nomenclature for our releases. In practice, each release has major, minor, patch and build element. In other words, its name and surname.

First, it enables the team to have mutual understanding on already developed taxonomy. Second, it facilitates growth. This results in better client support by providing shortest possible time to provide production environment’s patches.

The differentiation factor of the agile methodology is that delivers small pieces of working code with a business value. This way you get constant feedback and adapt accordingly.

At Singular, we have first line of support that process all the requests from the clients in a form of tickets. They are all centralized in the JIRA service desk. Afterwards, delivered to the development team in a more detailed form. Finally, the tickets are assigned to different members depending on their urgency level.

This way we avoid unnecessary interruption and defocus of the development team.

To maintain the agility in your work, you need constant collaboration of the team. Each request from the clients is analyzed through the prism of the market trends and demand.
While the Product Owner and the PMs are the first line of communication with the clients, the team insight also matters.

Given we use JIRA as a ticket aggregator, Confluence came as a natural choice for continuous collaboration. The good thing about Confluence is that it makes every request and document available for every team member. Teammates can easily add their comment and feedback. Moreover, we try to give a visual concept of each request. The Team uses wireframe/mockup tools that provide a better visual understanding.

We design each feature in several delivery phases. This way we get fast feedback for continuous improvement.

Scrum didn’t work for for us from the very beginning. WHY?

We work with our clients on a revenue share based model. This mean, when they make money, we make money. For that reason, when the client makes a request for financial improvement we can not wait until the next sprint to make a delivery.

The Kanban approach makes the process very straightforward. We have a list of issues in our Backlog, but instead of scoping and planning a sprint for the following 2–4 weeks the question is: What is my priority for the day?

In agile development, constant collaboration can be the make or break for the success of the team. When you work in a distributed team, constant collaboration may not happen by default. You have to build the “communication structure”. The tools will be your solid ground.

We use JIRA as a centralized point for issues and Slack for day to day communication. You can read all about the process we have developed within these tools in one of our previous blog post: “The hidden gems of JIRA, Confluence and Slack”.

The Sportsbook team can make a release in a couple of hours, but prior delivery we have to test it. Your testing process MUST NOT take more time than the actual build. To maintain your agility you must be agile in every part of the process.

Our QA team has worked very diligently to develop test automation, while our Dev team has developed Unit and Integration tests. Read the details in our previous blog post:

“Technologies for automation testing – Our Story”

The one test to measure the success of your delivery is performance and load testing. We create software for millions of users. Moreover, our software deals with real money. For that reason, load and performance testing becomes one of our highest priorities.

Agile has its risks. The catch is to keep an eye on technical quality. Every code has its own technical debt. The teach lead must pay attention and pause the speeding car when needed to address the technical debt. Your auditing must be repetitive.

Want a happy client? Continuous delivery is not enough. Clients want to feel involved. That’s the purpose of Product Owner in case there is not direct involvement of the Client. It starts with the Strategic Roadmap, where we add the feedback from the market to finalize it with release. During the whole cycle we are in constant communication!

For that purpose, we created the Release Notes (RN). The RN communicate every update with our clients. We use the PowerShell Script, to sum up, the RN for a specific update. For bigger updates like the implementation of a new feature, we create RN in a more narrative form. Of course, the clients request for a more informal communication as well. This happens on weekly basis and covers the progress made on the road map. Moreover, provide insight into what the clients can expect in the following release.

In agile development, your team is as strong as its weakest member. You have to act as one team. The individual commitment translates into team commitment.

We have a rule: There is no back-end, front-end, QA team, we are all Sportsbook. We all work together to create the best product. Each member has a crucial role, each contribution matters.

Bottom line, agile is about continuous improvement. You don’t implement agile overnight, you don’t rush the process, you don’t jump steps. You start, test, adapt. There is no silver bullet.

It is not about the methodology, but the mindset. Your team has to transform into an agile state of mind.

In agile you don’t know what you don’t know. That is the beauty that makes the ride exciting 🙂

Presentation slides available HERE.