Software Development Process: Arch-Agile Methodology

Abstract
The rapid pace of software development presents significant challenges, which the Agile Methodology has effectively tackled. This approach emphasizes flexibility and collaboration, enabling development teams to respond swiftly to new updates and changing requirements. As a result, it allows for quicker delivery of product enhancements and updates to customers, ensuring their needs are met promptly and effectively. However, this situation can present significant challenges for start-ups and new product development. While some subject matter experts may have a clear understanding of the project requirements, the developers on the scrum team often have numerous ways to implement the initial version of the product. This can lead to unnecessary research and prolonged discussions about the approach to take for product development, creating obstacles in the process. In today's software development world, there are countless options-development kits, tools, and packages-to solve a problem. Often, valuable time is consumed discussing which approach to take, even when there are no significant differences between the options. This situation poses a real challenge, particularly for dynamic Scrum teams. The Arch-Agile (Architecture-Agile) Methodology builds upon traditional Agile practices, offering a robust framework that guides teams in initiating the development of new products on a focused path to meet the goals. This approach provides structure and identifies a clear path toward successfully completing the product development.

Keywords: Agile methodology, Data, Arch-agile, Software development process

1. Introduction
The Arch-Agile Methodology² enhances the principles of Agile methodology, offering an increased focus on expedited development of a sellable product. While it retains the core execution components typical of Agile, such as the formation of scrum teams, the execution of sprints, daily stand-up meetings, and retrospectives, it introduces significant enhancements in story planning and backlog management. Arch-Agile's approach to planning user stories is a more strategic alignment and transformation of ideas from the product owner to design stories. So technically, the design backlog is the critical entity in Arch-Agile. This way, the sprint backlog will evolve and mature in the early stages of product development, enabling teams to prioritize tasks more effectively with technically sound user stories with more clarity and detail. This methodology aims to streamline workflow toward product development, enhance collaboration, and drive the development on a good path without deviating from product goals.

2. Agile Methodology for Software Development

Figure 1: Software Development using Agile Methodology.

In Agile methodology², refer to (Figure 1), few key individuals or team entities drive software development; these roles are critical. They are mentioned below:
●Product Owner (PO)³: At a broad level, the primary objective of the product owner is to ensure that the developed product provides value to customers, users, and the company. To achieve this, the product owner is responsible for managing the product backlog and adding stories that align with this vision.
●Scrum Master³: The scrum master's duty is critical to the scrum team's success. He facilitates conversations between team members and other internal and external entities to resolve conflict, channel knowledge, and improve collaboration. He also manages impediments so that the scrum team can focus on executing stories at the expected pace. The scrum master also coaches the team to self-manage.
●Developer⁴: This is not just a software developer. The scrum team developer refers to people who help create a valuable product for the customer. The developer's duties include planning the sprint, helping to build the sprint backlog, and implementing the stories.

The project uses the Agile methodology's sprint cycle for execution. A sprint consists of user stories planned for execution within a short time frame-usually one, two, or three weeks. The goal of each sprint is to achieve specific objectives that further product development. In software development, a user story typically goes through the stages outlined in (Figure 2), from sprint planning to review and closure.

Figure 2: Lifecycle of a story from sprint planning to the sprint completion in software development.

The figure 2 illustrates Agile methodology in a typical software development environment, assuming the use of a version management tool like GIT to manage product development artifacts. It's important to note that story implementation in Agile methodology is not limited to software development or version management. During a sprint, the story goes through several straightforward steps: first, it is planned and incorporated into the sprint backlog; then, one of the developers picks up the story and implements it. After implementation, the developer demonstrates the work to the team and the product owner, who then reviews the story and ultimately closes it. This process is simple and effective! 

3. Problem Description
If Agile works well, what issue are we trying to solve? We appreciate the principles of agile work; however, developers often have an overwhelming array of techniques, software solutions, and packages. This can complicate key product development strategies and hinder implementation progress on new product development, especially in a start-up company. Sometimes, every developer has multiple ideas for implementing a story because of the wide range of technology and tools available in the market. Consider a set of user stories that define product features, where there is only one clear path to achieve them. In this case, the developer is aligned, and the project will likely proceed smoothly. Now, let’s explore a scenario where the same set of user stories can be implemented in five different ways. While everyone may agree that the choice of approach won't significantly impact the outcome, we often create an additional story to determine which method is best. This can lead to debates over the results, complicating matters further. These discussions can consume extra sprints. If this situation occurs for most of the features of the new product, it can result in significant delays in project execution. By the time the product is completed, it may not meet market demands and could become very costly. So, how can we handle this situation? Arch-Agile to the rescue.

4. Solution - Arch-Agile Methodology
Architecture-agile methodology, or Arch-Agile Methodology, works by making the stories in the sprint backlog more technically deeper, with clear implementation guidelines and no ambiguity before it surfaces for sprint planning. For this Arch-Agile Methodology uses an extra role called Architect and a special backlog called design backlog. The role of the Architect is critical in this. He is expected to have experience designing similar systems and be very knowledgeable about the product domain or similar domains. His responsibilities include the following:
·Come up with software and system architecture.
·Identify software development packages and tools.
·Identify and resolve project dependency
·Define the product development environment and Agile framework integration.

Figure 3: Arch-Agile Methodology.

The Architect is responsible for managing the design backlog. At the beginning of new product development, the stories from the product backlog are not moved to the sprint backlog. Instead, the Architect collaborates with the Product Owner to convert stories from the product backlog into design stories that are listed with priorities in the design backlog. During the sprint planning session, the Architect, Product Owner, developers, and Scrum Master work together to identify which design stories can be transferred to the sprint backlog for the next sprint execution. Since the design stories provide clear instructions on what to implement and how to implement it, they typically offer greater clarity and technical detail compared to stories in the product backlog. This level of detail can also facilitate more accurate story estimation. Once a design story is complete, the architect marks the corresponding story in the product backlog as complete. This way, the architect can ensure that the product is developed based on the system architecture and aligns with the product owner's vision. Practically, this approach is excellent for starting a product development to quickly achieve the first version of a sellable product.

Typically, companies don't have many architects available to support all product development. Therefore, it’s advisable to use Arch-Agile to create the initial version of the product and then transition to Agile for subsequent enhancements and updates. Figure 4 illustrates the entire product development lifecycle.

Figure 4: Complete Product life cycle with Arch-Agile and Agile.

5. Conclusion
Arch-Agile methodology is an excellent process framework for starting a new product development and streamlining the development through a clear technical path to achieve the swift completion of initial product development. In this framework, the Architect plays a vital role in setting up the platform for the developers with tools and accessories that can help the developers work on the stories. The Architect also designs the first system architecture and identifies the development environment and packages. Design backlog is another entity added to the Arch Agile methodology. The design backlog contains technically rich user stories that the architect derives from the product backlog. When following the Arch-Agile methodology, sprint planning is done based on the design backlog and its priorities, not the product backlog. The sprint execution, sprint review, and retrospection activities in Arch-Agile remain the same as those in Agile methodology.

6. References

1.  https://link.springer.com/chapter/10.1007/978-3-642-55035-5_11
2. S. Ilieva, P. Ivanov and E. Stefanova, "Analyses of an agile methodology implementation," Proceedings. 30th Euromicro Conference, Rennes, France, 2004: 326-333.
3. https://www.scrumalliance.org
4. https://www.scrum.org/