Azure DevOps – not just a code repository
In the last couple of years, I’ve grown to like the Azure DevOps services provided by Microsoft, but the journey to this point hasn’t been a straight arrow.
I have some key learnings I want to share with the rest of you. Some are my personal experience, others are stories I’ve snapped up from colleagues and their situations with the service at their respective customers.
Some background may be in place before we get into it. Since Azure DevOps (formerly Visual Studio Team Services) started allowing GIT-repositories, we tend to think of this service as a service for developers to handle their code, build and deploy scripts and versions of them. While that is true, that is not all Azure DevOps actually can do. As with any other service, it takes some effort to both understand the capabilities and to structure your use of the capabilities to suit your needs.
Planning in DevOps
One of the capabilities in Azure DevOps that is a bit overlooked is the planning features within the section Boards. Within this section, you can plan, collaborate, gather requirements, divide the work into smaller and more manageable pieces, see who has committed code, see if it is deployed in a specific environment, and follow up on the progress. Sounds like a Project Manager’s wet dream, doesn’t it?
Well, you remember that I said “structure your use of the capabilities to suit your needs”? Here come the difficulties. It is almost always hard to implement a new tool that no one really knows that they need. The first things I heard when I suggested the use of Azure DevOps Boards in our projects were along the line:
We have a good task list in Excel already. And that’s free!
But, I made a PowerPoint that outlines the Project timeline…
I have the requirements in a Word-document and a shortlist in Excel, I don’t want to transfer them to yet another tool.
I can’t see that I need that. Besides, it is much easier to send a progress report once a week by email.
How to overcome these arguments without stepping on people’s toes or even stepping over their dead bodies? I can’t give you a definitive answer for that, but advise you to be relentless and keep showing the benefits of building up a structure in Azure DevOps! And, I will provide you with some advice on how to build that structure.
First of all: there are some hierarchies to understand within Azure DevOps: Organizational hierarchies and Work Item hierarchies. Let’s look at the Organizational parts first:
Every DevOps account can be tied to one or more Organizations
An Organization consist of one or more Projects
A Project consists of one or more Teams
A Team has one or more members
Planning the structures
So, should I have one or more Projects in my Organization? Yes, maybe? Are they completely separate from each other? Do they need to be separated? Separation is intended for just that: keep things apart that don’t need to touch. If you don’t need that separation, keep as much as possible in one Project and separate the work Items in Teams within that Project. Remember: this is a collaboration tool!
The next part to understand is the hierarchy of Work Items. A work Item is a “card” that describes what you want to accomplish. Normally, people have a bit of trouble defining exactly what they want to have in one single go. That is quite normal, especially when it comes to a larger project. This is why the Work Items are made in a hierarchy from Work Items most vague in details down to a Work Item that describes a single detail to be implemented.
The responsibility around the Work Items is always good to decide upon early. I normally recommend that the Business side (Product Owner or any equivalent) takes responsibility for creating and maintaining Epics and Features. When a Feature is ready for development the responsible role at the Business side can hand it over to the Developer side for refinement in User Stories. On the Developer side, we need to break the Feature down into User Stories. In this part, it is very helpful to have open communication with the Business side. When we have our User Stories and understand them, we can start planning for in what order we want to implement them. This also needs help from the Business side and, probably, communication with other teams.
Working in DevOps Boards
For the planning, Azure DevOps provides us with Sprint Planning. We can easily drag and drop a User Story to the desired Sprint. Do not overdo the planning! Better to have a sense feeling of accomplishment at the end of the Sprint than to have four, untouched User Stories at the end of the Sprint! Immideatly after the Sprint Planning, the Developers start to break down the User Stories into Tasks and to implement code/configuration and infrastructure that aims to fulfill the User Stories.
When it comes to planning, I have another, general advice, to share with you. A Task should a Developer be able to finish within 8 working hours. A User Story should, normally, be finished within the Sprint. If this is not the case, it is better to re-evaluate them and split them up into finer details. This takes some getting used to, but is very important for all involved.
So, how can I see the progress and share that with my Organization? You can of course check out the state of each Work Item and that way create your own picture of the general situation. An easier way is to check the Sprint Backlog and add a rollup column based on the Progress.
So, without using PowerPoint, Excel, Word, and sharing via Teams, SharePoint, DropBox, OneDrive, and so on, we can have a truly collaborative platform between Business and Developers for the development of any kind of project and keep everyone updated with the Progress. It just takes a small effort to create the collaborative structure together! There is also an extensive Marketplace for Azure DevOps. If you feel the need for a certain extension, go on and try it. There are extensions for Microsoft Teams for example. Just another way of getting the collaboration a step further out in the organization. All the effort will pay off. Developers will be happier when you help take the guesswork out of their everyday work. Project Managers will be happy when they can get progress and status at any given time. Product Owners will be happy when they can see steady progress and have ease of communication with the Developers.