%% Use bold for emphasises and italics for quotes or phrases %% ## Sections %% ## What problem does it solve %% ### Being Agile Agile is established as a methodology that aims to enhance SDLC cycle through an iterative and flexible approach to project management and the intertwined software components - in a short definition. As **Agile** is a methodology, it may be implemented with different tools. One of the best tools on the market is Azure DevOps, as it integrates all aspects of project management into one space. #### Agile + Development There are a couple different products attempting to fuse Agile with Developer Platforms, majorly GitHub, GItLab, Azure DevOps. Azure DevOps is perhaps the best as it offers all functionalities out-of-the-box: - Azure **Artifacts** - Azure **Boards** (more than just Scrum Board, also Wiki and Dashboards) - Azure **Pipelines** - Azure **Repos** - Azure **Test Plans** It is a full package that integrates the Developer Platform and its underlying (GIT) Repositories and CI/CD Pipelines with features of Agile-driven project development, so Boards and '*Test-Driven Development-like*' functionalities in the form of Test Plans (sort of a QA feature rather than TDD specifically). GitHub and GitLab perform somewhat similarly, yet I would place GitLab above GitHub in this contest. This article is however not about granular comparison, but rather about why Jira fails as the tool it claims to be. GitHub is **the more popular** choice most of the time and it offers: - **Repositories** - **Pipelines** - **Projects** - **Pages** - A few non-consolidated features (e.g. artifact registries) ### Being more Agile While the Developer Platform part of GitHub remains adequate, the Agile part is at best lacking. Compared with Azure Boards from Azure DevOps, the clear winner is Azure Boards as it provides granular configuration of: - Project Process - Basic, Scrum, Agile, CMMI, but most importantly - custom Project Processes inherited from the default processes. A custom Project Process may define new types of 'Requirements' (Work Item types in popular nomenclature) with custom fields, names. - Project Wiki - Perhaps one of the least appreciated parts, yet offering incredible possibilities, including Project documentation page with subpages(!), custom Dashboards (e.g. for Queries, incredibly useful for Agile management) and a 'Summary' page. - Project Test Cases - It is an additional feature that requires a license, yet it extends the basic functionality with capability of testing the Project's features with Test Cases. This is something useful for Teams with dedicated QAs (or as usual - DevOps Engineers). - Project Stakeholder Views - Essentially, the granular roles that may prohibit access to Repositories, yet allow access to the Boards, as well as Dashboards with custom views - such approach allows for 'isolation' of the Project (SDE efforts) from the monitoring/KPI tools, yet the entire solution remains *homogeneous* as it contains both. This is why GitHub is often *supplemented* with Jira. Jira is meant to fill out the gaps. <center><img src="https://media1.tenor.com/m/iB7GZ2k0KPwAAAAC/oh-agent-smith.gif"></center> %% ## How does it solve it %% ### Jira is... not *agile* The whole point of Azure DevOps and platforms attempting at coupling Developer Platform with Agile methodology tools is creating a workspace for seamlessly integrated features of the two worlds to the benefit of simplicity and velocity. The fact that GitHub or equivalent Developer Platforms must be paired with additional *Agile* tools logically concludes the point of them being inadequate in this scope - increasing the complexity at the very beginning. However, properly designed tools would implement the capabilities mentioned above and there would be no problem - every Developer would be happy. In a slightly less ideal (real) world - Jira exists and the main issues with this fact are: - non-native integration with Developer Platforms (Repos and all correlated GIT features, such as e.g. Pull Requests), **thus increasing the efforts**, - lack of simplicity when it comes to Project Process configuration - this is dependent on the Project Owner and Scrum Master, yet it remains perhaps one of the biggest issues for all Jira Projects, **further increasing the efforts**, - poor design of the UI, e.g. shoddy scalability for small screen devices (especially laptops and Developers happen to use laptops... a lot), **hence challenging Developers**, - lots of smaller design decisions - e.g. inability to edit Work Items after completing them, lack of cohesive design for most important Work Item properties - inheritance, correlation, easy conversion from e.g. Task to User Story (e.g. drag and drop in Azure Boards), **finally wearing the Developers out**. The biggest flaw of the tool is the lack of enforced decision making framework. Azure DevOps has a **clear vision on what the Users (Stakeholders, Product Owners, Scrum Masters, Developers) can do**. Jira offers lots of customisation, leading to **overly modified, diminished-value layouts** with lots of overlap in between. %% ## How to use it %% ### What Jira should be Sometimes a simple setup is not great, yet it satisfies the development needs and does not decrease the velocity for superficial reasons. As an example of a sufficient Scrum process flow: 1. Developers and Product Owner create Work Items in an Iteration. 2. Developers assign Work Items and adjust Work Items properties. 3. Developers create Pull Requests and finalise work by linking them to Work Items. 4. Developers modify Work Items using pre-defined Workflow states. 5. Product Owner creates a new Sprint and a Retrospective. Such a 'process flow' is sufficient to implement basic Agile methodology criteria. Jira complicates this process by creating an over-complicated interface with redundant parts. Azure DevOps offers very intuitively created Iteration Paths (Sprints) with Area Paths (Teams). It is incredibly simple to create a Backlog with different Iterations that include Boards for multiple Sub-Teams (e.g. Architects, QAs, Cloud Engineers). Both Azure Boards and Jira offer the option to create custom Board colouring rules, filters or Queries to retrieve specific information. The difference being that almost all features of Azure DevOps are very simple to configure and a few clicks away. Jira has an unspoken '*mystic capability*' of bending the **three-click rule** in every way imaginable. Something that may be simple suddenly becomes a chore. This effectively kills development efforts as simple tasks become complicated and kill focus that could be spent on Software Development. It is essential to provide a simple interface for somewhat trivial functions that need not be complicated. For example: the Developer should be able to easily navigate back and forth through the Iterations Paths without the need of custom dashboards or asking for help. It is difficult to substantively compare Azure DevOps, Jira and GitHub (Agile-components wise) without referencing the GUI components, design patterns and default configurations in details - yet everyone who has tried each of these solutions would likely understand the clear differences in between them. ## References ### Section 1 - Being Agile - https://learn.microsoft.com/en-us/azure/devops/user-guide/devops-alm-overview?view=azure-devops - https://github.com/features#features-project-management - https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects ### Section 2 - Being more Agile - https://learn.microsoft.com/en-us/azure/devops/boards/work-items/guidance/choose-process?view=azure-devops&tabs=agile-process - https://learn.microsoft.com/en-us/azure/devops/organizations/settings/work/customize-process?view=azure-devops - https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-requirements?view=azure-devops&tabs=agile-process - https://learn.microsoft.com/en-us/azure/devops/boards/configure-customize?view=azure-devops&tabs=agile-process ### Section 3 - Jira is... not *agile* - https://www.atlassian.com/software/jira/guides/boards/overview#what-is-a-jira-board - https://www.atlassian.com/software/jira/guides/issues/overview#what-is-jira-work%20item-hierarchy ### Section 4 - What Jira should be - https://learn.microsoft.com/en-us/azure/devops/organizations/settings/set-area-paths?view=azure-devops&tabs=browser - https://jira.atlassian.com/browse/JSWSERVER-14837 ## Metadata Date of creation: 2025-07-09 Date of revision: <...>