DevOps - that wonderful name that brings developer and operations processes together to support continuous delivery of software updates. It's a different discipline to managing infrastructure or monitoring servers, though Infrastructure as Code has a place in DevOps processes.
Today's blog is provided by Microsoft MVP Takashi Takebayashi, explaining why developers use Azure DevOps Services and how it solves the problems they have working together as a team.
Introduction
In this post, I will introduce trial and error and its consequences as a Scrum Master and developer to improve the efficiency of project management and the quality of output.
Prerequisites
Team members other than me (product owners, designers ... etc) have a lot of experience in Waterfall development and less experience in Agile / scrum development.
Initial state
Since development efficiency is poor with Backlog, which does not have CI (continuous integration) / CD (continuous delivery) function, I proposed to use Azure DevOps Services, but it is not translated into Japanese. Was rejected because of this.
Similarly, Azure DevOps Services was rejected because it had to be operated and maintained by itself.
Initial issue
- No CI
- No CD
- User stories are not prioritized
No CI
We were using Backlog didn't have CI. Also, Azure DevOps Services, Azure DevOps Server with CI / CD wasn't available, so the developers had to prepare the CI themselves.
We chose GitHub Actions because the version control used in the project is Git, and if the scope of influence is GitHub Actions, it is limited to developers. I have fixed this issue by synchronizing the Git repository on Backlog with the Git repository on GitHub.
No CD
We were using Backlog didn't have CD. Also, Azure DevOps Services, Azure DevOps Server with CI / CD wasn't available, so the developers had to prepare the CI themselves.
GitHub Actions adopted in CI was also available on CD, so by GitHub Actions, fixed this issue.
User stories are not prioritized
We were using Backlog didn't have "priority". As a result, we couldn't sort the user stories in order of priority, and we had to use some other tool to sort the user stories in order of priority. Excel was the one that product owners were accustomed to.
However, it was difficult to change the priority easily in Excel. Specifically, the product owner needs to take the following steps when changing the priority of the user story.
- Insert a line in the priority of the user story product owner want to include.
- Write the user story on the inserted line.
- (When the one with the lower priority is made higher or the one with the higher priority is made lower:) Delete the line of the user story before moving.
This task was more troublesome than the product owner had imagined. As a result, there were many problems such as, the user story that the product owner forgot to delete remains, the product owner intended to add the user story but accidentally deletes the user story, Backlog or Excel user stories has not been updated.
As a result, the entire Scrum team was confused, with missing user stories to do in the sprint and user stories that didn't have to be done, and the velocity remained low.
New issues arose as a result of each solution
Enormous DevOps tax
As a result of each product owner and developer solving the problem at hand, it became necessary to use multiple tools properly for the team as a whole. Also, since it is troublesome for each member to see all of the multiple tools, some members work without looking at the information contained in the tools.
Specifically, the following happened frequently:
There was an error in the resolution of the image created by the designer. The developer had incorporated Danger into CI conducted by GitHub Actions.
Danger acting as CI pointed out that the resolution of the image created by the designer is incorrect. However, the designer did not see the results or suggestions of GitHub Actions, so the error was not resolved. Our team followed the rule not to merge the changes if a warning occurred in CI. As a result, images with incorrect resolutions were not merged until the errors were corrected.
The team took the following steps to correct the mistake.
- Tell the designer verbally or with a chat tool that the resolution of the image created is incorrect.
- The designer recreates the image.
- Check if the Danger that acted as CI is correct.
- The mistake wasn't fixed in one go, and the team repeated this procedure over and over again.
As a result, it happened that no user story was done within the sprint.
Drastic solution
The whole team understood that even if each of them did what they thought was good for the team, it was only a partial optimization, not an overall optimization. So, in the situation where we are now on a zero basis, we discussed in retrospect what should be prioritized to solve.
Despite various opinions, in summary, we agreed that "everyone would use a common tool."
The tool chosen was the initially rejected Azure DevOps Services.
Haste makes waste.
By adopting Azure DevOps Services, we have been in front of us until now. All the issues that existed have been resolved.
- Enormous DevOps tax -> All information is always in Azure DevOps Services. So, DevOps tax does not occur because it is aggregated.
- No CI -> CI with Azure Pipelines
- No CD -> CD with Azure Pipelines
- User stories are not prioritized -> Azure Boards allow prioritized user stories
At the same time, there were no new challenges.
And with the adoption of Azure DevOps Services, our velocity has increased tenfold!!
Learn more
Get started with Azure DevOps
Deploy applications with Azure DevOps
AZ-400 Define and implement continuous integration
