Role of Architect in Agile Development

Introduction

Agile is a methodology used by many enterprises as a software development methodology to deliver value to end-users incrementally and faster. The approach is iterative, and the working software built and delivered in smaller chunks at the end of each iteration. In Agile methodology, the tasks are broken down into smaller, more easily managed segments to speed up the design process and produce a quality product as quickly as possible.

While the demand to move all the enterprise applications development using Agile is increasing by the business, not all applications are equally suited for agile development. 

Challenges in Agile Development 

While every customer today is adopting agile development irrespective of nature, size of the project, the following are the list of challenges that we foresee as an Architect in agile development.  Top challenges are,   

1. Visibility, no end to end visibility on long term client road map (technical and domain).
2. Resistance, for any suggestions and changes to the existing processes, the acceptability is very low or almost nil from the Customer.
3. Multiple teams working on different features and different parts of the code base result in architecture foundation structure erosion and code overlap across modules.
4. Lack of focus on Quality of Service (QoS) attributes.
5. Requirement Volatility, usually requirements are defined from multiple sources, not just by Business Analyst. Therefore, whenever someone expresses a ‘wish’ that needs to be added to the backlog.
6. Time Crunch, it was always a compromise between technology, NFR and time. Usually, we do not have any control over time. To make the customer happy, we need to complete all the Business requirements within that time. So the only place we can compromise is technology and NFR.
7. The latest technology adoption, the approach is to prioritize all the 'visible' requirements first, and then get into others. In the process, we miss the opportunities to implement the latest technologies. 
8. Technical debt, technical considerations are getting lower priority in product backlogs compared to business features. This accumulates the technical debts that need rework.

As an architect being part of many programs, we have come across the following few scenarios:

Scenario 1

Working on multiple functional aspects in parallel which would fall into different logical categories.

Agile methodology predominantly works on the "one-task at a time" principle. The scrum meetings expect everyone including the architects to log the efforts and report status on those lines. Also, strictly logging the efforts against the exact tasks would result in the creation of an unmanageable number of tasks.  It is very difficult to fit the dynamic priorities and parallel tasks into this culture. 

The solution adopted is for a given sprint, the tasks are, 

• Discussion with architecture board.
• Formulating NFR Strategies. 
• At the end of a sprint, ensure that efforts are appropriately distributed across various tasks.

Scenario 2

Low priority of Technical Considerations.

Architecture created during initial iterations before the implementation of iteration starts. Any changes identified, will be presented in PI planning and try to get user stories for that. Generally, we need to present all the issues in the PI planning event, need to buy time for architectural or best practices implementations. Any event that not considered in PI/Sprint planning is a big challenge.  Any design changes identified during the middle of the iteration pushed to the next iteration. 

As architect must assess the overall architecture, design consideration, and estimate the Nonfunctional requirements based on vast experience in that area.  I need to have continuous attention to technical excellence and good design. Also, adopt the regular changes and accept the late changes in requirements. 

Scenario 3 

Skill management. 

In one of the programs, the user stories allotted to less skilled/ new resources.  The delivery and working with them is a challenge.   This is an issue because in the agile process we have less control to allocate tasks to resources as most of them choose for themselves.

Program teams divided as small scrum teams to concentrate on delivery. Continuously check with the team to make sure they are not deviating from the stated design. Many times, as an architect had to protect the team from the unwanted bureaucracy

Demo the sprint output to business for customer feedback and accommodate necessary changes and Secondly, the team needs to have the right composition of experienced and fresher's engineers.

Though agile does not recommend documentation explicitly, we use to document as much as possible for easing the life of support teams in the future.

Scenario 4

Requirements Management.

Though the requirements verified in the start towards the end, we use to get a few surprises regarding implicit requirements.

Sprint scope jointly decided between the product owner and team. Architect; intervene only in case of issues during the scoping or changes introduced at the last moment.

Many times the testing used to happen on mock data, but we use to face many challenges and CRs during the SIT/UAT phase. As the business use to realize, that what they thought would solve their problem completely is solving it only partially. 

Role of an Architect in Agile Development 

Following diagram depicts the high-level steps involved in a typical agile development process:

During Portfolio backlog construction phase, Architect will collaborate with Project Management, Epic Owner, and Business Executives to perform following activities:

1. Review and understand high-level customer journeys and understand what the customer wants.
2. Review and understand the epics to suggest enhancements/refinements to epics.
3. Perform technical analysis, define architecture/technical vision and strategy to help with the strategic direction of value streams, roadmap, provide solution alternatives, high-level cost estimate.

The architect will be part of backlog grooming to create program backlog which involves the following activities:

1. Review detailed customer journeys to define target state business capability model and model the end-to-end solution architecture including Application, Data, Integration, Infrastructure, Security, and Operations.
2. Identify Non-functional requirements.
3. Perform necessary technical Proofs-of-Concept (PoC’s).

During Program Increment (PI) planning, the architect will help the team with sharing the technical and architectural vision and perform the following activities:

1. Estimate the user and technical stories.
2. Help with prioritization of stories.
3. Help with sprint planning.

As an agile architect, promote the agile approach across the enterprise. Acts like a servant leader, facilitator.  It helps the team in smooth execution and removes any roadblocks. The agile architect is the best product owner for the enterprise architecture product.

As a product owner, the agile architect identifies the architecture required by an organization. The Agile architect owns the acceptance criteria used in the EA development sprints.  As an Architect the focus should be on, 

• Intentional Architecture. Architecture is a Collaboration.
• Participate in all agile ceremonies which include Elaboration, Planning, Retrospection and stand up meetings.
• Build the simplest architecture that can work (established design principles).
• Define minor/major design solutions based on the requirements.
• Don’t under architect and don’t over-design.
• Isolate rapidly changing parts/components from a more stable one.
• Code it or model it (spikes, prototype, domain and use case models).
• Build it, Test it (design for testability).
• Implement Architectural Flow (architectural epics and the portfolio kanban).
• Leading the team on the technical front and guiding the team towards achieving quality deliverable on time.
• Needs to stay invested with the team throughout. Start involvement in a project right from the point of Functional specifications. Jointly review the functional specs with the business to understand the expectations and make sure that what’s written is what’s expected.
• Continuously check with the team to make sure they are not deviating from the stated design. Many times, as an architect had to protect the time from unwanted bureaucracy.

Summary 

In agile, the architect needs to stay invested with the team throughout. Needs to be visionary and at the same time manage change and complexity. Start involving in the project right from the definition of functional specifications. Jointly review the functional specifications with the business team to understand the expectations and make sure that what is written is what is expected. 

Enterprise Architects should organize themselves and take responsibility for their scope of the architecture project delivery. 

References

https://www.scaledagileframework.com

Further Reading

How to Become a Java Software Architect

Software Architecture: The 5 Patterns You Need to Know