Delta Teams: A way of setting integration ground

Delta Teams: A way of setting integration ground

delta teams

Enterprise software development deals with a large amount of functionality that needs to be delivered. Hence the functionality is split into components and each team is responsible to develop and maintain one or more of them. Each team will take the architecture decisions needed to deliver their functionality.

What if we have a cross-cutting concern? What if we need to enhance the security for each API in the application or implement a distributed logging mechanism or even update all the automated CI pipelines?

In the spirit of early integration, we propose the concept of delta teams. A delta team is a technical task force assembled in order to set the integration ground. A delta team has a limited lifetime and a very simple goal to implement an integrated end to end scenario in order to help the teams deliver rapidly business value.

Like special forces, a Delta team tries to set the ground for the rest. A walking skeleton that teams can rely on and be able to enhance it.

When the time box expires the team is been disassembled. Optionally the team can have a demo and a retrospective ceremony. In the case of a demo, the team will demonstrate its work and share the knowledge developed, while in the case of a retrospective will provide useful input for what worked well and what won't.

In our case, we had to have distributed logging in our micro-services application. we called upon our scrum masters and inform them that we want to make a proof of concept in order to solve the problem. Thus, we decided to experiment with the Delta team’s idea.

The result of the first delta retrospective we had, shown that the team isolation and the technical flexibility the team had, were really valuable to the process. The whole process was time-boxed and intense as we used pair programming techniques.

The solution was driven by a fast and easy thinking rather than a more sophisticated one. Or if we would like to put that in fewer words, simplicity. This allowed us to deliver in two days a working end to end scenario. This couldn’t be real without the full support of both team’s scrum masters.

I truly believe that if you try an approach like the above you will not be disappointed by its performance.

Have you ever came across problems like the ones above?
How did you come up with them?

Vassilis Simeonidis, 
Software Developer - Post-Graduate Student

Popular posts from this blog

Constraint Theory on Cities: Skylines

Image
 In 1984 Dr. Eliyahu M. Goldratt introduced, with his novel “ The Goal: A Process of Ongoing Improvement ”, the theory of constraints. Theory of constraints emphasises on calibrating a pipeline of work using as a metric only its total output and not the productivity of each component. The user of the theory has to identify its output, its input and the major bottleneck in its pipeline. This fundamental theory was also depicted in the novel “ The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win ”, which was meant to be the devops flavor of the novel “The Goal”. In this novel, a new assigned IT Manager has to deliver a new project which is supposed to give to its company a competitive advantage on the market. While doing this he has to sustain the life cycle of all the IT projects this organization runs. I read the two books with little time difference between them, quite recently. I started being a fan of this theory and I was wondering if such a theory could
Read more

Learning Through the Web: Lessons Learned

Image
Disclaimer: The subject discussed below is based on my personal experience with software tools in a humorous aspect. It is not meant to be approached as “the correct approach”, it’s something that I find useful. Working as a software engineer I have encountered a plethora of problems that require different tools per case. Obviously there is no chance of knowing every tool you are going to use, especially early on, on your career. And since computer specialists double in numbers every 5 years, based on Clean Coders, My lawn article [1], every day makes this case more relevant. With such a rate of growth, learning new tools and methodologies becomes an industry problem When I begin to use a new, to you, tool, the cycle goes like the following: A new need appears You think of and (maybe) look for the best tools available You select one or a combination of them based on your needs and taste Then you start googling the required setup Once you have the required setup in place, you start to p
Read more

Learning Through the Web: Ansible

This list is a companion to my article Learning Through the Web: Lessons Learned As mentioned in the article, during the learning period I get through, I try to read a relevant book and spot the things I missed on the web. This list is exactly this for ansible. The book read is Ansible Up and Running [1] Firstly something that comes handy, you can make your Ansible playbooks executable using shebang by adding #! /usr/bin/env ansible-playbook at the beginning of the file It is a good practice to keep files and jinja templates on separate directories (/files, /templates) because during the execution of each respective task, (file or template) ansible will check those directories first, either it is in a role or simply a playbook Handlers in ansible run only on changed task status, not always default/main.yml variables are meant to be overridden whereas vars/main.yml are not You can define dependencies between roles You can pass roles variables using the following syntax roles: - { role:
Read more