Working with Agile methodologies and practices is natural for CARDO AI. Traditional business strategies, project planning methods, and workflows cannot work for the needs of our team and customers. In this article, we will discuss Agile Working, its roots, and how this methodology fits into CARDO AI.
Why Agile working?
Our Agile way of working is deeply linked with our history, impact makers, and contributors. But before we move further to examine these aspects, let’s stop for a bit to discuss what Agile working is.
Many consider management to be the most important invention of the 20th century. After all, it is through management practices and techniques that many of the advancements in technology and life’s comforts are extremely reachable for us today. Management practices were particularly refined in manufacturing during the early part of the 20th century to ensure easy replicability of processes to lower costs and improve the quality of production goods.
But soon, evidence management born out of production lines found it hit limitations when dealing with a new breed of problems (complex problems), especially as we became more exposed to increasing digitalization (and softwareization of products).
This led not only to new ways of organizing work, giving rise to decentralization and the law of small teams, but also to look at the whole production process in a completely different way.
Main characteristics of Agile Organizations
Instead of Time, Budget, and Scope, Agile organizations focus on User Needs, Business Viability, and Technical Complexity.
Let’s start with the very first and basic requirement: is there a user need, a problem our product could solve for the customer? There are many and various techniques that can be utilized to deep dive and answer this question, the most famous being design thinking and JTBD (Jobs to be Done). The outcome of this phase should be to frame a problem and from there on evaluate the window of opportunity.
Once this is done, two concurrent questions are asked by the Agile Team: Now that we have our problem framed and opportunity statement written, how viable is it to build and maintain this solution? How are going to sell it and what customer engagement practices will we need to implement? These and other related questions all fall under the realm of determining the business viability of the product. Furthermore, the team also looks at the technical complexity associated with building said product to explore the opportunity: What technology is it going to be built upon? How many moving parts would there be? What type of skills are required to shape the opportunity? These and other related questions fall into the realm of technical complexity.
Once Agile teams are able to answer these questions, they will generate scalable value at the intersection of the above through enablement and continuous improvement of their teams.
Three basics of agile values
Agile ways of working honor the heritage of Lean manufacturing and are proponents of the division of work in smaller chunks, delivered in cycles (usually called sprints), in order to experiment and improve through incrementation rather than by being submerged by complexity. By delivering this way and having the incrementation ready by the end of the iteration, the customer is able to immediately validate the user story and respond if the development serves them to complete the intended purpose.
Furthermore, Agile organizations and Agile ways of working scale through decentralization, breaking up teams when they become too big into smaller teams. This is done while still remaining evidence-based, purpose-driven, transparent, and fostering collaboration. More importantly, the feeling of ownership across the teams is what leads contributors to materialize accomplishments.
At CARDO AI, these ways of working are reminiscent of our start, where a small team with a vision worked tirelessly to transform a concept into building a prototype, measuring impact, and learning from feedback. We started at CARDO AI with a group of 4 employees and the mission to revolutionize the private debt market. We designed the first MVP and tested the idea with key experts from the market in order to have a validated concept. Only after that, do we get to work on the actual product.
“It was a challenge as there was a lot of uncertainty, ambiguity, and excitement. We were working on something that did not have a benchmark to compare against in the market. But that provided an extreme motivation and great vibe within the team at the time. This enabled us to ship very fast desired features and have the customer immediately validate or takedown. When validation occurred, that was like fuel for the team to deploy even during late hours. Every validated feature felt like a giant step forward towards our vision, and it was extremely relieving” – Elitjon Metaliaj, Front End Team Lead.
The importance of framing the problem
As a proponent of software solutions, we strive to clearly frame the problems we are trying to face and define measurable indicators to match our progress against. We aim for our goal setting to be direct and to attract commitment of all involved parties. Furthermore, framing allows us to see the various interdependencies, therefore giving creators an opportunity to think on a bigger scale all the time.
Contribution from everyone
After defining the problems, we are committed to include all creators to have a say on how we solve the problem at hand. Responsibility on the backlog items (writing and execution) is not distributed due to authority or seniority, but is welcomed by all creators. Quoting world renown author Haruki Murakami, “If you only read the books that everyone else is reading, you can only think what everyone else is thinking.” This is not the type of professional culture we would like to transmit to our co-creators.
A culture of constant feedback and evolution
Updates and designations are then defined by the various team members as the process iterates through the various sprint feedback loops (Planning, Stand Ups, Refinement, Reviews, Retros). Each feedback loop serves the team a different purpose, where the Planning serves as the base camp fitting people with the maps and tools to tackle the goal of the sprint, the Stand Up aiming to answer the question of what the next step would be for each member, the Refinement serving as a flow direction controller based on progress and outlook, the Review as a feedback collection moment from the customer and a snapshot to base the forthcoming Planning upon.
Last but not least is the Retrospective, where the team is ensured a safe space to stop, take a deep breath and reflect on the interaction, behaviors, tools and processes observed and utilized during the Sprint, how they made them feel, what to retain and what to change.
Continuous Experimentation
Therefore, we are able to divide our effort in smaller chunks and get to experiment on our hypothesis for the length of the sprint, giving ourselves the opportunity to be truly evidence-based for future iterations. All in the sunlight of transparency!
We aim to further enforce this even more through our shared Review activity, where all teams report on their progress during the last sprint, making sure every member of the organization is aware of what colleagues are trying to solve each iteration and sponsoring further interactions across various teams to quench curiosity and foster more learning and collaboration.
Conclusion
All in all, we believe this way of working has enabled the full participation of all our co-creators in the organization, which in turn has made highlighting, framing, and solving problems an inclusive and thorough activity in our organization. As our size and ambition grow, so does our awareness to examine our agile ways of working and evolve them to the context and needs of our co-creators.
After all, what value does it serve to preach continuous improvement if we aren’t the ones to first enact it?
If what you read appeals to your curiosity, why not get in touch with us? Whether inquiring about an open position or just willing to have an introduction, we would be glad to have a chat. Find our contact points at our website, www.cardoai.com.
About the author
Rubin Haxhiymeri – Product Delivery & Growth Lead
Rubin is a certified Digital Transformation Specialist and System Coach with 9 years of work experience across different transformation journeys in the industries of Telecommunications, Multimedia, and Fintech. Rubin’s main interests include strategic marketing of technology innovation, positioning of the value proposition as well as building autonomous teams for the development, delivery, and longevity of tech products in the market. As a preacher of patience and continual improvement, his favorite phrase is “Do not boil the ocean.”
