Continuous Reliability – Key Takeaways
Last Saturday, we took part in the annual JavaSkop conference. Our teammate Dejan talked about continuous reliability as key for success with agile. In this blog post we give you the KEY takeaways from the presentation structured in 12 principles that created value for our team (slides available at the end of the post).
1. FOUNDATIONAL PRINCIPLES
Singular offers enterprise software as a service for developing sports betting solutions. To maintain our on-time delivery and quality we MUST have:
- Versioning standard;
- Aligned versioning and branching strategy;
- Dedicated environments for development, testing, staging and production;
This way, the product life cycle is absolutely clear from development to production. The versions have a structured nomenclature, every number in the name has its weight. Once the version has a build we promote it through the promotion pipeline.
This is the foundation of our agile processes.
2. CHANGE IS CONSTANT, SAME FOR TECHNICAL DEBT
In agile, change is constant. And since the features are evolving over time, no matter how good your intentions are, technical debt is inevitable. However, keep your strategy aligned all the time with the change – create roadmaps. Map everything including your debt!
The strategic roadmap covers a period of a year from a C – level perspective.
The tactical roadmap covers the priorities for the next 3 months.
The creation of the roadmaps MUST take input from:
- C-level priorities
- Client’s requirements
- Product analysis outcomes
- Competition analysis
Every point on the roadmap should have its own specification
3. FREQUENT DELIVERABLES OR QUICK PATCHES
We started using Scrum, but it didn’t work for us. Our business model is revenue share based. For that reason, it is in our best interest our clients to make money. This means that when the client makes a request that would imply a better financial performance, we can’t say: “Sorry, we are in the middle of a sprint. That is unheard of.”
For that reason Kanban was a better fit for our team dynamics. With the Kanban methodology, instead of scoping and planning a sprint for the following 2–4 weeks the question is: What is my priority for the day?
To get a better understanding read “Why we switched from Scrum to Kanban”.
4. THE METHODOLOGY IS JUST A GUIDELINE
Even with Kanban, we had to make some modifications. REMEMBER, the important thing is to bring value to your team and product. Don’t adapt the team to the methodology, but modify the methodology to fit the needs of your team. The ultimate goal is to improve the performance of the team.
5. UX FIRST APPROACH, ELIMINATE SURPRISES
We create a complex software handling billion transactions per month, several thousand users at the same time. To maintain on-time delivery together with a stable solution, the team MUST be aligned, no question about it.
Having a transparent and collaborative process in place is crucial. We use Confluence as a central repository for all requests and documents. Teammates can easily add their comments and feedback to any document at any given time. Moreover, we try to give a visual concept of each request. The team uses wireframe/mockup tools that provide a better visual understanding.
6. CONSTANT BUT SMART COLLABORATION
Communication is not about being involved in every chat or minor consultation. Shut down Skype. Skype is ruining your productivity. For effective communication you need structure, you need a tool to map your team. Use centralized tool for management and link all reported issues and operational ones – collaborate on each of them. And for everyday’s communication we decided to use Slack, and here, we’ll highlight only some of Slack’s features that make our collaboration more effective::
- Slack Channels – create a dedicated channel for each project. Helps eliminate unnecessary distractions;
- Turn off notifications for a specific time or particular channel;
- Slack bots – automate some operational activities;
- Numerous Slack Integrations;
In a previous blog, we go into detail how we use them to keep our team focused and productive.
7. ALWAYS A STABLE AND PERFORMANT SOLUTION
We deliver a patch every week. In case of a critical issue, we deliver in a couple of hours. This pace of delivery requires automated testing process. Agile refers not only to the development, but also the testing and deployment aspect of the solution. For that reason we have developed regression, Unit and Integration tests. For that reason we have developed different kind of tests unit, integration, regression, load and performance, data consistency tests.
We have even created a custom-made Singular testing framework based on Java utilizing several technologies.
8. CODE QUALITY IS ESSENTIAL
We create software for sports betting which means the solution handles real money of million users. The solution at any time processes huge amounts of data that must be consistent at all times. The performance of the code in the production is not up for question. To ensure high performance of the code in the production we perform load and performance testing.
More details in “Technologies for automation testing – Our Story”
9. COMMUNICATE BACK ALL CHANGES
Communicate with the client on more than one level, have multiple ways to get and provide feedback. We have both, formal, structured channels and informal, ad-hoc sync meetings with our clients:
- The JIRA Service Desk is our first line of support that process all the requests from the clients in the form of tickets. Next, if needed, the tickets are assigned to different members of the development team depending on their urgency level.
- Technical Release Notes communicate every update with our clients. We use the PowerShell Script to sum up the RN for a specific update.
- Narrative Release Notes for bigger updates like the implementation of a new feature where we explain the business benefits as well, not just the technical details.
- Ad-hoc updates on a weekly basis to record progress made on the road map and sync about the following release.
This way, you and your client have a clear idea of the software’s current progress and future realistic expectations.
10. POWER TO THE TEAM
In the end, the success depends on the team and how well the members work with each other. We have three golden rules that we believe empower the team’s work etiquette and dynamics.
- Constructive criticism is welcomed from anyone on the team regardless of seniority level. Every discussion is a learning lesson and creates the potential to improve the product.
- In addition to all the tools and apps we use for higher efficiency, physical white boards are our space for brainstorming.
- The last, bud definitely not least rule: We are ONE team. There is no back-end, front-end, QA team, we are all Sportsbook. We have a shared goal, a bottleneck in one part of the process hurts the reliability of the software as a whole.
11. WHAT ABOUT THE DOCUMENTATION
Documentation may be the most dreaded word in development. Yet, you cannot function effectively without it. Don’t spend too much time, but dedicate time for solid documentation. Remember:
- Your software must exist a long time after you
- Documentation eases and speeds up the on-boarding process
- Documentation is useful for all stakeholders
- Documentation is an overview of the decisions made
- Helps the support team to handle reported issues more effectively
Confluence has made the creation of our documentation smooth and straightforward.
12. CONTINUOUS IMPROVEMENT
In agile, there is no one size fits all solution. You have to continuously work on improving the process to maintain a high level of reliability.
Start with the obvious. Place tools and process in place. Make sure the use of them becomes the team’s practice. Over time, the practice itself creates principles and values. But be patient and consistent. This is KEY.
The final outcome is a learning organization that is dedicated to continuous improvement.