Blog Post

Just thirty years ago, there was barely any internet, but today, Information Technology (IT) has transformed the world for the better. The majority of the most valuable companies globally are IT companies. Going by the drastic growth of these companies, there is much to learn from them, especially from their business models and management approach. One of the first opposition to traditional business models came from the automobile industry - with the introduction of Lean Manufacturing by companies like Toyota. As the IT sector grew, it adapted some Lean Principles to fit its fast-paced nature. Hence, the Agile Manifesto was signed by 17 volunteers back in February of 2001, and several years later, it has birthed many Agile Frameworks. Today, we hear many terms from these Agile Methodologies, such as Scrum Master, Design Sprints, etc.

This article explores the application of the Agile mindset and methodologies in Architecture practice.

What is the Agile Framework?

Agile Frameworks are technology processes used to build new ideas and test those ideas using the things learned from the tests to drive the next iteration. The aim is to deliver a product with business benefits sooner.

The most popular Agile Framework is Scrum. Other common ones are Extreme Programming and Kanban System. They all follow the Agile Manifesto. The Agile Manifesto is a set of statements of four values and 12 principles intended to help a team embrace an Agile mindset.

The Manifesto places more Value on:

1. Individuals and Interactions over Processes and Tools;
2. Working Software over Comprehensive Documentation;
3. Customer Collaboration over Contract Negotiation;
4. Responding to Change, over following a Plan.

For the twelve Principles,

• Principle two is about welcoming changes when working in an uncertain zone.
• Principles three and seven refer to continuous product delivery in weeks as a measure of progress - that is why most Agile teams deliver in short iterations called Sprints.
• Principle four describes how customers should work closely with the development team, necessitating a role called the Product Owner, commonly a customer representative who sits with the team and guides them as they deliver the product.
• Principles five and eleven talk about motivated, self-organised teams. That is why most Agile teams are cross-functional and self-organised, small teams of generalists that work together to deliver a product.
• Principle six describes the importance of face-to-face conversations, enhanced through User Stories - mainly in the form of sticky notes on a Kanban board.
• Principles one, eight, nine and ten emphasise prioritising high-value work. The Product Owner identifies what the customer values the most through a Product Backlog.
• Finally, principle 12 encourages the team to meet frequently to discuss process improvement, typically at the end of every sprint.