Thursday, November 2, 2017

Principles of Agile Architecture | Supreme Agile

תוצאת תמונה עבור ‪Agile‬‏
I think that we all agree that the software industry is going towards agile, we can see it based on both a number of companies that already implemented this methodology and also on the large enterprises that going towards it. This major transition requires the implementation of agile practices in a way to support the complex incorporate system architectures with the remainder of following the spirit and principles of the agile manifesto.

As you all know, enterprise-class architectures will demand more than the theoretical guidelines as they presented in the agile manifesto, to help us reach the next level, I created this article proposing few of the most important principles for the development of enterprise architectures.

These principles are as follow:

Principle #1 – keep it Simple to Increase Success
Principle #2 – If you Build, you test IT!
Principle #3 – Collaboration is the Key to Success
Principle #4 – The Same Team Should Design and implement the System
Principle #5 – Continuous Improvement of the Process

We'll describe each of these principals in the sections that follow.


Principle #1 – keep it Simple to Increase Success

Agile software development is known for its focus on simplicity, if we review the agile manifesto (Principle #10):"Simplicitythe art of maximizing the amount of work not doneis essential".  
Simplicity is a major factor as the project/system complexity increases. The only way for agile teams to successfully managing large, complex architectures, is to make sure they keep things as simple as possible, how?
  1. By validating that they will use the simplest design that can work
  2. They remove any unnecessary dependencies in design that can increase complexity.
  3. They uncover any design hidden requirements that can affect the software.
  4. They use only the technology needed to overcome the problem.
Steve jobs: "Simple can be harder than complex: you have to work hard to get your thinking clean to make it simple. But It's worth it in the end because once you get there, you can move mountains"

Principle #2 – If you Build, you test IT!

Testing a system involves many validations and Verification (V&V) activities that will help the team to test the system ability to meet its functionality, Performance and user experience. To do this, teams must design a supported testing infrastructure (Manual/Automated) that provide ongoing testing support.  

The software quality is determined by many aspects, such as the quality of the requirements, Coding and especially testing (if you cannot test the software, you cannot assume it will work on customer environments). Now, that system architectures are more complex than before, there is a Hugh importance to make sure that the entire team will hold the responsibility of testing (Anything else would be just irresponsible enough).

Principle #3 – Collaboration is the Key to Success

Due to the fact that agile teams are self-organized by definition, it makes good economic and technical sense to use the those who have the knowledge, Experience, and skills to match the team goals and challenges.

"Business people and developer must work together daily throughout the project"
To achieve success, each stakeholder should have the power to contribute to the overall project, each technical input should be respected by others, and there is no need to be a specialist to share new ideas.

Principle #4 – The Same Team should code and Design the System

This principle is driven by the agile manifesto itself (Principle #11):"The best architectures, requirements, and designs emerge from self-organizing teams". This principle makes sense because in a real project effort were the agile teams are empowered to deliver software in some narrow time frames (Iterations of 2-4 Weeks at most), teams must have the power to make decisions that can affect their ability to meet the iteration goals including Design, Testing, and coding decisions.

A common pitfall of many agile projects is directed from ignoring this principle, think about a team that needs to be held accountable for design decisions made by others, and that's simply not effective for team performance (Especially when we want to motivate the team to execute plan not made by them).

In addition, we need to remember that these two phases (Design and Execution) are going together, therefore there is no sense to split it among more than one team, so in the optimal scenario these two phases should be made by one team that will take the entire responsibility for design and execution, Expected Benefits:

  • Increased motivation among the team members.
  • Lower chances of synchronization failures.
  • Better decision and execution making.
  • A Collective sense of ownership.

Principle #5 –Continues Improvement of the Process

Just like that, we want to see continues improvement in teamwork using retrospectives and other methods, we also need to continually aim to improve the agile process in our organization.

The motivation behind this principle is very obvious because if we succeed to continually Improve our process, we will make it more efficient, reduce unnecessary overhead, increase quality and reduce delivery time.  

No comments:

Post a Comment

My Presentations