For years, the DevOps culture is becoming a standard and more and more companies are turning to this Agile model. Is this method suited to IT services companies, which have traditionally been involved in outsourcing?
Once this culture has been adopted, we realise that there are a number of drifts, particularly in terms of deadlines and costs. What seems obvious on paper doesn't necessarily work as described: often used in the context of a product, it's sometimes difficult to get your teams and organisation on board when you're delivering a service or when all the tools and skills aren't already present in the company. What's more, this paradigm shift can be costly in terms of building the most effective ecosystem possible.
The strong acceleration of the Public Cloud has made this culture even more important: better 'time to market', the benefits of CI/CD and the 'on demand' infrastructure are now essential if we are to remain competitive, experiment quickly and deliver faster.
However, we are now seeing a clash of cultures between ITIL and AGILE. Both have their advantages and disadvantages: while ITIL advocates change control and the mastery of dates, AGILE emphasises iterative processes, experimentation and speed of implementation.
By adopting an agile approach to IT outsourcing, we identified risks and slippage in the schedule. The argument: "You understand, dear customer, we can't finish the project on time because the user story has slipped into the next sprint" is hard to take...
Cloud Temple's historic business is hosting in Private Cloud mode and facilities management to ITIL standards. Public Cloud and software development skills have since been added.
Naturally, we had to transform our organisation to find the best balance. As our Public Cloud technical experts are DevOps people, they are 'inherently' agile.
Towards a hybrid organisation
To carry out this business transformation and combine DevOps with respect for our customers' constraints, we, like many others, looked to the well-known Spotify model. After analysing their organisation through the many articles that exist, we realised that the vast majority of the elements could be used in our context, but not without major adaptations.
We also wanted to remain agile, but limit the number of processes, meetings and tools. So we turned to Modern Agile which consists of purifying "classic" agile to focus on the values of this methodology.
Our organisation is therefore based around squads, guilds and a single project management tool: Azure Boards.
Cloud Temple squads
As real centres of expertise, we have chosen to group all our experts into strong, autonomous teams that are self-managing on the technical side. As a result, each Public Cloud Provider (Azure, AWS, GCP, Alibaba) has its own dedicated squad whose members progress together, helping each other, challenging each other, reviewing each other and sharing their knowledge and experience as projects progress.
Squad roles are well defined: architects, builders, runners. But the proximity of the people involved and the fact that they work together means that information and knowledge can be shared on a daily basis, so that everyone can make progress. In this way, we have created a real team spirit and solidarity with a common goal: progress every day to constantly improve the quality of our service.
Of course, the breakdown of activities is clear and we know our capacity to produce each month. Nevertheless, this proximity means that runners and builders can contribute to the architectures. In the same way, our architects and builders know that they'll be doing escalation runs. Visit breaking down barriers and helping each other have become fundamental values of our culture.
Guilds, the guarantee of conformity
Each expert is therefore part of a Squad that takes up 80% of his time to support our customers in our various services. At the same time, each expert is also part of one or two guilds that take up 20% of their time.
As a result, experts from different squads (Azure, AWS, etc.) work together to contribute to the standardisation, documentation and improvement of the structuring technical elements that will serve all our customers (monitoring, backup, templates, containers, industrialisation, etc.). This time is managed by each member of the team in a totally autonomous way, depending on the customer's project; we felt it was essential to guarantee the quality of the standards for the most structuring elements and to encourage a continuous improvement approach.
Each guild topic is implemented in the same way for each of our customers. This simplifies and optimises the build phases, drawing on the standards produced by the guilds. The run also benefits from these best practices, because the implementations are uniform from one project to the next.
We work in four-month iterations, with a kick-off to establish the objectives of each guild and the value it will bring to the company. A backlog is drawn up with priorities.
As each squad's sprints are planned, everyone knows that they will have to take on User Stories up to 20% of their capacity.
A synchronisation meeting is held every month to take stock of progress. At the end of each iteration, a review is held in front of the teams to share the work carried out, which will be used for all the projects. In addition to the technical documentation produced, the knowledge is disseminated during the presentation.
Of course, our customers' issues remain our priority and contributions to guilds may not be made in the event of a landslide. It will then be compensated during a calmer period. Above all, the aim is not to put pressure on the experts on the guild side (they have enough pressure on their shoulders with customer projects), but rather to help the team grow and make us all better.
What role do our project managers play?
We also have a team of project managers at Cloud Temple who work across the whole company. They are responsible for planning and managing our projects.
In the same way as the technical squads, they are autonomous in their organisation, but the proximity stimulates a standardisation of the tools, methods and media used for the different projects.
So, when a project manager is assigned to a project, he or she aligns with the leader of the technical squad on the resources available and plans the work according to the milestones for which he or she is the client's guarantor. In this way, we ensure that the planning is done in advance of the phase, with the sprints being completed according to the customer's requirements, rather than on an ad hoc basis as in traditional Scrum.
Of course, unless the customer has deadlines in his schedule, the technical experts remain free to organise their work as long as they respect the scope of the sprint and the project plan. They retain this agile autonomy but within a certain framework, guaranteeing that the customer's challenges are met. So we don't have a Scrum Master in our teams, because the project managers fill the sprints according to capacity, thus ensuring the feasibility of the operations.
Azure Boards is our project management tool. The User Stories are planned as soon as the projects are signed, and the key dates are indicated at the outset, so we have visibility over several weeks for each resource. With the contribution of the teams and a few dashboards, we are able to consolidate our Activity Report (ARC) in the tool and have a clear view of our projections and capacity. This limits the number of tools we use and gives us a common frame of reference.
A formula that works!
So yes, we 'twisted' the agile manifesto and the Spotify model to keep only what we wanted. We chose to refocus on values that our employees and customers can identify with, instead of copying and pasting a pre-established blueprint. This has enabled us to develop our expertise and put in place an efficient organisation.
Today, we're convinced that the model we've developed for our company reconciles our business with the culture of our employees, while delivering value to our customers. Every day, our numerous Public Cloud projects enable us to put this organisation to the test and support our customers in their transformation projects.
