Reducing the gap between operations and development using Azure DevOps

Intro

As we all know, DevOps is culture. In a company that is going to adopt its practices and principles, everyone should be “on the same side”. Continuous improvement cannot be part of our work in IT if we wouldn’t reduce the gap between development and operations. People like me, that worked in the 90s, know that dev and ops were always isolated in silos and this was “the only” way that everyone followed as a suggestion taken from the market leaders. Ticketing systems and extreme bureaucracy acted as a man-in-the-middle between those silos, transforming each organization in two people-unaware endpoints.

Speaking from a DevOps perspective, in such circumstances, a developer couldn’t know anything about how to deploy, where and how is an environment configured. On the other hand, an operation guy couldn’t get anything from a package in terms of what the application has been made for. Due to this gap we often see performance issues, underestimated hardware stuff and delayed releases. Last but not least, what about the lack of commitment and accountability of the employees working on the solution? In short, reducing such a gap is possible using a combination of DevOps culture and the right tools. We will see hereafter how my organization tries to do so using Azure DevOps.

Scenario

Let’s get started with our team (DevTeam hereafter), which is working with agile methodologies, composed of ten developers and a PO. A quick note, we are using a process decision framework called Disciplined Agile (https://www.disciplinedagileconsortium.org/). Then, we have three operation professionals (OpsTeam hereafter). Build and deploy pipelines already exist. Builds are hosted by Azure DevOps and deploys are managed by Octopus Deploy. Getting this has been a difficult mission.

Everything is related to infrastructure in terms of servers, operative systems, virtual hosts, DNS, firewalls, security and so on, is the responsibility of our OpsTeam. As a result, they do many tasks for managing the environments. Here comes the problem. DevTeams used to create tasks in a dedicated backlog, but OpsTeam didn’t. It’s not just a matter of end-of-pipeline tasks, but also tasks for their daily basis work.

Our solution

Modify the tool, adapting its shape in order to fit in with that real scenario. A piece of cake, when you’re DevOps “inside”. How did we change Azure DevOps? Let’s describe what we did in three parts:

Team on Azure DevOps

To create a team in Azure DevOps is really a piece of cake (according to the latest releases). Just navigate to the options and select Teams:

We can add many teams clicking on New team:

We can set the team’s administrators, the permission set and an area under which every work item will be created. This area will be one of our best friends, especially when we will make our queries for gathering and analyzing the team’s related data. Additionally, also the other teams’ members could create items with this area in order to make the OpsTeam aware of them.

Team’s backlog

Now let’s navigate to Backlogs:

Good! The new backlog has been created. Going on it, we will see the team’s drop-down as well as the one for iterations. Great features!

Once created, we will see the teams’ drop-down:

Work items

Now, let’s create a new work item type. We call it Ops item. Navigate to Process customization page:

Before adding the new work item, we must ensure that the process is already a custom process, otherwise, all the edits will be blocked as shown in the following picture:

We’ve already created a SimplifiedScrum process. let’s add our item now:

Now we are going to modify the fields of the new type. Each team should be able to understand all the item’s properties. We will leave the item as is in this example. Then, we have to map the type to the backlog item list, since only the default work item types are shown initially. To do this, navigate to the Process customization page, Backlog Levels tab:

As we can see, we can also set the default item for our requirements backlog. Moreover, every Sprint backlog, based on iterations, will enable us to add the new Ops item:

Wrapping up

So, we’ve got a backlog for the IT Operations team’s members. Then, we’ve related it to their Azure DevOps team. Additionally, we’ve got a particular work item type (not mandatory, but really useful for querying it or adding it into dashboards) target of IT Operations’ job and a dedicated Area Path. We can make many relationships between items of both our backlogs. Here is an example of how an activity can be managed and organized (extension: Work Item Visualize):

As you can see, the Ops items are Successor of the “development” Product backlog items. Indeed, the Ops Items will be finished after the PBI, typically. Think about creating s DNS or a network path to let the production app work in production.

Conclusions

With this solution, we’re decoupling backlogs. Moreover, we’re isolating the management maintaining the relationships between work items that reside on different boards. At the same time, we’re making a strong synergy between Development and Operations.Then, in a couple of clicks, we can switch teams and backlogs, using Azure DevOps Boards. We can track changes in both the departments, also for audit requirements. In my opinion, this helps the enterprise awareness and facilitates the continuous improvement of all the teams and any member’s skill.

Agile@School – Inizio

Il club delle 6

Anche l’ITI F.Viola/Marchesini di Rovigo si è unito ufficialmente al progetto esperimento/laboratorio Agile@School basato sull’idea e il supporto di Alessandro Alpi.

Immagine

Il tutto è stato inserito nelle attività ufficiali di alternanza scuola-lavoro dei ragazzi delle due quinte dell’istituto rodigino.

Il laboratorio ha come obiettivo introdurre i ragazzi ai concetti Agile e di lavoro in team: si mettono le mani in pasta e si utilizzano strumenti all’avanguardia del mondo professionale per realizzare un’app con Xamarin.

Nelle tre ore di laboratorio abbiamo toccato svariate argomentazioni e devo fare i complimenti ai ragazzi per essere stati complici e attivi in questo inizio di percorso tutto da esplorare.

  • Abbiamo introdotto i primi concetti e terminologia del mondo Agile e delle sostanziali differenze di cosa vuol dire fare un software per hobby/studio e farlo professionalmente.
  • Abbiamo esplorato le funzionalità di base di VSTS (Visual Studio Team Services) creando varie tipologie di PBI e mettendole…

View original post 158 more words

Agile@School – sesta lezione

Il club delle 6

Sono ripresi oggi gli appuntamenti all’ITI F.Viola / Marchesini di Rovigo di Agile@School dopo le vacanze: siamo al sesto episodio su dieci. Come ripromesso negli episodi precedenti abbiamo ripreso in mano dei principi Agile/DevOps che negli ultimi incontri erano stati parcheggiati in favore di approfondimenti tecnologici su Xamarin Forms.

Continuous Delivery

View original post 219 more words

Agile@School – Terza lezione

Il club delle 6

Eccoci giunti alla terza lezione su dieci del laboratorio Agile@School dell’IIS Viola/Marchesini di Rovigo

Screenshot_1

Stand-up meeting

Anche questa volta abbiamo fatto pratica con lo stand-up meeting in cui abbiamo fatto un piccolo riassunto della puntata precedente ed è stato introdotto a grandi linee il programma della giornata. La partecipazione al riassunto sugli argomenti passati è stata tiepida ma ugualmente ci ha fatto scontrare col fatto che per riassumere gli episodi precedenti bisogna scegliere l’adeguato livello di astrazione: né troppo elevato, né troppo dettagliato. A seguire ho introdotto gli argomenti della giornata e una previsione sulla lezione futura.

MVVM – Comandi

Abbiamo ripreso il filo della lezione precedente introducendo il concetto di comandi nel mondo MVVM. Con l’occasione abbiamo letto insieme la documentazione MSDN dell’interfaccia ICommand, abbiamo ripassato il concetto di delegati e studiato un’implementazione di ICommand. Ancora una volta il livello di preparazione delle quinte mi ha stupito perché la…

View original post 233 more words

Agile@School – Seconda lezione

Il club delle 6

Anche questa settimana si è svolto l’incontro del laboratorio Agile@School all’IIS Viola/Marchesini.

Stand-up meeting

In questa seconda lezione abbiamo applicato subito uno dei concetti affrontati la lezione scorsa: il feedback per incentivare il miglioramento continuo. Ne abbiamo approfittato per introdurre lo stand-up meeting che viene svolto da molti team. In questi minuti di  incontro “informale” in piedi abbiamo provato a raccogliere sensazioni e pareri sul primo incontro. Dopo un primo momento di silenzio qualcuno ha detto il proprio parere:

  • Alcuni hanno definito l’incontro più interessante del previsto, in particolare è stato trovato interessante il concetto di team e la sua gestione;
  • Qualcun’altro è stato colpito dalla potenza della visualizzazione del lavoro tramite una kanban board;
  • Uno dei professori ha riferito che i principi base riguardanti DevOps sono molto interessanti.

Ho provato anche a incentivare feedback negativi ma nessuno si è sbilanciato. Per ora 3 feedback positivi sono un buon risultato…

View original post 256 more words

Agile@School 2017 – obstacles on the path

Hello everyone,

As mentioned in the previous post, the project has been started and we’ve reached the “fourth episode”. This time, Alessandro and I were able to talk with students in order to get which kind of project they are going to complete and show during the final exam.

Like every other project, problems are behind the corner. Indeed, the students didn’t create any task under the related Product Backlog Items. This is what they should have done. The issues were principally:

  • some teams still not had figured any idea to implement
  • some other weren’t able to use Visual Studio Team Services (VSTS) in the right way (or few of them simply didn’t wanted to 🙂 )

That’s it, so our last meeting was focused on explaining the advantages of agile methodologies instead of the classic waterfall approach, showing them how to use VSTS correctly in order to clarify any doubt about its use. We started to speak about methodologies because they used to waterfall their project, and this means that they were gathering ideas, instead of thinking in an iterative way.

Although this fact, we could see the first results from the majority of the students which let us being confident about the future of their projects.

As result of this talk, the students seemed to have got why choose a methodology instead of another, being able to manage their work with the right tools. At the end of this day, we’ve assigned them just a simple homework: create the tasks which reflects their development steps, moving PBIs through different status during their work.

That was all for this episode. Stay tuned for any news about the course of the project.

See you to the next post!

Agile@School 2017 – let’s start over

As a recurring project, Agile@School is started again on February, with a new set of projects and ideas. Gabriele will help me again, but it will be a very difficult task. During the past year we followed a Scrum approach, in order to comply the team structure. As you can read here, there were one team with a small bunch of members. Now, we’re getting “bigger”. As a result, we’ll have micro-teams of two/three member each. Great chance for Kanban. Let’s give it a try.

01

How will we approach in the beginning?

  • defining a set of micro-team, that we call “task forces”
  • designing a Kanban board
  • describing personas
  • speaking of some ceremonies we’d like to get rid of
  • speaking of some ceremonies we’ll keep
  • describing the customer journey and the story map practices

The task forces

The term not fits very well, actually; indeed, a task force is something that could be considered as a “defcon 1” team. However, we would give the teams a label which is “strong”. To be honest, we have a little amount of time, so in the end we can say that we’re in hurry already 🙂

The Kanbard board

As we said above, we will have more task forces, most likely six. Therefore, the board will use columns (as usual) for the status management and rows (aka Swimlanes) for separating teams and projects.

02

The board will be created in Visual Studio Team Services, in order to use also the Source Control Manager which relies on it.

Personas

Each team member will populate a simple card, the Persona card, which is depicted in the picture below:

03

As you can see (in Italian), the first column is for Persona details, the second for interests and the third is the “role” which the member would like to have. I know that the last column is not included in any best practice, but I feel that some student could start to think about its job and its future. Could be interesting.

The customer journey

During the next meeting, we’ll ask the students to show us their customer journey. Each team will have to describe the journey of a typical user, with mood for each action it takes and the value which it gets by the action itself.

Conclusions

Kanban, task forces, boards, customer journey, personas, etc. This year is full of new things to get knowledge from. Also the source control manager will change. We will use git on VSTS so we will get different projects in the same place in a quicker way.

And now, let’s start over! 🙂

Events after the summer holidays

Summer holidays are coming, finally. This year I’m really tired, maybe because I’ve spent my energies on learning English, working hard for my own Company, following external school and non-school projects. But I can say that one of the most heavy part has been the organization of the following two events:

Continue reading “Events after the summer holidays”