It’s all about risk - are you ready to partner with a company or simply add external people to your organization and expect this to scale well. Are you already doing agile software development or are you looking for ways to get there?
Аs a solutions architect at Qaiware I am constantly involved in customer workshops on product architecture and delivery. And yet, as strange as it may seem, I still find it challenging to describe what we are doing and why it actually works for our clients.
Oftentimes, companies view us as the next outsourcing house with a focus on payments. Although partly true, it does not represent all we bring to the table.
The value in question lies in our approach to software delivery. Our strength and what really pays off eventually, is doing agile software development through “autonomous teams”, which differs greatly compared to traditional outsourcing.We are a small, highly specialized development company, working with large scale corporations. Our clients are used to outsourcing and near-shoring, in other words allocating external resources that are governed by a client management body.
And therein lies the challenge - when you have a complex hierarchical structure and you want to do Agile development and delivery, you usually end up doing a form of waterfall( a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one).This is not necessarily bad, but did you start off with that idea in mind?
Avoid Quick & Dirty
What usually works best in these situations is to take a structured approach and avoid a rushed and hectic start, or “quick and dirty,”, as we call it.
Normally, we conduct one or two workshops with our clients, where we identify specific needs, challenges they face - business or technological, and what is the best way to approach them.
These workshops are usually followed by an updated project roadmap, where a major topic becomes the software delivery model and of course the commercial aspects. Putting the sales part aside, lengthy discussions always revolve around how we can set up an autonomous team and deliver. Or better even, what does an autonomous team look like and why should the customer go down this road?
So, Why Autonomous?
It is important to set up the software development in an agile way with clear stakeholders and a goal that is propagated right to all participants. A great way to achieve that is through autonomous teams.
Autonomous doesn't mean independent - it means that all dependencies are clear, that each dependency has an owner, that we can foresee what could hinder the way of the delivery machine.
This is exactly the analysis that is being done by Delivery Managers, Solutions Architects and Business Developers during the course of the aforementioned setup workshops (not to be confused with a scope lock! Locking a scope is the step before doing waterfall).
All these steps are aimed at achieving an organization setup that is tailored for the software product in question, which is to be executed or partially executed by an autonomous team.
What’s The Team Structure and Dynamics?
When the setup is complete, we start ramping up the team in gradual steps:
1. A Product Owner and a Delivery Manager start working on the product roadmap and delivery processes.
2. We conduct internal consultations with our architects on what the software design should be and a System Operator usually starts to build the necessary infrastructure like CI/CD pipelines, provisioning and orchestration.
3. Gradually we reach a full operational team that consists of a Delivery Manager, a Product Owner, Back-end developers, Front-end developers, QAs and System Operators.
This sounds a lot! It certainly is, still this is the only way to achieve autonomy of the software development. Then the delivery of the actual software will be handled inside the team.
How Does This Team Fit in the Clients’ Organization?
How to set up autonomous teams in complex organizations? The answer lies in the roles!
The Delivery Manager and the Product Owner are the roles that are mostly exposed to the key stakeholders, to the external dependencies. They are there to make sure that the software product serves its business purpose, designed in the best possible way and to handle all ongoing issues. Everything else - development, quality, infrastructure is handled within the team itself only. This doesn't mean a black-box. Quite the opposite - the team maintains full transparency of all tasks at hand and welcomes any feedback but it is self sufficient in performing its basic duty - to produce software. With this gradual approach a team reaches full velocity with very few iterations and starts to deliver the software with high quality and in short terms.
So what do you get with an autonomous team at the end - a delivery unit that can live up to its name and deliver continuously, in a measurable and predictable manner enabling the organization in which it fits.
This may be achievable through traditional outsourcing as well but your organization should already be agile, ready to scale, with a product and managerial know how that is close to absolute.
Surely this all sounds like a software and managerial Utopia. However, I assure you it is possible when you know your tools and most importantly when you have a team of great engineers that are used to doing this and have the right attitude and experience.
